Push route not working

delta

I have just configured a new vpn server and got my client working with it.. I can ping both ways but I have a routing issue.

If I wanted to route ALL traffic from the client thru the vpn including all web browsing, the entire internet I am able to do that with push "redirect-gateway def1 bypass-dhcp"

But I don't want to route ALL traffic, only the traffic for my little private network at the other end where the VPN server is. To accomplish this, I commented out the line push "redirect-gateway def1 bypass-dhcp" and instead added this line..

push "route xxx.xxx.xxx.xxx 255.255.255.224"

And the end result is, I can't get to ANY of the above addresses. But I can get there just fine when I route ALL traffic thru the vpn server.

Here is my config...

local xxx.xxx.xxx.xxx
port 1194
proto udp
dev tun
ca ca.crt
cert server.crt
dh dh1024.pem
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "route 216.151.2.96 255.255.255.224"
;push "redirect-gateway def1 bypass-dhcp"
push "dhcp-option DNS 8.8.8.8"
push "dhcp-option DNS 8.8.4.4"
keepalive 10 120
comp-lzo
max-clients 5
user nobody  
group nobody 
persist-key  
persist-tun  
status openvpn-status.log
log         /var/log/openvpn.log
verb 3

janjust

your config shows the full IP address that you masked out elsewhere 🙂
You're trying to push something like

push "route XX.XX.Xx.96 255.255.255.224"

this means all address in the range .96 - .127 will be routed via the VPN - is this truly correct? is this route present on the client after the tunnel comes up? what happens if you run 'traceroute' or 'tracert' to any of these hosts?

delta

janjust wroteyour config shows the full IP address that you masked out elsewhere 🙂
You're trying to push something like
push "route XX.XX.Xx.96 255.255.255.224"
this means all address in the range .96 - .127 will be routed via the VPN - is this truly correct? is this route present on the client after the tunnel comes up? what happens if you run 'traceroute' or 'tracert' to any of these hosts?

That is correct.. I want anything I do that goes to .96 thru .127 to go via the VPN. Currently it only does that if I route ALL traffic thru the vpn.

traceroute goes the long way around, thru comcast ( my isp ) and eventually goes in thru the public IPs When I do the redirect, then the first hop is the vpn server as it should be except tracert to google also goes thru the vpn server.

janjust

does the .96 route appear in the routing table after the VPN connects? what is the metric of that route? is there a more direct route or other route with a lower (= higher priority) metric?

delta

janjust wrotedoes the .96 route appear in the routing table after the VPN connects? what is the metric of that route? is there a more direct route or other route with a lower (= higher priority) metric?

Here is the route table after I connect I am unable to get anything on the 216.151.2.96 network while vpn is up however I can get to the vpn server by using only the 10.8.0.1 address...

IPv4 Route Table
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0      192.168.9.1    192.168.9.252     20
         10.8.0.1  255.255.255.255         10.8.0.5         10.8.0.6     30
         10.8.0.4  255.255.255.252         On-link          10.8.0.6    286
         10.8.0.6  255.255.255.255         On-link          10.8.0.6    286
         10.8.0.7  255.255.255.255         On-link          10.8.0.6    286
        127.0.0.0        255.0.0.0         On-link         127.0.0.1    306
        127.0.0.1  255.255.255.255         On-link         127.0.0.1    306
  127.255.255.255  255.255.255.255         On-link         127.0.0.1    306
      192.168.9.0    255.255.255.0         On-link     192.168.9.252    276
    192.168.9.252  255.255.255.255         On-link     192.168.9.252    276
    192.168.9.255  255.255.255.255         On-link     192.168.9.252    276
     216.151.2.96  255.255.255.224         10.8.0.5         10.8.0.6     30
        224.0.0.0        240.0.0.0         On-link         127.0.0.1    306
        224.0.0.0        240.0.0.0         On-link          10.8.0.6    286
        224.0.0.0        240.0.0.0         On-link     192.168.9.252    276
  255.255.255.255  255.255.255.255         On-link         127.0.0.1    306
  255.255.255.255  255.255.255.255         On-link          10.8.0.6    286
  255.255.255.255  255.255.255.255         On-link     192.168.9.252    276
