Bug #15535
open
Outgoing packets with Private source IP on WAN
0%
Description
Capture on the WAN interface shows, that there are some packets leaving towards the Internet with Private RFC1918 source IP address and it is not translated to the WAN interface's public IP address.
I noticed this issue during the investigation when my SIP phone system stopped working.
Once the issue starts it keeps happening until I stop sending SIP traffic for a short period. When I start SIP traffic again everything is back to normal, the Private source IP of these outgoing packets are translated correctly to the WAN Interface's Public IP address.
As far as I am aware, this issue only affecting UDP packets with source and destination port 5060, other connections are not impacted, their private source IP addresses are correctly translated to WAN Public IP address.
I have no method to intentionally reproduce the issue, it happens randomly and stays until I stop and start sending SIP packets (UDP S/D Port 5060), therefore once it happen I can keep the system in this state for debugging purpose if needed.
Please let me know if more information is required.
Thank you!
Files
Updated by David G 7 months ago
- File clipboard-202406012259-owrxs.png clipboard-202406012259-owrxs.png added
- File clipboard-202406012303-3th7v.png clipboard-202406012303-3th7v.png added
After stopping and starting the SIP traffic the processing is correct:
Host is sending the same UDP packets with source and destination port 5060 
However the pfSense this time correctly translates 10.20.33.1 to the Public WAN IP address and randomize the source port from 5060 to 25276. The remote host is able to receive the packets and respond.
(As the very first screenshot shows in the previous post the Source port randomization also didn't happen in the problem scenario, the packet was just sent out in its original form on the WAN interface without any NAT processing.)
Updated by Jim Pingle 7 months ago
- Status changed from New to Not a Bug
If you use NAT in such a way that it would try to make two connections use the same conflicting information, it will fail to create a NAT state and the second connection will egress without NAT. The most common way this happens is, as you noted, with static port NAT. Only the first session using the static source port will work, later ones will fail.
For information on how you might reconfigure your setup to avoid the use of static source ports, please post on the forum, or contact TAC if you are a customer.
Updated by Steve Wheeler 5 months ago
- Status changed from Not a Bug to New
This at least appears to be real. NAT is configured correctly and works as expected most of the time. Periodically a connection is opened that does not have NAT applied.
Diagnosis continues here: https://forum.netgate.com/topic/188498/no-nat-processing-for-certain-packets/
Updated by Jim Pingle 5 months ago
Like I mentioned a couple comments up, the way that happens is when something tries and fails to make a NAT state. Usually static port is the easiest way it happens, but that's not the only way. Another way is if they have so many connections to the same remote ip:port that they exhausted their pool of unique external source ports.
Have yet to see any actual proof either way, though. Need to see things like their entire ruleset and state table at the exact moment a packet failed to get NAT applied. They say it's just automatic outbound NAT, but other things can also interfere there like 1:1 NAT, maybe things like siproxd, etc.
Updated by
Updated by David G 5 months ago
- File clipboard-202408042245-ubdou.png clipboard-202408042245-ubdou.png added
- File clipboard-202408042247-v8msq.png clipboard-202408042247-v8msq.png added
There is only one host communicate to this remote IP:Port.
There is no 1:1 NAT
There is no static port configured.
There is no siproxd package installed.
State table for the remote ip at the exact moment a packet failed to get NAT applied:
I retrieved the full ruleset, but I wouldn't expose it publicly. What would be the best way to send it to you?