OpnSense breaking UDP hole punching

[PassionLynx]

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?

[Patrick M. Hausen]

"static port" in the outbound NAT rule.

[PassionLynx]

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?

[zhladik]

Hi,

late answer but I hope it helps someone. I just got the same problem as PassionLynx. I found that as default firewall randomizes the source port on passing packets out. On UDP it can break some apps. Typicaly some streaming or VOIP apps. The reason for this is security by obfuscating info about source port app allocation. But bidirectional UDP traffic needs this to keep the "punch hole" automatically open for bidirectional traffic.

I discovered how to solve this problem. You have two options:

1. If you want to keep NAT more secure, you can create a special Outbound NAT rule only for your app, usually it is enough to specify the destination port or server address and 'STATIC' parameter enabled.

2. You can replace the default NAT rule with a manually configured one with the same parameters as the default one with the difference in 'STATIC' parameter.

Before you are able to make this change you must switch to Manual or Hybrid outbound NAT rule generation

If you can not predict the destination or source address or port, you must use option 2. I think that security risk at this case increase is usually minimal.

[sammyke007]

I'm struggling with this...

Do I also still need to port forward that port (8555 for WebRTC) to my internal IP (192.168.1.21)?