@p-dang thanks, this fixed it!

@netblues I tried that, split dns and used just a simple webservice to try it. Kinda works.. but not really. I think the DNS name might be the problem.

I have Cloudflare as external DNS provider, there I can change the TTL for the record to a minimum of one minute, that might work.
Howerver, the internal name in DNS resolver I cannot change TTL so there it uses the default TTL of 3600 seconds.
So.. leaving the house would break communications for about 15 minutes every time, not so good...

Without using NAT Reflection mode (that do not work for UDP) does anyone know a creative solution to this?

@mipucket So after researching this more it appears that SSDP won't work because multicast isn't supported in WireGuard? There seems to be a bug report generated for this 11 months ago.

Is this correct? Has anyone been able to get UPnP working for a WireGuard client?

Hello, I am in a project that I would like to do.

These are VPN tunnels with Wireguard. There is information on the internet that talks about the client network and the server network and the 2 networks connected by the Wireguard VPN tunnel, but this project that I have has some peculiarities and is also expected to grow easily.

I consult you to start this idea correctly and not have to make changes halfway through the growth.

I have:

Wireguard server installations (server: Ubuntu), behind the server there is an ethernet network (192.168.100.x), where there are servers that collect data from clients.

The engineering facilities, there is the client/server (to be defined) Wireguard (Debian/Ubuntu to be defined), in the ethernet network (range to be defined), there are the engineers who would connect in a timely manner to the clients to make modifications of code.

The client installations, there is a Wireguard client (Peer: Debian), on the ethernet network (range to be defined), there are the computers that have the data.

Peculiarities:

The servers going through Ubuntu + VPN + Debian, would take the data, from the computers of all the clients, that are behind the Wireguard Debian client. Therefore, the servers can connect to all clients. Between clients they cannot be seen. Engineers going through Debian/Ubuntu + VPN + Debian would change code, from all client machines, behind the Wireguard Debian client. Therefore, engineers can connect with all clients.

So seeing the peculiarities, you could recommend me missing IP ranges, as well as 'AllowedIPs' and 'Endpoint' of each 'Peer' and I'm not sure if I would have to configure routing.

Thanks in advance, I'm new here and just looking to confirm that I start the project correctly.

Best regards,
Edu

@cmcdonald Thanks - I'll give it a test!

The easiest solution to prevent the openvpn reloads / restarts is just to disable the Gateway Alarm Actions.

But still unsure why the status > peers endpoint IP is not being displayed correctly, I think it is picking up the previous / old one.

revised-pfsense-crash-dump.txt

@deltaend All great suggestions and I agree with them. Will add this to the list of things to work on.

@hossimo ha glad to hear it's working! Sometimes the simplest mistakes are the hardest to hunt down. I hit that more than I'd like to admit.

@netblues Thanks for the suggestion. As it happens I already had that bit right, but I stupidly overlooked including the 98 subnet as an allowed IP for the WireGuard tunnel - so problem solved! Thanks again.

thanks Chris, now I see where mi mistake is. will try tomorrow.

@tquade What do I do to move this along. I can provide screen captures, logs, etc. This functioned OK prior to 0.1.6.

Ted

@ligistx-0 I test on several hardware platforms, including the 1100. No issues to report in regards to arm platforms.

Can you report your package versions from the WireGuard > Status page ?

WireGuard is a very quiet protocol, meaning that it won't "come alive" unless there is actually traffic to pass down the tunnel.

Hello.

In my case both Pf has public IP, went I setup WG P2P at first I don't have to open ports, WG open the sockets and don't add any value for keepalive.

If I delete all setup and delete WG from both pfsenses, this issue appear, I have to open udp port for wg in one side because start blocking the packets.

My questions is, in a standard setup like this one, do wg open the sockets or we need to open the port in the WAN always?

Or what is the right steps?

To understand more how WG is working, thanks Chris.

@bubbel I see you're using a TAP device, which is L2. WireGuard only operates at L3 so if this protocol relies on L2 ethernet frames, you won't be able to tunnel that through WG without an additional inner tunnel that can pass L2 frames. That is technically possible but not trivial to configure.

@cmcdonald

Thanks for responding. The problem was solved in another thread: https://forum.netgate.com/topic/168357/system-log-tun_wg0-loop-detected?_=1640196156974