[EnigmaCurry]

> Many home routers try to preserve the source port in external mappings. This is a property called “equal delta mapping” – it won’t work on all routers but for our algorithm we’re sacrificing coverage for simplicity.

It is precisely this point that has flummoxed me when connecting my p2p wireguard config[1] with a friend that uses a pfsense router, no matter what we tried, pfsense always chooses a random source port.

But in the simple case this blog outlines, if both ends use the same source port, this method punches through 2 firewalls effortlessly:

[1] https://blog.rymcg.tech/blog/linux/wireguard_p2p/

[hdgvhicv]

In my experience, Cisco ASA does source port persistence by default (when it can’t do it then it falls back to random), fortigates can do it (in various ways depending on version, although fallback method in the map-ports doesn’t work), juniper SRXs can’t, unless you guarentee a 1:1 map.

[jonathanlydall]

Does your friend setting up port forwarding on their pfSense not help in your scenario?

[EnigmaCurry]

Yes, that solves it completely. But the exercise we were trying to do was to do it without that.

[hdgvhicv]

You’re getting into birthday paradox territory, throw a few hundred packets in each direction and one will get through

This hs a good diagram to understand the options

https://rajsinghtech.github.io/claude-diagrams/diagrams/netw...

[patjensen]

This is easily solved in your source NAT configuration on pfSense. It's a single checkbox to not randomize ports on outbound flows. This will enable full cone NAT.

You can scope it to just your IPsec service, or whatever it is your hosting, or you can enable full cone for the whole subnet.

It is not DNAT, nor is it port forwarding. If you host a SIP proxy, SBC or peer to peer gaming, it will enable these use cases as well.

https://docs.netgate.com/pfsense/en/latest/nat/outbound.html