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

gregb

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.

DiskWizard

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.

DiskWizard

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)

gregb

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?

DiskWizard

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

DiskWizard

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.

gregb

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