===========================================================================

delta

In my last message I said something incorrect. I am NOT able to ping the vpn server at all and it is NOT able to ping me..

However if I remove the push route and instead add the push "redirect-gateway def1 bypass-dhcp" then everything works perfectly.. except that I have to route everything via the vpn server.

Here is the routing table on the vpn server if that has anything to do with it..

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.8.0.2        *               255.255.255.255 UH    0      0        0 tun0
216.151.2.96    *               255.255.255.224 U     0      0        0 eth0
10.8.0.0        10.8.0.2        255.255.255.0   UG    0      0        0 tun0
10.1.2.0        *               255.255.255.0   U     0      0        0 eth1
link-local      *               255.255.0.0     U     1002   0        0 eth0
link-local      *               255.255.0.0     U     1003   0        0 eth1
default         216.151.2.97.op 0.0.0.0         UG    0      0        0 eth0

janjust

In my last message I said something incorrect. I am NOT able to ping the vpn server at all and it is NOT able to ping me..

I'm confused now: the client cannot ping the VPN server@ 10.8.0.1 ? that's a VPN issue; all other pings are routing issues. If the client cannot ping 10.8.0.1 then you need to fix that first (check firewalls on both ends).

If the clietn *CAN* ping the VPN server then
[*] try pinging the VPN server at its public IP
[*] check if IP forwarding is enabled on the server (cat /proc/sys/net/ipv4/ip_forward)
[*] check if there's a firewall/iptables rule blocking traffic on the VPN server

delta

janjust wrote I'm confused now: the client cannot ping the VPN server@ 10.8.0.1 ? that's a VPN issue; all other pings are routing issues. If the client cannot ping 10.8.0.1 then you need to fix that first (check firewalls on both ends).

If the clietn *CAN* ping the VPN server then
[*] try pinging the VPN server at its public IP
[*] check if IP forwarding is enabled on the server (cat /proc/sys/net/ipv4/ip_forward)
[*] check if there's a firewall/iptables rule blocking traffic on the VPN server

I only have the trouble pinging the vpn server and back when using the push route. If I comment out the push route, then I can ping fine. Likewise if I use the redirect then I can ping and route everything fine except I don't want to route the entire internet thru the vpn so I need push route to work. But when I use push route, it kills my ability to ping or route anything.

The IP forwarding is enabled, and for temporary testing purposes, I have disabled the firewall.

janjust

still confused 😉
just to clarify: WITH the "push route" in the server config , the client cannot ping 10.8.0.1 after the VPN has come up? can the client ping any other IP (e.g. 8.8.8.8) ?

delta

janjust wrotestill confused 😉
just to clarify: WITH the "push route" in the server config , the client cannot ping 10.8.0.1 after the VPN has come up? can the client ping any other IP (e.g. 8.8.8.8) ?

With the push route, the client can ping 8.8.8.8 or any other external addresses but can not ping the vpn server.

WithOUT the push route but instead using the push "redirect-gateway def1 bypass-dhcp" The client can ping the VPN server and can route ALL packets thru the vpn server. A tracert to 8.8.8.8 shows the vpn server as first hop. The client can also access everything on the server's network just fine (the server's network is all public IPs)

Even though the push redirect is working for me, I prefer not to route all my internet traffic via the VPN which is why I am trying to get push route working.

janjust

you keep stating "with the push route, I cannot ping the VPN server" and I keep repeating: with the "push route", can you ping 10.8.0.1. With the push route, what is the output of

ping 10.8.0.1

and what does the server log show when you do this?
I cannot help you further until I know the answer to this question.

delta

