@Bob.Dig I will work on some pics but it's been in a state of evolution as a test network running another scenario at the moment - but when I can switch it back to this I was looking for some things to focus on and try. I used an interface group for NAT rules because one of the tutorials I read showed to do that and said create a group or do rules for every one. Seemed like a group would be best practice then for larger numbers - but you you recommend to just do a NAT entry for each instead?

Traceroute from the outside world: vpsuser@test:~$ sudo traceroute -I a.b.c.164 traceroute to a.b.c.164 (a.b.c.164), 30 hops max, 60 byte packets 1 daniel.domesticagriculture.org.uk (103.144.176.193) 0.518 ms 0.470 ms 0.457 ms 2 wist.lyle.org (103.144.176.143) 0.479 ms * * 3 100.64.101.167 (100.64.101.167) 10.793 ms 10.781 ms * 4 * * * 5 * * * 6 * * * 7 * * * ... 100.64.101.167 is my router's WG client IP

@MartynK that's ok, it's a bit odd that a reboot was necessary. Maybe it was the MTU changes?

My eyes are having a hard time getting beyond 250.0.0.0. Just something about it. I say this as a free thinker that regularly uses 172.20.20.0 or 172.21.21.0 I'm putting my money on a DNS entry feeding a public IP address instead of an internal IP address, and therefore not trying to send the 25 out the tunnel, and then the ISP knocking down the port 25 traffic.

The CPU in the 8200 is a lot more powerful so you see the widget usage in the 1100 far more. That is especially so because the refresh rate can start to hit the time taken to pull the data. Did you try the patch linked above to revert to the previous widget behaviour?

@Bob-Dig EDIT: Changing the default gateway under the "Routing" tab again caused the remote site to be inaccessible via the S2S VPN.

@Gblenn Just tested it with /31 and it works. For route-based IPsec the gateway is created automatically when you assign the tunnel to an interface. I haven't tried with /32 tho. But I tried with larger subnet like /24. I guess it's like what you said, as long as they are on the same subnet it will work. Just that for point-to-point connection with a single transit network it doesn't make sense to use something larger that contains more than 2 IPs.

@dennypage Okay thanks.

@Bob-Dig thanks for your feedback again! Yeah, I think they are assigned properly, unless I'm missing something here and PPPoE actually requires a different assignment. [image: 1719260898527-assigments.png] [image: 1719260903240-gateways.png] Thank you!

@Ratfink Connecting two sites with Wireguard VPN is absolutely doable, and you don't even need fixed IP's for it to work. When you say you have 5 fixed IP's from your ISP, I'm kind of assuming you have your office at your house? Meaning they are both connected to the same fibre? Otherwise, if they are at very different locations, is it still the same ISP? In terms of getting the IP's on the respective pfsense machines, I assume you know how or have instructions from the ISP to do this. Might be MAC based if DHCP for example... Anyway, running pfsense on repurposed HW is very common and can be done "barebone" or virtualized. So you shouldn't have any problems getting to to work on your rack servers, hopefully. So step one is of course getting both machines up and running. And since they will be for different sites and connected via VPN you must make sure to use different LAN subnets on them. Like 192.168.1.0/24 on one and 192.168.2.0/24 on the other. Once you have them up and running you can follow a guide like one of these to set up wireguard. Even though you have fixed IP's it might be a good idea to get two domains, unless you already have that. https://www.youtube.com/watch?v=2oe7rTMFmqc https://www.youtube.com/watch?v=7_gLPyipFkk

Finally! The solution was creating a firewall rule that route the traffic of my Bridge interface through the gateway i have created for the wireguard client.

@JustAnotherUser said in Port Forward over VPN not working....: If you want to go over WAN anyway, assign an interface to the wg instance and enable it at site 2. This brings up a new firewall rule tab for it then. Now go to the "Wireguard" tab, edit the existing rules and change the interface to the new one. I'm not sure what you mean by your last sentence but, I've done the rest. You mean, changing the interface in the filter rule? In Firewall > Rules you will see a tab called "Wireguard". pfSense might have created a rule on this tab automatically, when you set up the Wireguard tunnel. So go to this tab and edit the existing rule and change the interface from "Wireguard" to the interface, which you have assigned to the Wireguard instance before. Then the rule disappears from the Wireguard tab and appear on the new interface tab. Also in the WG settings on router 2 you have to change the "allowed IPs" to 0.0.0.0/0 to accept public forwarded traffic.

@FoolCoconut said in Wireguard + Port Forwarding = Return Traffic exiting through WAN???: Holy f**k. The problem was an any/any rule in the Wireguard unasigned tunnel firewall rule list. Even though the AirVPN WG interface was assigned, group rules are evaluated first... Hope this helps someone else as well. @FoolCoconut THANK you. ive been trying to figure this out for a very long time.

@hspindel Update, finally got the VPN tunnel to work!

Couldn't get dante to work until I found this. For those of you sportsfans keeping score at home, this is still valid/needed for pfSense version 2.7.2-CE and dante-1.4.3_2 circa 2/2025.

@Gertjan said in How do I route outgoing email over WireGuard Tunnel?: Of course I use have DANE available and set up : I just noticed I had to recreate the TLSA records, something with Let's Encrypt must have changed. I hope I am good now for some time...

Yup, those devices are probably not trying to resolve .local addresses using DNS servers at all. They assume they are mDNS and try to find them locally.

@jimp Thank you! Sorry I didn't run across this in my reviews of other forums. That was EXACTLY what I was looking for!