Problem with WireGuard remote access tunnels
-
Hello, all!
I've configured my pfSense CE box to have a whole-network WireGuard tunnel out to a VPN provider.
I'm also trying to set up some WireGuard remote access tunnels back into my network. Everything worked as expected with a split tunnel configuration, but when I tried to move over to full tunnel, I started seeing some weird results.
On an iPhone WG peer, everything routes properly. When I tunnel into my home network and go to an IP checker website (ip.me), I see the public address of the VPN provider. I can also access local resources as expected.
When I try to do the same thing using my Linux laptop connected to a hotspot, I can access local resources, but the IP checker shows the address of the hotspot I'm connecting to. This seems like the laptop is split tunnelled.
I've checked the conf file on my Linux peer and everything seems like it is set properly (e.g. AllowedIPs = 0.0.0.0/0). I've also checked the Oubound NAT rules in pfSense and do have a rule which should be supporting traffic on my WireGuard inward tunnel subnet to go out the VPN gateway. I've also checked that all my firewall rules specify the VPN gateway as well.
I ran traceroute on my Linux peer, and it shows the first hop as my VPN tunnel address and the second hop as my VPN-provider's IP address.
I'm honestly at a loss, so any advice would be greatly appreciated!

-
@shiftysandbox62 Must be a routing (table? WG application?) issue on the Linux laptop. If packets 'leaving' the laptop and 'arriving' at the hotspot were destined for your WG server, then that's where they'd go. You apparently have packets 'leaving' the laptop and 'arriving' at the hostspot not destined for your WG server.
Wouldn't have anything to do with the pfSense side.
-
@tinfoilmatt Thank you very much! Do you of a good resource I can use to help me troubleshoot routing? I'm relatively new to Linux, but love to learn.

EDIT: I tried uninstalling the WG client package on my Linux machine and am still encountering the same issue.
-
For anyone who may find this thread later, I tracked the cause down to an IPv4 vs IPv6 issue. I only configured my tunnel for IPv4, and while the the WiFi network demonstrating the behavior had an IPv4 LAN, its WAN address was IPv6.
Privacy Policy · Cookie Policy