Open VPN TUN Site-to-Site only can ping VPN peers, works fine with TAP
-
I have a site-to-site that I've configured with TAP, however the hit to MTU is an issue for my use-case. I also prefer to offload any network routing configuration to quagga ospf, which works well with TAP.
I'm able to get OSPF to work and distribute routes over a TUN network now, which is actually new as I remember in the past even setting non-broadcast with manual peers didn't work. However I still have the issue where hosts behind the PFSense router pair are not able to communicate over the tunnel. I'm able to test connection from the client to the router, and confirm OSPF has a neighbor relationship.
I want any network behind the remote site to communicate to the "HQ" site especially internet networks, the current TAP config works well for this.I know I'm not understanding a key concept with the remote and local networks, but the way I currently have both the HQ and remote site are configured to pass 0.0.0.0/0 for both remote and local network, which I would assume w/o routes setup (which are handled by OSPF) should allow all traffic to pass the tunnel from either side, i.e. any website with any IP can communicate with any host with any IP with an ospf route.
I've returned to the TAP connection type again after not being to get the TUN to work again, but if there's a openvpn config I've missed when reading the docs, or an PFsense specific feature I'm missing I'm hoping someone can explain what it is, or at least why my desired configuration isn't possible.
Thanks
-
What kind of TUN did you specifically create? SSL/TLS, Shared Key, Tunnel Network size, etc?
-
Currently it's a UDPv4 TLS PKI authenticated TAP tunnel, on a /24 Tunnel network, LZO adaptive compression, no advanced features, disable all route push., remote and local network set to 0.0.0.0/0. All I did this time was change the network type from TAP to TUN on a working configuration and confirm peer/ospf connectivity.
I'm re-reading some things on openvpn and I realize the issue that could be causing remote LAN traffic to die at the TUN connection is because the IP is out of the TUN network. Maybe this means I need to NAT traffic to the TUN subnet? I did try this briefly and didn't get any success, but if this is the best way to solve this I can re-attempt. -
You cannot use OSPF over an SSL/TLS tun tunnel with a /29 or larger tunnel network because OSPF cannot insert the necessary iroutes required by OpenVPN server mode into OpenVPN based on the routes received by the protocol.
You can use a point-to-point network (SSL/TLS with a /30 tunnel or a shared-key config with any size tunnel network (shared-key always uses just the first /30 no matter what you define)).
In point-to-point mode OpenVPN will transmit any traffic received by the process across the tunnel because there is no concept of iroutes in ptp mode so there are no special requirements placed on the source/dest addresses of the traffic (like iroutes).
-
Thank you very much, I was able to get this to connect. I had actually use a /30 before, but a) the openvpn service crashes if it is specified and a /24 network had been used in since last boot, and b) If I was able to get this to work in the past with a /30 I hadn't noticed enough to set the network type to point-to-point in OSPF.
I was able to resolve this by setting a /30 on my TLS/SSL network (I want to use GCM), rebooting, and then setting OSPF to use /30 networks with network type point-to-point. I don't have the MTU/MSS I was hoping to get out of TUN at 1398, but It's a lot better than the 1296 I was getting with TAP.
Is is possible the TLS/SSL tunnel is adding a lot of additional overhead that the PSK tunnel would not be? If so, I may need to further decide if the overhead reduction is worth the loss in acceleration of the GCM which isn't supported with PSK.Thanks again!
-
What is 1398? MTU or MSS?
-
https://www.speedguide.net/analyzer.php Here's where I get the values:
1397 MTU(now after testing tun-mtu values)
1357 MSSI currently have these advanced options set:
fixmss;
tun-mtu:1400I was able to confirm these are functional after setting the MTU to 1300 and getting that result on the test above. but with 1400, it seems 1397 is the best I can do, which makes sense if the MSS of non-tunneled packets is 1460 (40bytes of headers) - another 40 bytes for encapsulated packets = 1420, so it seems there's about 23 bytes of OpenVPN headers for TLS/SSL authentication. I was just hoping to get as close to the 1420 I've seen in IPsec as possible. I'm not using IPSec because of the routing functionality.
I set the tun-mtu to 1402 and the tested result still returns the above results with MTU 1397
