Bug #15535
closed
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 29 days 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 27 days 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.