Route to loopback (lo0) interface instead of openvpn tunnel interface (ovpnc1)



  • Summary: When the OpenVPN tunnel comes up the remote network route is bound to the loopback interface. Manually updating the route to use the OpenVPN tunnel interface corrects the issue.

    I have a refresh install of "2.2-ALPHA (amd64) built on Fri Jul 11 23:19:58 CDT 2014" running on a Xen 4.1 host. The pfSense box has a single WAN interface (xn0).

    The pfSense appliance is acting as an OpenVPN client. I have added the following directives so that the server doesn't push a full set of routes to the pfSense appliance:

    
    ns-cert-type server
    setenv PUSH_PEER_INFO
    route-nopull
    
    

    Environment:

    • The local network uses 10.20.0.0/16, with the pfSense box on 10.20.25.2/24

    • The remote network uses 192.168.0.0/16

    • The remote OpenVPN server configuration steals address space from 5.5.24.0/21

    • the tunnel is IPv4 only

    Last part of the OpenVPN connection log:

    
    Jul 14 19:07:37 	openvpn[52321]: OPTIONS IMPORT: timers and/or timeouts modified
    Jul 14 19:07:37 	openvpn[52321]: OPTIONS IMPORT: explicit notify parm(s) modified
    Jul 14 19:07:37 	openvpn[52321]: OPTIONS IMPORT: LZO parms modified
    Jul 14 19:07:37 	openvpn[52321]: OPTIONS IMPORT: --ifconfig/up options modified
    Jul 14 19:07:37 	openvpn[52321]: OPTIONS IMPORT: route-related options modified
    Jul 14 19:07:37 	openvpn[52321]: ROUTE_GATEWAY 10.20.25.1
    Jul 14 19:07:37 	openvpn[52321]: TUN/TAP device ovpnc1 exists previously, keep at program end
    Jul 14 19:07:37 	openvpn[52321]: TUN/TAP device /dev/tun1 opened
    Jul 14 19:07:37 	openvpn[52321]: do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
    Jul 14 19:07:37 	openvpn[52321]: /sbin/ifconfig ovpnc1 5.5.24.47 5.5.24.47 mtu 1500 netmask 255.255.248.0 up
    Jul 14 19:07:37 	openvpn[52321]: /sbin/route add -net 5.5.24.0 5.5.24.47 255.255.248.0
    Jul 14 19:07:37 	openvpn[52321]: /usr/local/sbin/ovpn-linkup ovpnc1 1500 1542 5.5.24.47 255.255.248.0 init
    Jul 14 19:07:42 	openvpn[52321]: /sbin/route add -net 192.168.0.0 5.5.24.1 255.255.0.0
    Jul 14 19:07:42 	openvpn[52321]: Initialization Sequence Completed
    
    

    The local ipv4 routes are as below (with the last one being the suspect route):

    
    # netstat -rn
    Routing tables
    
    Internet:
    Destination        Gateway            Flags    Netif Expire
    default            10.20.25.1         UGS       xn0
    5.5.24.0/21        5.5.24.51          UGS    ovpnc1
    5.5.24.51          link#6             UH     ovpnc1
    10.20.25.0/24      link#5             U         xn0
    10.20.25.2         link#5             UHS       lo0
    127.0.0.1          link#3             UH        lo0
    192.168.0.0/16     5.5.24.1           UGS       lo0
    
    

    Is this a configuration issue? If I manually add the route I see the same results with the lo0 interface being used and packets dieing with TTL exceeded:

    /sbin/route add -net 192.168.0.0 5.5.24.1 255.255.0.0
    

    Adding the route like this is a manualy workaround

    # route del 192.168.0.0/16
    del net 192.168.0.0
    # /sbin/route add -net 192.168.0.0/16 -interface ovpnc1
    add net 192.168.0.0: gateway ovpnc1
    

    My expectation was that because the gateway is reable via the ovpnc1 interface the new route would inherit/acquire this interface. Is this an issue in the alpha or is it user error? Thanks.



  • Seems like my problem also connected  with lo0 being used as default route for WIFI, but I never tried to fix it manually.
    Okay, I'll take a deeper look into my problem now.



  • Problem solved - I had to switch NAT Outbound from Manual Outbound NAT rule generation (AON - Advanced Outbound NAT) to Automatic outbound NAT rule generation (IPsec passthrough included)



  • I also had NAT setup on manual with a single rule. I will using automatic after I rebuild the pfSense box (I did an automatic upgrade and it didn't boot afterwards).

    My appliance has a single interface.  Only traffic out the OpenVPN interface requires nating.  I don't have IPSEC running. Is automatic mode appropriate? Why does the NAT rule impact routing?



  • The only reason for my actions was to solve the problem, later I'll check my outbound permissions to set them secure as possible.



  • My appliance has a single interface.  Only traffic out the OpenVPN interface requires nating.  I don't have IPSEC running. Is automatic mode appropriate? Why does the NAT rule impact routing?

    I don't want to be ignorant, but the questions you're asking have the answers in manuals nor technological univesities.

    We're all digging on our own btw.

    Cordially yours, Dimitry.



  • Note #4 of this bug seems to cover this:
      https://redmine.pfsense.org/issues/3747#note-4