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