WG peers won't connect

Jarhead

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.

arjay

@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.

Jarhead

@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??

arjay

@jarhead

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.

Jarhead

@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.

Jarhead

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.

arjay

@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.

Jarhead

@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?

arjay

@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.

Jarhead

@arjay Post pics of the config.

saf2030

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)

Jarhead

@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.

arjay

@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

Bob.Dig

@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.

Jarhead

@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.

saf2030

@jarhead Hi My WG configurations work perfect I was responding to Arjay, Thanks Stephen
File to big to upload however you can download here if you like (PD005)

https://sflynn.substack.com/i/85683721/pd-wireguard-and-tailscale-ftw-p-wireguard-on-pfsense

arjay

@jarhead my general test ist to disconnect from pfSense and go from Wlan, same with the phone. So I was doing that all along.
Again, the NAT is what Lawrence systems recommended when not using an interface. And since as you say the rules permit anything it doesnt hurt and this would be the indication on any traffic here too.
So, still searching for a proper way to debug this and stop changing configs by chance.
So of course I can delete all the permit rules but that will not be the root cause.
In general I also use the phone so I dont have to switch network adapters for testing. I even duplicated the Wireguard and put down the WG on my VM. Didn't help. I can show you the first couple of letters of the keys, but I can definitely exclude this as the issue. Also I should see traffic on the interface in either case..

Jarhead

@arjay Not NAT, but outbound NAT.
Did you add that?

arjay

@jarhead i will not have access for the next 5 days. I will take a look again afterwards.