A Different WireGuard Problem
-
I have a WireGuard routing issue that is unlike any other problems I can find here. Here is the scenario ...
I have a standalone WireGuard server (a Raspberry Pi-4) plus four other computers sitting behind my pfSense firewall, all on the same internal subnet. These machines can all communicate with each other via both the WireGuard VPN and their normal subnet addresses. So the tunnel is working properly.
But ... another client of the VPN is outside the firewall, on the Internet. It does pick up its correct WG IP address from the WG server that sits behind the pfSense firewall. The issue is that I can't ping or SSH to/from this external computer and any of the internal WG IP addresses, including the WG server itself. This despite the fact that the outside computer's WG connection has been set up correctly. Its own firewall is not blocking any traffic thru the tunnel.
The issue seems to be that of needing some sort of rule to make sure IP packets are forwarded transparently thru the pfSense firewall. Once the VPN is established, pfSense should in theory not see anything in the tunnel, it just forwards traffic via the WG port to the WG server.
Is there something else I need to add to the NAT/Rules sections in pfSense besides just forwarding traffic on the WG port to the WG server??
Any suggestions will be most welcome, with my thanks.
Chuck -
@chuckm2000 This has nothing to do with pfsense. As long as you have the correct port open on the pf, everything else should be handled by rpi. Two things that come to my mind are - setup RPI to forward traffic sysctl net.ipv4.ip_forward and second enable NAT on rpi. For added measure - disable fw on rpi and look for logs on your roaming client to see if the tunnel 'really' connected. There are enough resources on google to help you with this. Good luck.
-
@ab5g
Many thanks for your reply. You have confirmed my original thoughts, that pfSense should not be getting in the way. I simply have a NAT and Rule that forwards all traffic on the VPN's port number to the RPi WireGuard server. So I agree it should not be the problem.The RPi does have IPv4 forwarding enabled in the kernel, and its firewall is disabled, but the problem persists. And forwarding does work between computers inside the pfSense firewall when I use the VPN IPs to do pings and SSH connections. But the objective is to have the remote host able to use the VPN to reach the computers sitting behind the pfSense firewall.
I need to fire up something like WireShark at both ends of the path to see if I can figure out what's blocking packets. The only indication I get from doing pings is "Destination host unreachable". And SSH simply hangs silently. It could be a setting at the remote-end Linux machine.
Fortunately OpenVPN does work in this scenario, but I would prefer to switch to the newer lighter-weight WireGuard to do the job. The two forms of VPN use very different mechanisms under the covers.
I'll eventually figure it out, and it's bound to be something embarrassingly simple.
Chuck
-
@ab5g
Forgot to ask .... are you the "AB5G" I see on the QRZ site? Just curious
Chuck VA7UL -
@chuckm2000 If the Wireguard tunnel is up then its routing on the pi. What you need to do it to NAT the remote clients on the pi such that for the local LAN it looks like the traffic is coming from the pi. For instance I have the following on my pi .
cat /etc/wireguard/wg0.conf
[Interface]
Address = 10.100.100.50/32
PrivateKey = xxxxxxxxx=
PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE[Peer]
PublicKey = Pxxxxxc=
AllowedIPs = 10.100.100.0/24,192.168.1.0/24
Endpoint = 58.182.47.98:51820P.S: I am not on QRZ.