janjust wroteyou keep stating "with the push route, I cannot ping the VPN server" and I keep repeating: with the "push route", can you ping 10.8.0.1. With the push route, what is the output of
ping 10.8.0.1
and what does the server log show when you do this?
I cannot help you further until I know the answer to this question.

Sorry, I didn't know what better way to say it, I can't ping the vpn server.. Here.. the results of pinging the vpn server...

Pinging 10.8.0.1 with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for 10.8.0.1:
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

And as I said before, If I comment out the push route line and instead use the push "redirect-gateway def1 bypass-dhcp" then I CAN ping it and everything routes via VPN.

delta

Sorry, I completely forgot you wanted to see the server log.. Here it is...

Wed Apr 24 01:04:53 2013 OpenVPN 2.2.2 x86_64-redhat-linux-gnu [SSL] [LZO2] [EPOLL] [PKCS11] [eurephia] built on Aug 10 2012
Wed Apr 24 01:04:53 2013 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Wed Apr 24 01:04:53 2013 Diffie-Hellman initialized with 1024 bit key
Wed Apr 24 01:04:53 2013 TLS-Auth MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 EL:0 ]
Wed Apr 24 01:04:53 2013 Socket Buffers: R=[229376->131072] S=[229376->131072]
Wed Apr 24 01:04:53 2013 ROUTE default_gateway=216.151.2.97
Wed Apr 24 01:04:53 2013 TUN/TAP device tun0 opened
Wed Apr 24 01:04:53 2013 TUN/TAP TX queue length set to 100
Wed Apr 24 01:04:53 2013 /sbin/ip link set dev tun0 up mtu 1500
Wed Apr 24 01:04:53 2013 /sbin/ip addr add dev tun0 local 10.8.0.1 peer 10.8.0.2
Wed Apr 24 01:04:53 2013 /sbin/ip route add 10.8.0.0/24 via 10.8.0.2
Wed Apr 24 01:04:53 2013 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
Wed Apr 24 01:04:53 2013 GID set to nobody
Wed Apr 24 01:04:53 2013 UID set to nobody
Wed Apr 24 01:04:53 2013 UDPv4 link local (bound): 216.151.2.125:1194
Wed Apr 24 01:04:53 2013 UDPv4 link remote: [undef]
Wed Apr 24 01:04:53 2013 MULTI: multi_init called, r=256 v=256
Wed Apr 24 01:04:53 2013 IFCONFIG POOL: base=10.8.0.4 size=62
Wed Apr 24 01:04:53 2013 IFCONFIG POOL LIST
Wed Apr 24 01:04:53 2013 LAPTOP,10.8.0.4
Wed Apr 24 01:04:53 2013 android,10.8.0.8
Wed Apr 24 01:04:53 2013 Initialization Sequence Completed
Wed Apr 24 01:05:02 2013 MULTI: multi_create_instance called
Wed Apr 24 01:05:02 2013 192.168.9.252:61689 Re-using SSL/TLS context
Wed Apr 24 01:05:02 2013 192.168.9.252:61689 LZO compression initialized
Wed Apr 24 01:05:02 2013 192.168.9.252:61689 Control Channel MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 EL:0 ]
Wed Apr 24 01:05:02 2013 192.168.9.252:61689 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
Wed Apr 24 01:05:02 2013 192.168.9.252:61689 Local Options hash (VER=V4): '530fdded'
Wed Apr 24 01:05:02 2013 192.168.9.252:61689 Expected Remote Options hash (VER=V4): '41690919'
Wed Apr 24 01:05:02 2013 192.168.9.252:61689 TLS: Initial packet from 192.168.9.252:61689, sid=3012b91a 770f0765
Wed Apr 24 01:05:03 2013 192.168.9.252:61689 VERIFY OK: depth=1, /C=US/ST=OR/L=Wilsonville/O=Delta/OU=Delta_Technical_Services/CN=zeus.deltatechnicalservices.com/name=zeus/emailAddress=les@deltatechnicalservices.com
Wed Apr 24 01:05:03 2013 192.168.9.252:61689 VERIFY OK: depth=0, /C=US/ST=OR/L=Wilsonville/O=Delta/OU=dELTA/CN=LAPTOP/name=changeme/emailAddress=les@deltatechnicalservices.com
Wed Apr 24 01:05:03 2013 192.168.9.252:61689 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Wed Apr 24 01:05:03 2013 192.168.9.252:61689 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Wed Apr 24 01:05:03 2013 192.168.9.252:61689 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Wed Apr 24 01:05:03 2013 192.168.9.252:61689 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Wed Apr 24 01:05:03 2013 192.168.9.252:61689 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Wed Apr 24 01:05:03 2013 192.168.9.252:61689 [LAPTOP] Peer Connection Initiated with 192.168.9.252:61689
Wed Apr 24 01:05:03 2013 LAPTOP/192.168.9.252:61689 MULTI: Learn: 10.8.0.6 -> LAPTOP/192.168.9.252:61689
Wed Apr 24 01:05:03 2013 LAPTOP/192.168.9.252:61689 MULTI: primary virtual IP for LAPTOP/192.168.9.252:61689: 10.8.0.6
Wed Apr 24 01:05:05 2013 LAPTOP/192.168.9.252:61689 PUSH: Received control message: 'PUSH_REQUEST'
Wed Apr 24 01:05:05 2013 LAPTOP/192.168.9.252:61689 SENT CONTROL [LAPTOP]: 'PUSH_REPLY,route 216.151.2.96 255.255.255.224,dhcp-option DNS 8.8.8.8,dhcp-option DNS 8.8.4.4,route 10.8.0.1,topology net30,ping 10,ping-restart 120,ifconfig 10.8.0.6 10.8.0.5' (status=1)
Wed Apr 24 01:05:06 2013 LAPTOP/192.168.9.252:61689 IPv6 in tun mode is not supported in OpenVPN 2.2
Wed Apr 24 01:09:10 2013 LAPTOP/192.168.9.252:61689 [LAPTOP] Inactivity timeout (--ping-restart), restarting
Wed Apr 24 01:09:10 2013 LAPTOP/192.168.9.252:61689 SIGUSR1[soft,ping-restart] received, client-instance restarting

