Messages

1

General Discussion / Re: OpnSense breaking UDP hole punching

« on: December 28, 2022, 04:29:10 pm »

Using the "static port" option would mean I had to move from automatically generated outbound NAT rules to manual ones, right?
(I can't create an outbound rule only for the applications in question, because the ports used by p2p applications are most often completely randomized).

And if I understood it correctly, this option means that the NAT then simply uses the internal peer's source port also for behind the NAT, which causes its own share of problems. (Like when two internal peers use the same source port to reach the same host)
Or did I misunderstand something here?

2

General Discussion / OpnSense breaking UDP hole punching

« on: December 28, 2022, 02:20:03 pm »

Hey guys,

I wondered why p2p in many applications just doesn't seem to work and did some digging.
It turns out that for two connections:

- [InternalPeer] -> [ExternalPeer0]:[dstPort]
- [InternalPeer] -> [ExternalPeer1]:[dstPort]

OpnSense uses different source ports from the NAT outgoing. At least as far as I understand, this breaks the UDP hole punching concept, because you contact a STUN server on a specific dstPort and then the server reports the external port you used to the other peer you want to create a direct connection to.
But when you then contact the peer directly, OpnSense uses a completely different srcPort behind the NAT.
So when the other peer sends something to the srcPort with which you contacted the STUN server, it is simply blocked.

Some NATs use a consecutive numbering in the choice for srcPorts, and p2p applications often also attempt eSrcPort+n, but at least from the logs I looked at, that wasn't the case.

Is there any kind of setting to change this behavior for OpnSense?