Site-to-site tunnel up but devices from other site not reachable (route to WAN?)
-
I have set up a OpenVPN site-to-site tunnel following this guide exactly: https://doc.pfsense.org/index.php/OpenVPN_Site_To_Site
Now the tunnel is marked as "up" but I cannot reach anything from the other subnets. To me it looks like there are no routes but obviously I have set "IPv4 Remote networks" on both sides to reflect the subnet of the remote site. As the guide has no other mentions I'd assume this is enough however, when I look in "Diagnostics / Routes" there are no routes to the remote site subnets. Should they show up here? The remote site pfSense tunnel IP does show up here and is pingable:
10.8.10.2 link#7 UH 3 1500 ovpns1
Gateways on clients in both subnets are correct. Here are some characteristics of the situation:
Setup:
pfSense A wan: 1.1.1.1 (example)
pfSense B wan: 2.2.2.2 (example)A OpenVPN (server) tunnel IP: 10.8.10.1
B OpenVPN (client) tunnel IP: 10.8.10.2
Both OpenVPN tunnel network: 10.8.10.0/30A LAN Subnet (configured on B "IPv4 Remote networks"): 10.0.10.0/24
B LAN Subnet (configured on A "IPv4 Remote networks"): 10.0.11.0/24A LAN IP: 10.0.10.250
B LAN IP: 10.0.10.250Pings and traces:
On A: ping 10.8.10.2 works!
On B: ping 10.8.10.1 works!On A: ping 10.0.11.250 timeout
On B: ping 10.0.10.250 timeoutOn some client in subnet A:
traceroute to 10.0.11.250 (10.0.11.250), 30 hops max, 60 byte packets 1 pfSenseA (10.0.10.250) 0.317 ms 0.287 ms 0.278 ms 2 datacenter-gw-which-is-default-gw-of-pfSenseA (WAN-IP) 0.881 ms 0.886 ms 0.874 ms 3 datacenter-some-core-router (WAN-IP) 0.838 ms 0.815 ms 0.809 ms 4 datacenter-seemingly-exit-router (WAN-IP) 3.445 ms 3.429 ms 3.409 ms 5 * * * [...] 30 * * *
I found more posts with similar problems but never with a real clue. In the traceroute obviously there is a routing problem from hop 1 to 2 but why? Shouldn't the traffic go through OpenVPN when the tunnel is up and "IPv4 Remote networks" are configured?
Any help would be welcome!
-
What tell the OpenVPN Logs?
-
Not sure for what I should look in it. I don't see anything related to the subnets. A and B logs look very similar only in B there are some parts with "No route to host (code=65)" which is cryptic to me. Therefore I'll just post B (complete openvpn log output after the latest restart):
Feb 6 19:25:48 openvpn 6610 Initialization Sequence Completed Feb 6 19:25:48 openvpn 6610 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this Feb 6 19:25:48 openvpn 6610 Peer Connection Initiated with [AF_INET]1.1.1.1:51194 Feb 6 19:25:41 openvpn 6610 write UDPv4: No route to host (code=65) Feb 6 19:25:40 openvpn 6610 write UDPv4: No route to host (code=65) Feb 6 19:25:40 openvpn 6610 write UDPv4: No route to host (code=65) Feb 6 19:25:40 openvpn 6610 UDPv4 link remote: [AF_INET]1.1.1.1:51194 Feb 6 19:25:40 openvpn 6610 UDPv4 link local (bound): [AF_INET]2.2.2.2:0 Feb 6 19:25:40 openvpn 6610 TCP/UDP: Preserving recently used remote address: [AF_INET]1.1.1.1:51194 Feb 6 19:25:40 openvpn 6610 /usr/local/sbin/ovpn-linkup ovpnc1 1500 1572 10.8.10.2 10.8.10.1 init Feb 6 19:25:40 openvpn 6610 /sbin/ifconfig ovpnc1 10.8.10.2 10.8.10.1 mtu 1500 netmask 255.255.255.255 up Feb 6 19:25:40 openvpn 6610 do_ifconfig, tt->did_ifconfig_ipv6_setup=0 Feb 6 19:25:40 openvpn 6610 ioctl(TUNSIFMODE): Device busy (errno=16) Feb 6 19:25:40 openvpn 6610 TUN/TAP device /dev/tun1 opened Feb 6 19:25:40 openvpn 6610 TUN/TAP device ovpnc1 exists previously, keep at program end Feb 6 19:25:40 openvpn 6610 GDG: problem writing to routing socket Feb 6 19:25:40 openvpn 6610 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts Feb 6 19:25:40 openvpn 6408 library versions: OpenSSL 1.0.2m-freebsd 2 Nov 2017, LZO 2.10 Feb 6 19:25:40 openvpn 6408 OpenVPN 2.4.4 amd64-portbld-freebsd11.1 [SSL (OpenSSL)] [LZO] [LZ4] [MH/RECVDA] [AEAD] built on Nov 16 2017 Feb 6 19:25:40 openvpn 6408 disabling NCP mode (--ncp-disable) because not in P2MP client or server mode
Edit: Maybe "GDG: problem writing to routing socket" can give some clue? It is also present in A…
-
Are you using TAP devices in the OpenVPN settings?
-
no, I really followed the guide 1:1 (unless I made a mistake but I just rechecked and it is tun on both).
-
meh, after some further fun trail and error I found the problem. There was an old and disabled IPSec rule in conflicting subnet range. It looks like also it was disabled and definitely offline it still hindered OpenVPN to add its routes. After deleting it completely and another restart site-to-site works. And for further reference: yes, now also the routes to the remote OpenVPN subnets show up in "Diagnostics / Routes".