janjust

aha now I see where things are failing: the route you're pushing

push "route XX.XX.XX.96 255.255.255.224"

includes the address of the VPN server itself - so after this route is applied, all traffic to the VPN server it sent via the VPN, including the VPN traffic itself (classic "biting your own tail" problem).

The easiest solution is to push another route

push "route XX.XX.XX.125 255.255.255.255 net_gateway"

which adds a 'bypass' route for the VPN server itself.

delta

janjust wroteaha now I see where things are failing: the route you're pushing
push "route XX.XX.XX.96 255.255.255.224"
includes the address of the VPN server itself - so after this route is applied, all traffic to the VPN server it sent via the VPN, including the VPN traffic itself (classic "biting your own tail" problem).

The easiest solution is to push another route
push "route XX.XX.XX.125 255.255.255.255 net_gateway"
which adds a 'bypass' route for the VPN server itself.

Fantastic!!!! Thank you! That fixed it.. All is working now but I have one last question on a a slightly different topic. I am assuming that my tunnel is not yet encrypted and things I do can be sniffed? Do I need to do something with this?

# Select a cryptographic cipher.
# This config item must be copied to
# the client config file as well.
;cipher BF-CBC # Blowfish (default)
;cipher AES-128-CBC # AES
;cipher DES-EDE3-CBC # Triple-DES

And if I do, which of the above would be the lightest on resources and best for speed.

janjust

by default your tunnel is, as stated, encrypted using Blowfish ; depending on the hardware this is the lightest on CPU load ; only if you have CPUs on both end that support AESNI (Intel i5, i7, Xeon E5) then it would make sens to use AES-256-CBC.