WireGuard on pfSense behind ISP router. Why do I need a static route?
-
@dangersheep
Did you remove the interface already or at least the IP and gateway settings?Did you add a firewall rule to Wireguard or even the specific interface to allow access?
-
@Bob-Dig Thank you. I've followed all your instructions. I've deleted the static route; I've deleted the wireguard gateway (now it defaults to WAN_DHCP); I've deleted the assigned interface for wireguard. However, the most I can do is establish a handshake.
On my phone with wg active, I see a 'healthy' tx volume (23 KiB) after a minute or two, but just 700 B of rx traffic. The connection doesn't seem to be replying 'properly'
-
@viragomann said in WireGuard on pfSense behind ISP router. Why do I need a static route?:
Did you remove the interface already or at least the IP and gateway settings?
I removed the assigned interface. And I removed the gateway dedicated to WG. Now I only have one gateway (for each IPv4 and v6) and I explicitly made "WAN_DHCP(6)" the default gateway for pfSense.
-
@viragomann said in WireGuard on pfSense behind ISP router. Why do I need a static route?:
Did you add a firewall rule to Wireguard or even the specific interface to allow access?
Yes.
On the WAN interface, there is one rule allowing all IPv4 UDP traffic addressed to the port 51820 on the WAN interface to pass.
On the WireGuard firewall tab (there is no longer a tab for the assigned interface - deleted - so this is just whatever default WireGuard 'interface' exists) there is just one rule that allows all IPv4 traffic to pass from any source/port to any source/port.
-
@dangersheep
So you should be able to ping the WG server IP and the pfSense LAN IP as well at least. Doesn't this work? -
As for how the rules are performing, I log when the WAN -> WG rule is passed, and I see that happening, with UDP traffic addressed to WAN_ADDRESS:51820.
There is lots of blocked UDP traffic on WAN_ADDRESS but it seems to be mainly on port 137 coming from all sorts of ports on the upstream ISP-router LAN address = default gateway.
In passing, why would there be traffic directed to pfSense_WAN:137 from the upstream gateway? I guess that's a response to a filesharing service somewhere behind pfSense - would that make any sense?
-
@viragomann said in WireGuard on pfSense behind ISP router. Why do I need a static route?:
So you should be able to ping the WG server IP and the pfSense LAN IP as well at least. Doesn't this work?
No, that does not work. pfSense is configured to respond to ping and does so from a device on the LAN subnet. But when connected to the wireguard tunnel, it is not possible to ping anything.
-
I can, for example, run wireshark on the wg interface on a device (using my phone data as hotspot). The handshake completes, but when I try to ping I see the ICMP traffic leaving 10.0.100.2 with destination 10.0.100.1 but never any reply.
-
This post is deleted! -
@dangersheep said in WireGuard on pfSense behind ISP router. Why do I need a static route?:
In passing, why would there be traffic directed to pfSense_WAN:137 from the upstream gateway? I guess that's a response to a filesharing service somewhere behind pfSense - would that make any sense?
If you're running the filesharing behind pfSense and didn't expose it, there should no related packets be seen on the WAN.
Maybe the router just tries to get NetBIOS informations.
Für Kurviger habe ich ein Tourer+ Jahresabo, eben auch, um das Projekt zu unterstützen. Mal sehen,
Do you see the packets, when sniffing the traffic on pfSense on the WG interface?
-
@viragomann said in WireGuard on pfSense behind ISP router. Why do I need a static route?:
Do you see the packets, when sniffing the traffic on pfSense on the WG interface?
So, I can see the handshake, watching the traffic on the wg interface from my remote device.
And I can see the ICMP arriving on the pfSense WG interface:
HH:53:42.411647 IP 10.0.100.2 > 10.0.100.1: ICMP echo request, id 18, seq 1, length 64 -
@dangersheep
But no response?To get sure, if you go to Status > Gateways, is there any other gateway shown up aside from the WAN?
Does pfSense and the LAN devices even have internet access?
-
@viragomann
No reply, no. I just see that line.Status > Gateways just shows the ISP router LAN interface address (ipv4 and 6) and both are 'online. No other gateways.
pfsense and the LAN devices both have internet access.
-
@dangersheep
If I watch the pfSense LAN interface and ping from a device on that subnet, I get a response and I see the full request-reply exchange in the pfSense packet capture, so I think I'm doing it right.There's really nothing coming back out of the WG interface.
-
What gateway should traffic on the wireguard tunnel use? Surely you want that traffic to go back out the wireguard interface, not out the default gateway?
Aren't the packets being encrypted, at the remote wg interface (we see them hitting that interface), travelling down the tunnel, being decrypted and hitting the pfSense wg interface (we see them arriving), and then sent back out the default gateway? What guarantees that the wg traffic goes back out the tunnel?
-
For some reason, it's only when I do the full combination of:
- assigning an interface
- creating a new gateway as before
- adding a static route as before
that suddenly the wg tunnel lights up with returned traffic to the remote device. Weird!!!??? I'm concerned I'm doing something dumb/dangerous.
-
@dangersheep In your picture the WG-Client is a phone. And you don't want to define that as an external gateway because you don't want to route any traffic out there to the internet or any other clients because a phone has no other clients around it, right?
Clearly you missing out on some of the basic stuff which could explain your problems. It is not easy to come up with a solution just from what you describe.
You don't need an external gateway for networks (subnets) that are directly connected to your pfSense. A phone with the WireGuard Client would be connected directly to the pfSense.
-
@Bob-Dig
You're right, I'm very ignorant! But I think I have a (very) basic understanding of the setup.I had assumed there was no need for interface assignment/gateway definition/routing but that simply isn't working at the moment. With @viragomann we narrowed it down to the fact that the WG_HOST interface sees ping requests through the tunnel but there is no sign of a reply on that interface when I log packets. There is definitely a firewall rule on the WireGuard tab (an automatic interface?) to allow all traffic from anywhere, to anywhere, and at that point I don't understand why it doesn't work.
Thanks for all your patience with this.
-
@dangersheep said in WireGuard on pfSense behind ISP router. Why do I need a static route?:
What gateway should traffic on the wireguard tunnel use? Surely you want that traffic to go back out the wireguard interface, not out the default gateway?
Generally there is no gateway needed to get access from WG clients to the local network.
When you set up a WireGuard access server, it just adds an additional (virtual) network to pfSense, where one IP out of the subnet is assigned to pfSense (virtual interface, even if it is not explicitly assigned), and a WG client gets another IP out of this subnet. So the client is virtually directly connected to pfSense.
Communications between the subnets on pfSense don't need any gateway. A gateway is only necessary to access subnets, which are not assigned to the router, to let it know, where the packets have to be sent to.Aren't the packets being encrypted, at the remote wg interface (we see them hitting that interface), travelling down the tunnel, being decrypted and hitting the pfSense wg interface (we see them arriving), and then sent back out the default gateway?
Encrypted is only the payload, but this doesn't have any affect to the routing. Each (encrypted) packet has still the source and destination address in the the header, which can be read by any device which is processing it.
What guarantees that the wg traffic goes back out the tunnel?
That the client is virtually directly connected to the router.
But maybe there is something wrong in the WireGuard setup.
-
@viragomann
Thank you for the clear explanation, I appreciate it and it all makes sense. There must be some conflict. I would have guessed it was to do with the firewall, but it's difficult to filter the blocked packets on a virtual interface.I guess the ping response must be being blocked leaving the WG_HOST virtual interface (because I don't see the reply even sniffing there)? Or is it being blocked at the pfSense WAN interface (but this would presumably be after it's left the virtual WG_HOST interface)?
