No traffic able to cross site-to-site openvpn
-
I have two sites, site-A and site-B. Site-A hosts a server that systems at site-B need to communicate with. I created a site to site tunnel between them.
The tunnel network is 192.168.212.0/24.
Site-A network is 10.200.36.0/24
Site-B network is 10.212.16.0/24Site-A is the openvpn server.
From Site-A:
/root: route -n get 10.212.16.2 route to: 10.212.16.2 destination: 10.212.16.0 mask: 255.255.255.0 gateway: 192.168.212.2 fib: 0 interface: ovpns2 flags: <UP,GATEWAY,DONE,STATIC> recvpipe sendpipe ssthresh rtt,msec mtu weight expire 0 0 0 0 1500 1 0
From Site-B:
/root: route -n get 10.200.36.2 route to: 10.200.36.2 destination: 10.200.36.0 mask: 255.255.255.0 gateway: 192.168.212.1 fib: 0 interface: ovpnc1 flags: <UP,GATEWAY,DONE,STATIC> recvpipe sendpipe ssthresh rtt,msec mtu weight expire 0 0 0 0 1500 1 0
I have the common setup issue where I can ping resources on either side of the tunnel from the local tunnel's interface, but nothing on the respective site's networks can get through. My firewall rules for the openvpn interface and the subnets in question are wide open (any/any).
For instance, 10.212.16.2 cannot ping 10.200.36.2, even though their routes are set and there's nothing blocking as far as I can see, though it sure seems that way! The hosts return pings normally on their own networks.
I have tcpdumped at both ends and nothing from the 10.212.16.0/24 network even reaches the other end of the tunnel, and vice versa... except that site-A can ping the other side of the openvpn tunnel -192.168.212.2.
I've been up too long to solve this one myself. I look forward to your insights!
-
@troutpocket
First change the OpenVPN tunnel mask to /30 if you have only a single client connecting to the server. Otherwise you would need to add a CSO for the client if you want to access any behind it.Then check the firewall of the destination device. Probably you have to add a rule to allow access from the remote network.
-
@viragomann
Thanks for the suggestion. Unfortunately, it's still behaving the same. In troubleshooting I made both networks are wide open with src:all and dst:all set for all protocols. I even switched which end is the server and client.This is really weird because I setup tunnels like this all the time. I even copied most of the config from another tunnel on a completely separate pair of sites in case I missed something. I'm worried one of the HA pairs is screwed up in other ways, now, after clicking on status->interfaces.
-
@troutpocket
Did you ensure that the destination device is even accessible from outside of its own subnet? -
@viragomann Indeed I did. I can even ping the 10.200.36.2 interface (and other devices on that subnet) from the interface at the other end of the openvpn tunnel! I'm tearing the whole thing down now and starting from scratch. I think something got horked along the way and I have a short amount of time to get it resolved.
-
I'm comparing configs and diagnostics between two deployments and noticed this. On the trouble site, the interface description doesn't include POINT2POINT
working site:
ovpns5: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1500 options=80000<LINKSTATE> inet6 fe80::208:a2ff:fe0e:e325%ovpns5 prefixlen 64 scopeid 0x1c inet 192.168.57.1 --> 192.168.57.2 netmask 0xffffff00 groups: tun openvpn nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL> Opened by PID 29277
another working site:
ovpns2: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1500 options=80000<LINKSTATE> inet6 fe80::208:a2ff:fe0e:e28d%ovpns2 prefixlen 64 scopeid 0x1f inet 10.248.33.1 --> 10.248.33.2 netmask 0xffffff00 groups: tun openvpn nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL> Opened by PID 32259
trouble site:
ovpns1: flags=8043<UP,BROADCAST,RUNNING,MULTICAST> metric 0 mtu 1500 options=80000<LINKSTATE> inet6 fe80::3eec:efff:feb6:84cc%ovpns1 prefixlen 64 scopeid 0x21 inet 192.168.212.1 netmask 0xffffff00 broadcast 192.168.212.255 groups: tun openvpn nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL> Opened by PID 99982
FYI, the sites I indicated as working are completely unrelated to the trouble site.
I checked other sites where I've setup point to point openvpn connections and the interfaces are all like the working site - specifically defined with POINTOPOINT in ifconfig. Only the trouble site is failing to define it that way.
-
Yup. Changing it to "shared key" seems to have worked. That's bananas! All the systems I was comparing to were also 23.01 and were using peer to peer (SSL/TLS). These are all 7100 1U appliances in HA configuration. Anyway, it's now working and I met my deadline so I'm going to take a break. If anyone has any ideas why share key worked but ssl/tls didn't, I'd love to hear it.