Wireguard site to site tunnel with GNAT
-
In the past I have successfully set up a few Wireguard site to site tunnels using Netgate routers but always where both ends have public IPs. For a new site I am working on I am stuck with a CGNAT telco connection on one end. I set up the tunnel as normal and all looks good: the tunnel handshake status is good and I can ping the routers in either direction. But if I try an HTTPS connection e.g. to the pfSense console it only works in one direction.
Does anyone know a) is it possible to get a setup like this to work? b) if so then what do you think I have missed? My understanding is that it should work but is there something extra needed to get TCP type connections to work through the tunnel where there is CGNAT?
Here is a diagram of my setup and what I have verified:
- client 2 can ping pfSense A
- client 1 can ping pfSense B
- tunnel status is good from both A & B ends
- client 2 can connect via HTTPS to pfSense A console
- client 1 cannot connect to pfSense B via HTTPS
-
Here is the diagram:
-
@prot0type VPN does work with NAT or CGNAT, yes. In that configuration pfSense B has to initiate the connection since it got a non-public IP. From there it should behave all normal.
I'd guess that there is an issue with firewall rules, since you can ping in both directions.
Have you create the interfaces for the Wireguard endpoints? Can you show the relevant firewall rules on both sites?
If you do a package capture on pfSense B, do you see HTTPS traffic from client 1?
-
Yes, have created interfaces, these are called BRUNYVPN and ROCHFORDVPN, firewall settings below.
When I try packet capture on the tunnel at pfSense B I don't see anything from client 1 but I do see port 443 traffic from client 2 to pfSense A as expected. Any idea how come the ICMP traffic gets through and the TCP traffic doesn't?
-
@patient0 Actually when I do packet capture on the tunnel interface and ping back and forth this traffic doesn't show up either, but the pings do work. Could it be that ICMP is handled in a special way by Wireguard? In other words the fact that the tunnel connects and allows ping in both directions doesn't mean much. I think there is a more fundamental issue here that I am missing.
-
@prot0type ICMP is not handled different, no. If you can ping the tunnel endpoints; 192.168.60.1 from 192.168.60.0 and vis versa, then the tunnel is up.
Which pfSense is which? BRUNYVPN is on pfSense A and ROCHFORDVPN on pfSense.
And you got hits in the 'States' of the firewall rules, that indicates traffic is passing through the interfaces.
Have you followed the Netgate: WireGuard Site-to-Site VPN Configuration Example? Well, not sure how the example looks with CGNAT.
-
@patient0 Yes, have followed that guide and infact have set up quite a few Wireguard tunnels before with no issue. The difference this time is the CGNAT. I am pretty sure its some quirk of the CGNAT that is causing this but still unsure how to diagnose.
My firewall settings on the tunnel interfaces are correct I think and are the same as I normally use, there is no blockage there.
