[SOLVED] OpenVPN pushing default routes to clients even if i told not to.

elpardua · Dec 14, 2017, 8:10 PM

Hi guys, i've been searching in the forums to see if someone had the same issue but i couldn't find anything like this. In all the other cases, users were just fine routing all the traffic across the tunnel.

I've configured a road warrior openvpn tunnel in 2.4.1 (had the same problem since various versions and across updates). My idea is to connect in a split tunnel way (my remote computer using the client access the networks behind pfsense using the established tunnel, and the rest of the traffic that goes to the internet goes directly from my computer).

I've specifically configured my networks in "IPv4 Local network(s)", and left unmarked "Force all client generated traffic through the tunnel."

I can reach all my servers, but when i check my routing table i can see the pfsense is pushing the route to default too…

pablo@damnb00k:~/Downloads$ sudo route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.99.1 0.0.0.0 UG 50 0 0 tun0
0.0.0.0 192.168.0.1 0.0.0.0 UG 600 0 0 wlan0
192.168.0.0 192.168.99.1 255.255.255.0 UG 50 0 0 tun0
192.168.0.0 0.0.0.0 255.255.255.0 U 600 0 0 wlan0
192.168.0.1 0.0.0.0 255.255.255.255 UH 600 0 0 wlan0
192.168.20.0 192.168.99.1 255.255.255.0 UG 50 0 0 tun0
192.168.30.0 192.168.99.1 255.255.255.0 UG 50 0 0 tun0
192.168.40.0 192.168.99.1 255.255.255.0 UG 50 0 0 tun0
192.168.50.0 192.168.99.1 255.255.255.0 UG 50 0 0 tun0
192.168.60.0 192.168.99.1 255.255.255.0 UG 50 0 0 tun0
192.168.70.0 192.168.99.1 255.255.255.0 UG 50 0 0 tun0
192.168.99.0 0.0.0.0 255.255.255.0 U 50 0 0 tun0
192.168.99.0 0.0.0.0 255.255.255.0 U 450 0 0 tun0

Tried another fresh install in a VM, and happens the same.

Am i missing something else?

Thanks in advance.
Pablo

JKnott · Dec 14, 2017, 8:20 PM

I noticed the same with IPv6.

johnpoz · Dec 14, 2017, 8:59 PM

Whats in your client config the client is loading??

I am currently connected to openvpn running on 2.4.2 and my client does not get this route - it only gets the routes for the local network behind pfsense.

My guess would be you at one time had it set to default route it, and you did not update the client config after you changed that setting..

My client gets the 10.0.8.2 address, while 192.168.9, .2 and .3 are the local sites I publish to the client… Look in your log when you connect.. You will need to bump your verb level up.. Set to 3 and see all the routes handed to the client when it connects.

elpardua · Dec 14, 2017, 9:32 PM

Hi guys, thank you both for replying.

John, i've checked my client config, but doesn't seems to have any route-related config.

dev tun
persist-tun
persist-key
cipher AES-256-CBC
auth SHA1
tls-client
client
resolv-retry infinite
remote 90.90.90.90 1194 udp
verify-x509-name "UCV" name
auth-user-pass
pkcs12 pfSense-udp-1194-pardua.p12
tls-auth pfSense-udp-1194-pardua-tls.key 1
ns-cert-type server
comp-lzo adaptive

i'll try bumping up the verbosity and try to find what's going on.

Thanks!

Pippin · Dec 14, 2017, 9:48 PM

Pushing route 0.0.0.0 0.0.0.0 somewhere for Windows Firewalls?

Derelict · Dec 14, 2017, 9:52 PM

pablo@damnb00k:~/Downloads$ sudo route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.99.1 0.0.0.0 UG 50 0 0 tun0
0.0.0.0 192.168.0.1 0.0.0.0 UG 600 0 0 wlan0
192.168.0.0 192.168.99.1 255.255.255.0 UG 50 0 0 tun0
192.168.0.0 0.0.0.0 255.255.255.0 U 600 0 0 wlan0

Current OpenVPN versions will not do that. You will get two /1 routes instead:

0.0.0.0/1
128.0.0.0/1

Look elsewhere for the source of that route.

elpardua · Dec 14, 2017, 10:07 PM

@Derelict:

pablo@damnb00k:~/Downloads$ sudo route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.99.1 0.0.0.0 UG 50 0 0 tun0
0.0.0.0 192.168.0.1 0.0.0.0 UG 600 0 0 wlan0
192.168.0.0 192.168.99.1 255.255.255.0 UG 50 0 0 tun0
192.168.0.0 0.0.0.0 255.255.255.0 U 600 0 0 wlan0

Current OpenVPN versions will not do that. You will get two /1 routes instead:

0.0.0.0/1
128.0.0.0/1

Look elsewhere for the source of that route.

I know, right?

