WG peers won't connect
-
Hi,
I'm migrating from a WireGuard setup on a Debian VM in my 192.168 network to a tunnel interface on my pfSense.
The Debian setup works flawlessly and I'm having no issues whatsoever, I simply want to reduce overall complexity in the network.
pfSense WAN is on the 192.168 encapsulating multiple interfaces that are more sensitive.
I've set up a tunnel WG_TUN on the tun_wg interface, added two peers, created the peer configuration on a windows machine and an android phone - all analog to my existing setup.
I create the UDP Pass rule on the Port for the WAN and the any to any pass on the WG_TUN interface. In the firewall rules state details, no packets are caught.
Since this didn't work I also included a hybrid outbound NAT on WAN for the WG port following the Lawrence Systems tutorial. (Port forwarding is turned on on the router of 192.168 of course)
Quite similar is this one here.However, when initiating the connection on the client side no RX data is ever received, upon the TX packets being sent out regularly. I'm stuck at this point for hours and opened the rules pretty much completely, without finding any issues in the logs or diagnostics.
I have pfBlocker and DNSresolver set up superficially until I get this to work properly. But also disabling this was not successful.
I think a first would be to find, where the packets get lost.Cheers,
arjay -
@arjay Not sure what that picture is supposed to do.
Did you add the gateway and static routes?
-
@jarhead I was experimenting with gateway and static route but to no avail.
I'm including some more screenshots for clarityin the current configuration.
Since I've tried multiple approaches this might not be clean, but it needs to work somehow first before I can work from there.
Not sure at this point how gateway and route should be set.Wireguard overview
WAN rule
WG tunnel rule
Wireguard rule
NAT rule
Gateways
Route
-
@arjay On the WAN rule, change the destination to WAN Address.
Is that the entire list of outbound NAT? If so it's missing a lot.
Gateways... Why is the default gateway a private address? Do you have a public address on the WAN?
The WG gateway should be the tunnel address of the other side.
The static routes should be the network from the other side. -
@jarhead
On the WAN rule, change the destination to WAN Address.- Thanks must've changed this along the lines
Gateways... Why is the default gateway a private address? Do you have a public address on the WAN?
- Do you mean the WAN_DHCP gateways? Not really sure. Since the WAN IP comes from the 192.168.2.1 router they might have been set when I configured DHCP configuration on the WAN interface. Haven't touched the pfSense in a while but everything works properly. The real WAN IP is dynamic by the internet provider*. What is missing here?
The WG gateway should be the tunnel address of the other side.
- Can you specify 'the other side'? As far as I understand this needs to be within the interface's subnet and since I'm having multiple peers it would only make sense to use the tunnel host 10.8.0.1
The static routes should be the network from the other side.
- Same here. I can put a static route to every peer of course which doesn't scale, but selecting 10.8.0.0/24 will give me a conflict with the address range on WG_TUN_IF.
-
@arjay said in WG peers won't connect:
Gateways... Why is the default gateway a private address? Do you have a public address on the WAN?
- Do you mean the WAN_DHCP gateways? Not really sure. Since the WAN IP comes from the 192.168.2.1 router they might have been set when I configured DHCP configuration on the WAN interface. Haven't touched the pfSense in a while but everything works properly. The real WAN IP is dynamic by the internet provider*. What is missing here?
I'm sorry, I wasn't thinking about a remote access Wireguard setup.
Delete the gateway and static routes, then delete the interface. Don't need any of that.
Set the tunnel address in the Wireguard / Tunnel/Interface Config/Interface Address.
That will be all you need for the Wireguard setup since the peers you have are fine once you put in the endpoint on them.
The endpoint will be the public IP of the pfSense box.
But now to that, so from what you said, you don't have a public IP on the WAN, is that correct?
What is the "192.168.2.1 router"?
If your pfSense is behind another router you'll have to get the listening port through that firewall also. -
@jarhead
Set the tunnel address in the Wireguard / Tunnel/Interface Config/Interface Address.- That's what you see in post #5.
... you don't have a public IP on the WAN, is that correct?
What is the "192.168.2.1 router"?- Yes, no public IP on the WAN. Like I said pfSense lives inside the 192.168. Managed by the router from the provider. I would use pfSense directly as an overall firewall + router and Wifi host but have no antennas for the machine. Since the pfSense box can't talk whatever FO duplex standard the internet provider modem is putting out I would have to set the now router into 'modem forward' mode and need another router to transmit Wifi somehow. So I'm going this simpler approach which suits my needs.
If your pfSense is behind another router you'll have to get the listening port through that firewall also.
- Makes sense, but I saw that they are not static and can be all over the place with each new connection. I created rule from the WG_TUN interface to any (also the 51820 UDP pass destination is * not WAN at the moment) but no luck with that.
-
@arjay said in WG peers won't connect:
@jarhead
Set the tunnel address in the Wireguard / Tunnel/Interface Config/Interface Address.- That's what you see in post #5.
No, it's not. That's the interface. You were supposed to delete that interface.
Set the address here:
https://forum.netgate.com/assets/uploads/files/1674998936642-wg_status.png... you don't have a public IP on the WAN, is that correct?
What is the "192.168.2.1 router"?- Yes, no public IP on the WAN. Like I said pfSense lives inside the 192.168. Managed by the router from the provider. I would use pfSense directly as an overall firewall + router and Wifi host but have no antennas for the machine. Since the pfSense box can't talk whatever FO duplex standard the internet provider modem is putting out I would have to set the now router into 'modem forward' mode and need another router to transmit Wifi somehow. So I'm going this simpler approach which suits my needs.
What is FO duplex standard??
If your pfSense is behind another router you'll have to get the listening port through that firewall also.
- Makes sense, but I saw that they are not static and can be all over the place with each new connection. I created rule from the WG_TUN interface to any (also the 51820 UDP pass destination is * not WAN at the moment) but no luck with that.
So you'll need a dynamic dns then. You have to have an endpoint in the peers, how else will they know where to connect to??
-
What is FO duplex standard??
- Apparently it's something called supervectoring or VDSL2 used for 250+Mbit/s. Anyways the network card I'm using here couldn't handle it or the negotiation for this subscription can't be registered properly.
That's the interface. You were supposed to delete that interface.
- The interface is set up once the tunnel is created
And I configured it like so.
So you'll need a dynamic dns then.
- dynDNS was set up the whole time, I didn't mention this. But true, it's whether it must be considered in the current configuration other than under 'Dynamic DNS'. I've set it on WAN but also setting it on the WG_TUN_IF didn't help. Status is always valid though.
-
@arjay said in WG peers won't connect:
The interface is set up once the tunnel is created
And I configured it like so.No it isn't. You added that interface and it's not used for remote access. Delete the interface in Interfaces/Assignments.
You set the tunnel address in the wireguard/tunnel settings.So you'll need a dynamic dns then.
- dynDNS was set up the whole time, I didn't mention this. But true, it's whether it must be considered in the current configuration other than under 'Dynamic DNS'. I've set it on WAN but also setting it on the WG_TUN_IF didn't help. Status is always valid though.
You wouldn't use ddns in pfsense, use it in the router that has the public address.
- dynDNS was set up the whole time, I didn't mention this. But true, it's whether it must be considered in the current configuration other than under 'Dynamic DNS'. I've set it on WAN but also setting it on the WG_TUN_IF didn't help. Status is always valid though.
-
This is where you add the tunnel address.
And this is the unassigned interface in Interfaces/Assignments
You assigned the tunnel to an interface, that isn't used in remote access tunnels.
-
@jarhead
Delete the interface in Interfaces/Assignments.
You set the tunnel address in the wireguard/tunnel settings.- I see, however the tutorials also propose that way and I think rule assignment works better with interfaces. Anyways, I deleted the interface and set the IP for the tunnel as 10.8.1/24.
You wouldn't use ddns in pfsense, use it in the router that has the public address.
- Removed dDNS. It's configured it the router with the public IP already.
I can verify that it works here since I have an analog Wireguard configuration running there.
I had really hoped that removing dDNS would make a difference but no success.
-
@arjay Did you do all of my suggestions?
Again, you have a router in front of pfSense, you still need to forward the port through that router to pfSense. Did you do that?
-
@jarhead It's all set accordingly.
Port forwarding is enabled on the router as well otherwise the tunnel there wouldn't work.
So I'm still looking for an angle to figure out where the handshake goes wrong and I feel it's the return side from the host but overall troubleshooting is difficult. -
@arjay Post pics of the config.
-
Here is what I do with WG see links below:
(https://twitter.com/FlynnInfoSec1/status/1618707989090955264?s=20&t=bZB57yltIUhxq615tNBOgA)(https://sflynn.substack.com/p/wireguard-and-tailscale-ftw-p2?utm_campaign=post&utm_medium=web)
-
@saf2030 You need to post pics of YOUR config if you want help.
You can mask the keys but leave the first 5 or 6 characters shown.
What makes you think the tunnel is working?
If you're going by the green up arrow in status, don't. That doesn't mean the tunnel is working, it just means that end of the tunnel is up, not that it's going anywhere. Don't believe me? Create a new tunnel on a port that isn't open through the firewall, you'll still get a green arrow on it.
Post pics. -
@jarhead Here's the config right now. If you're missing anything let me know. DDNS is not configured in pfsense.
Here is the Tunnel and peers
No interface selected for the tunnel
WAN rules left wide open. I know the third rule is covered by the second, but once it's working I can put it back in place.
Rules for Wireguard
And here is the NAT
-
@arjay said in WG peers won't connect:
And here is the NAT
Portforward is wrong here and not needed at all. Wireguard is a service listening on every interface, like the WAN-address.
-
@arjay First, the second rule on your WAN allows everything IN. Just delete it. It has nothing to do with Wireguard and I have no idea what the return channel would be, Wireguard uses the 1 port only.
Delete the NAT. You aren't port forwarding, just need it open on the WAN.
As you can see by the WAN rules, nothing is hitting those rules so chances are the other router is not configured correctly.
Do this, take the laptop with the WG client and connect it to the other routers LAN. So it will be on the same subnet as the WAN of pfSense. In the client config on the laptop change the endpoint to the WAN IP of pfSense.
See if you can connect. If you can, pfSense is configured correctly.
Then you have to start looking at the other router. What make/model is it?
Can you just put it in bridge mode so pfSense gets the public IP?Also, I said leave the first few characters of the public keys visible for a reason. If the connection I suggested above does not work, show the client config on the laptop with the first few characters of all keys visible.