New forwarded port when NAT state exists
I just spent a bunch of time troubleshooting and then reading several other posts here regarding port forwarding and NAT.
My understanding now is that if you have a simple port forward, say WAN:2000>LAN:2000, that there are issues if you also have an outbound state with dynamic outbound NAT
LAN:2000>(pfsense:13567)>remotehost:2000 which returns traffic to remotehost:2000>WAN:13567>LAN:2000
However, if then remotehost:2000 sends a new stream of data to WAN:2000, rather than simply forwarding WAN:2000>LAN:2000, pfsense drops the packet if it doesn't come to 13567.
This seems very wrong to me. I can't understand why you wouldn't just forward the packet. Mind you, this is all UDP traffic, so there's not connection-state issues in that regard.
At one point a pfsense admin, jimp, jumped into the conversation stating that allowing the port forwarding back "breaks more than it helps".
Can someone please explain to me what exactly this will break?
doktornotor Banned last edited by
Post a screenshot; your description of what you set up sucks.
I realize I probably worded this poorly since I assumed that this topic would be common enough that anyone with an answer to my question would be able to understand what I was saying. I'm sorry. It would take several screen shots with a wall of text explaining them, so let me see if I can quickly better describe the issue.
I have a server listening on UDP port 2000. It also sends traffic out on UDP port 2000 and expects to receive new inbound traffic on UDP port 2000.
I have a simple port forward. Interface WAN, Destination WAN address (220.127.116.11), Destination range from 2000 to 2000, Redirect IP 10.0.0.10, Redirect port 2000
This port forward works perfectly fine. Traffic from a host on the public internet (18.104.22.168:2000) looks like this when traced:
22.214.171.124:2000>126.96.36.199:2000 forwards from 10.0.0.1 to 10.0.0.10:2000
10.0.0.10:2000>188.8.131.52:2000 hits the default gateway of 10.0.0.1 which forwards 184.108.40.206:2000>220.127.116.11:2000
On the server, it sees packets as 10.0.0.1>18.104.22.168 and 22.214.171.124>10.0.0.1
On pfsense, you can see the traffic in tcpdump on both the LAN and WAN interfaces
My Outbound NAT is set to Automatic.
If my server initiates a connection to the machine on the public internet, the Automatic outbound NAT rewrites the packet with a random source port (ex.112233):
10.0.0.10:2000>126.96.36.199:2000 gets sent to the default gateway and then rewritten as: 188.8.131.52:112233>184.108.40.206:2000
The machine on the internet properly replies:
220.127.116.11:2000>18.104.22.168:112233 which pfsense happily forwards along and the server sees as: 22.214.171.124:2000>10.0.0.10:2000
However, and here is my problem, if the machine on the public internet now wants to initiate a new connection with the server, it will send traffic to 126.96.36.199:2000. I can see this traffic hit pfsense. However, it never gets forward out the LAN interface. No packets 188.8.131.52:2000>184.108.40.206:2000 are forwarded. However, during the midst of this, packets from other machines still work. I.e. 220.127.116.11:2000>18.104.22.168:2000 gets forwarded on to 10.0.0.10:2000.
I'm told that there is some reason why it's "supposed" to work this way. I'd like to know what that reason is.
You're probably creating a conflict of some sort by having a static source port equal to the destination port. The proper behavior there is letting the OS pick a random ephemeral port as the source port. The tuple NAT uses is source and destination IP and port. Default outbound NAT translates the source port on outbound traffic to help prevent conflicts in that circumstance from being an issue, but if the traffic sourced from the Internet in to you isn't randomized, depending on specifics it might match some other state and be problematic.
I understand that being an issue in stateful connections on TCP. What I don't understand is why on on a stateless/connectionless UDP connection my very simple port forward can't continue working in all circumstances regardless of whether or not there is any outbound traffic on that port. It shouldn't matter.
Yes. I understand it theoretically conflicts with the NAT states since NAT expects a random/ephemeral outbound port number. But I can't come up with a single good reason it should ever discard the inbound traffic without forwarding it. Can you explain why that would be helpful?
doktornotor Banned last edited by
Because states are still created for UDP. And ICMP… And. Look at the Diagnostics - States.
I know that states are created. It's necessary for the outbound NAT to function properly. But I don't understand why that inhibits the ability to properly forward new connections that come in via the port forward rule. What benefit is there in dropping those packets rather than forwarding them?
sandro.bordacchini last edited by
I faced today what I see as a quite similar issue… and I found a kind of workaround.
I am going to describe my scenario, the issue i faced and the workaround.
I have a multilan and multiwan installation with 2.1-RELEASE.
A lan and a wan are dedicated to VoIP (SIP) traffic. For those not familiar with SIP, it's just traffic on udp/5060 (in this case).
I had a working installation, then I made changes and I decided to reconfigure the firewall rules from scratch.
The SIP server is in the VoIPLAN with an ip address IPPBX.
For outgoing traffic i created a firewall rule on the VoIPLAN interface to send all the udp traffic originated by the IPPBX ip address through the VoIPWAN gateway/connection (VoIPWAN is the dedicated wan with a bunch of public IPs on it and a router that interconnects with the voip provider).
Then i created a Port forwarding rule to allow incoming traffic from VOIPPROVIDER ip address to be natted towards IPPBX (considering port udp/5060). Firewall rule was automatically created.
IPPBX sends periodically an udp packet to VOIPPROVIDER ip and receive an analogue udp packet in reply (sip ping), all on the udp/5060.
That was working fine.
Incoming traffic originated from VOIPPROVIDER towards VoIPWAN ip was unfortunately not forwarded.
Actually i tried to craft some udp packet from another public IP and sent them to VoIPWAN ip: that traffic was forwarded so i started to think that was something related to the originating IP.
Then i figured it out then in this case there were two NAT session conflicting: one dynamic (created by my IPPBX with the periodic sip ping) and one static (created by the port forwarding rule)… in this case, the dynamic one was the first being created. Previously that was the second one: infact, in the first setup of the system, the sip ping was not active but i activated when the firewall was already configured.
So I took these steps in sequence:
stopped the sip ping
cleared all nat entries, in states page, related to IPPBX ip and udp/5060
edited and resaved PF rule and reloaded rules
reactivated the sip ping
Now all seems working… I will confirm tomorrow when i will be in office ;)
If someone wants to investigate this issue, i looked at the states' entries in the not-working and in the working situation and they were slightly different.
VOIPPROVIDER:5060 <- IPPBX:5060
IPPBX:5060 -> VoIPWAN: <randomport>-> VOIPPROVIDER:5060</randomport>
VOIPPROVIDER:5060 -> IPPBX:5060
IPPBX:5060 <- VoIPWAN:5060 <- VOIPPROVIDER:5060
I suppose the "single arrow" mapping is the dynamic one. Maybe since it was already present, it forced the static NAT to use a random port and that made mismatch the portforwarding rule? (this is probably like throwing dice ;D ).