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



  • 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



  • I noticed the same with IPv6.


  • Rebel Alliance Global Moderator

    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.






  • 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!



  • Pushing route 0.0.0.0 0.0.0.0 somewhere for Windows Firewalls?


  • Netgate

    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.



  • @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.



  • @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



  • 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!



  • ^^^^
    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.



  • 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. :)


  • Netgate

    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.