Pretty strange. I've configured this in a pretty straighforward process (i usually configure ASA's VPNs through CLI, this is a fraction of the work).

In my computer i'm using the openvpn client included in kali, invoked from network-manager plugins. I have no openvpn client config in /etc/openvpn/client.

JKnott · Dec 14, 2017, 10:12 PM

@Derelict:

pablo@damnb00k:~/Downloads$ sudo route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.99.1 0.0.0.0 UG 50 0 0 tun0
0.0.0.0 192.168.0.1 0.0.0.0 UG 600 0 0 wlan0
192.168.0.0 192.168.99.1 255.255.255.0 UG 50 0 0 tun0
192.168.0.0 0.0.0.0 255.255.255.0 U 600 0 0 wlan0

Current OpenVPN versions will not do that. You will get two /1 routes instead:

0.0.0.0/1
128.0.0.0/1

Look elsewhere for the source of that route.

Where do you see those two? The two 0.0.0.0 routes are normal, the first is for the tunnel and the second for the actual interface. The 0.0.0.0 genmask indicates that all addresses are included. The tunnel has a lower metric, so it will be used as the default route. Even in routers from Cisco, Adtran, etc., the routing is done through 0.0.0.0. The /1 means a subnet mask with only the most significant bit being used to identify a network.

Here's what I get here:
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 172.16.255.1 0.0.0.0 UG 50 0 0 tun0
0.0.0.0 172.16.4.1 0.0.0.0 UG 100 0 0 eth0
172.16.4.0 0.0.0.0 255.255.255.0 U 100 0 0 eth0
172.16.255.0 0.0.0.0 255.255.255.0 U 50 0 0 tun0
174.115.32.127 172.16.4.1 255.255.255.255 UGH 100 0 0 eth0

elpardua · Dec 14, 2017, 10:16 PM

GOT IT!!! Layer 8 Issue :)

The problem is network-manager's implementation of openvpn.

When importing the ovpn file, stupid nm wizard unchecks on IPv4->Routes-> "use this connection only for resources on its network", then, all the traffic is sent through the tunnel.

Thanks all of you for your ideas!

JKnott · Dec 14, 2017, 10:25 PM

^^^^
I see that too.

However, sending all traffic through the tunnel is recommended for "road warriors" who use public WiFi. Your traffic can't be snooped then.

elpardua · Dec 14, 2017, 10:52 PM

I know, but this is just for eventual management purposes, on connections that are already encrypted (ssh and https), and the ISP service has not so much bandwidth.

Thanks again to you all. :)

Derelict · Dec 15, 2017, 5:02 AM

Where do you see those two?

The /1 means a subnet mask with only the most significant bit being used to identify a network.

–redirect-gateway flags...
Automatically execute routing commands to cause all outgoing IP traffic to be redirected over the VPN. This is a client-side option.

This option performs three steps:

(1) Create a static route for the --remote address which forwards to the pre-existing default gateway. This is done so that (3) will not create a routing loop.

(2) Delete the default gateway route.

(3) Set the new default gateway to be the VPN endpoint address (derived either from --route-gateway or the second parameter to --ifconfig when --dev tun is specified).

When the tunnel is torn down, all of the above steps are reversed so that the original default route is restored.

Option flags:

local -- Add the local flag if both OpenVPN servers are directly connected via a common subnet, such as with wireless. The local flag will cause step 1 above to be omitted.

autolocal -- Try to automatically determine whether to enable local flag above.

** def1 – Use this flag to override the default gateway by using 0.0.0.0/1 and 128.0.0.0/1 rather than 0.0.0.0/0. This has the benefit of overriding but not wiping out the original default gateway.**

bypass-dhcp – Add a direct route to the DHCP server (if it is non-local) which bypasses the tunnel (Available on Windows clients, may not be available on non-Windows clients).

bypass-dns -- Add a direct route to the DNS server(s) (if they are non-local) which bypasses the tunnel (Available on Windows clients, may not be available on non-Windows clients).

block-local -- Block access to local LAN when the tunnel is active, except for the LAN gateway itself. This is accomplished by routing the local LAN (except for the LAN gateway address) into the tunnel.

** ipv6 – Redirect IPv6 routing into the tunnel. This works similar to the def1 flag, that is, more specific IPv6 routes are added (2000::/4, 3000::/4), covering the whole IPv6 unicast space.**

!ipv4 – Do not redirect IPv4 traffic - typically used in the flag pair ipv6 !ipv4 to redirect IPv6-only.

https://community.openvpn.net/openvpn/wiki/Openvpn24ManPage

Two routes that OpenVPN can insert and delete at will that override 0.0.0.0/0, due to the longer mask, without OpenVPN having to track, save state of, and reset the user's current default gateway configuration, while continuing to match all IPv4 destinations that don't have a more-specific route.

They do the same thing for IPv6, as highlighted.