WireGuard on pfSense behind ISP router. Why do I need a static route?
-
@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)?
-
@dangersheep
If the tunnel is established, traffic from WG clients to the server and any local network doesn't logically pass the WAN, only the outer tunnel packets itself do.This traffic only has to enter the WG interface. Therefore it is sufficient to have a proper pass rule on the WireGuard tab.
This this rule at least pfSense itself should respond to clients requests.
Devices in the local subnet could block the access themself though. -
Hmm, I've been going through my settings and I really don't see anything wrong. So frustrating! The only thing I read about a few times is the possible need to NAT outbound traffic on the WAN address, which I've done, to no avail.
I've heard that being behind CGNAT could sometimes cause problems for wireguard, though I would have thought that would have prevented the handshake, too, right? I've emailed my ISP just in case they can help.
Any suggestions as to how I can proceed debugging this? Why is my WG host interface not replying to ping as sniffed on the interface itself? That really implies a problem with the firewall rules, doesn't it? Surely I should see a reply going out at the level of the interface, even if the routing/NAT was wrong?
Thanks for your patience.
-
@viragomann @Bob-Dig
Thank you very much, again, for your help.I seem to have got things working with the simple setup today. The only significant change I made was to UNCHECK the "Disable reply-to on WAN rules" option in the advanced settings, but I doubt this was the reason.
It's tricky because when changing routing/gateway settings, old routes (or perhaps firewall states) seem to remain active for a time, so sometimes the results of my 'trial-and-error' approach are confusing.
Anyway, I can now ping stuff behind the pfsense box.
To get traffic through the tunnel and then out to the wider internet, I seem to need an outbound NAT rule that puts traffic from the tunnel on the WAN address. Does that make sense? I didn't think I'd need that.
-
D dangersheep referenced this topic on
-
We discussed the need (or not!) for a static route/gateway. Isn't that related to the bug report here: https://redmine.pfsense.org/issues/14200 ?
