No NAT processing for certain packets
-
Hello,
I am experiencing cases when certain UPD packets leaving the WAN interface towards the Internet with private source IP address and not translated to the WAN interface's Public IP.
Event the source port number is not randomized which suggests that these packets are completely bypassing the NAT processing.
What can cause this issue?
Thank you! -
What rules do you have?
What states do you see?
Are you seeing that in a packet capture?
The only time I have seen that is if there is a state conflict preventing an WAN NAT state being created.
-
Hi @stephenw10
Thank you for your answer.I have active automatic rules
And have some disabled NAT rules with destination port 5060
I didn't check the states. I will defintely check the states when it happens again.
If I understand correctly state conflicting happens when two NAT-ed hosts sending packets with same source port number (in my case 5060) to the same remote host. (But even than the source port randomization supposed to resolve such conflict?) However it is not the situation in my case.
I have only one NAT-ed host which is sending packets with source port 5060 to a remote host with destination port 5060, sometimes these packets are leaving the WAN interface without translating the private IP to the WAN interface's Public ip.
There is a bug case with captures which was closed with the same reason.
https://redmine.pfsense.org/issues/15535Because I have only one host which communicates to this remote host, what can be conflicting?
Thank you!
-
Yup you would normally only ever see this when you have outbound NAT rules with static ports set. SIP is typical of that in that clients often use 5060 as the source port. And that there are still some VoIP devices that will only allow connections fro port 5060. NTP also sometimes hits this.
If you have OBN in Automatic mode that shouldn't happen.
-
Thank you in this case it is a bug I think.
Is there a way to reopen a bug ticket or I need to create a new one? -
Is that your bug linked above?
Before reopening that or opening a new one we need to see states and/or packet captures and compare that with the running ruleset.
What pfSense version are you running?
-
Yes, the bug ticket is the linked one.
I took packet captures while the issue was happening as well as after, when I just stopped the SIP traffic for a minute and started again. Probably that pause cleared the state in pfSense, because after that the local SIP client continued sending packets with exactly the same source / destination IP and port (black tcpdump screenshot in the ticket) and has been still working fine.
I didn’t check the states but I am waiting for this to happen again and I will check the state as well
pfSense+ version is: 24.03
-
That's actually your bug report though, you opened it?
If so, yes, the first thing to do there is check the states and rules actually running when you see it.
-
Hi @stephenw10
Yes, I opened that bug report.
The issue has started happening today again. The 10.20.33.1 IP is not translated to WAN IP address.
As you suggested I checked the states.
Filtering on 10.20.33.1:
Filtering on 103.140.134.2:
There are only automatic rules:
Can we reopen the bug ticket?
Thank you!
Best regards -
Were there other open states on the WAN to the same remote IP address and port? Some other internal SIP device?
The most common cause of seeing outbound NAT not applied is that it conflicts with an existing state.
-
Hi @stephenw10
@stephenw10 said in No NAT processing for certain packets:
Were there other open states on the WAN to the same remote IP address and port? Some other internal SIP device?
No. And, even if that was the case the source port randomization should resolve any conflict, in my uderstanding. Correct?
But the answer is no.I kept the pfSense in this state for days, but yesterday I had to restore the service. What I did is just disconnected the SIP server computer's ethernet cable for approx 50 seconds and when I connected back the NAT was working properly.
-
@turrican64 said in No NAT processing for certain packets:
even if that was the case the source port randomization should resolve any conflict, in my understanding. Correct?
Yes, it should. Though only if NAT is working of course. Some old SIP devices only accept 5060 as a source port but that is clearly not the case here since it works fine after reconnecting.
So when this happens it appears to be spontaneous? Not associated with a filter reload perhaps?
The only other situation I have seen something like this is if a state is somehow opened before the NAT rules are loaded. That should not normally be possible unless you have some custom startup items?
-
@stephenw10 said in No NAT processing for certain packets:
So when this happens it appears to be spontaneous? Not associated with a filter reload perhaps?
Yes, spontaneous and it happens every time when I am not even logged in to pfSense, therefore I don't initiate filter reload.
There is not custom startup.
Thank you!
Best regards -
@turrican64 said in No NAT processing for certain packets:
I have active automatic rules
Can you post a screencap of the configuration/'Edit' page of one of these NAT rules? Trying to see the format you've used to define source networks.
-
Those are automatically generated rules, they cannot be edited. By default pfSense creates rules for each internal subnet as source to any interface that has a gateway defined. What is there should be fine.
-
@stephenw10 Then something might be wacky with how the install script/wizard/whatever function created those 'auto-added' rules. I just referenced one of my own boxes and there's a seperate "Auto created rule" for each defined subnet. This may simpy be due to my own topolgy. But the way OP's source networks appear in their NAT rule table looks weird to me.
Regardless, the 'Edit' page can still be accessed even for 'auto-added' rules.
-
In which pfSense version? The actual auto-rules cannot be edited. If you select manual outbound NAT mode a set of user rules are added equivalent to the auto rules that you can edit. Those remain even if set back to auto mode but they only do anything in manual or hybrid mode.
-
@stephenw10 said in No NAT processing for certain packets:
If you select manual outbound NAT mode a set of user rules are added equivalent to the auto rules that you can edit.
That's exactly what I'm seeing then. Disregard, OP!
-
-
Done. Though I still think it must be something causing a state conflict somehow. It's going to be very difficult to reproduce.
I assume you cannot produce this on demand? You just have to wait for it to happen?
