Incorrect Source IP From LAN to WAN on WAN Capture, Why?

DeanH

I am working on a USG20W-VPN running v4.35(ABAR 2) firmware that has a PBX behind it registering to a VoIP server.  When capturing the traffic, in the WAN capture, I see the source IP of the initial packet is set to the private IP address of the PBX rather than the public IP address of the ZyXEL as it should.

This is rejected across the Internet due to the private source address.  Only when the PBX times out - after eight attempts - and tries a different server in the VoIP cluster (it is using SRV records for the server cluster IP addresses), is the public IP address used as the source IP address of the packet on the WAN side of the ZyXEL.  But, each time the PBX attempts to register again, the private IP address is used first, then only upon timing out and trying a different server does the ZyXEL change it to the public.

Looking at the LAN side captures, the packets are using the private IP as they should, there is no difference between the packets to one server versus the other - other than the frame number, server IP and server FQDN.  This appears to be a NAT translation problem where it is somehow missing the initial source IP translation, but catches it when a different destination IP/FQND is used after a few attempts.

I have checked the PBX as well, and it is the same as it was prior to this issue occurring.  It is set up to use DNS SRV records to look up the server IP addresses.

Where can I force the ZyXEL to use the public IP as the source IP on traffic sent out to the WAN every time?  I do not see a way to create an outbound NAT based on the documentation I have for the USG20W-VPN.

Zyxel_Cooldia

Hi @DeanH,

When you click “Collect Now”, a series of commands are run to save device status/information in compress file.

No service interruption during collecting diag-info. It will only require minimal CPU usage during the process.

DeanH

Well, I guess it just needed the old kick.  I rebooted it after hours and everything appears to be working again.

Zyxel_Cooldia

Hi @DeanH,
Welcome to Zyxel Community. 

When the issue happens again. Please help us to collect information as below,

1) Capture packets on lan/wan interface.

2) Collect diag-info first when the USG have SNAT issue.

3) Reboot USG. And then collect the diag-info again.

After completed action above, there are two diag-info, one is in problematic status, another is in normal status. With both diag-info, it would be helpful to troubleshoot this issue.

DeanH

Hello Zyxel_Cooldia,

Thank you for your response.

I did a packet capture on both the LAN and WAN interfaces and have those.

When you say "diag-info", is that a particular feature/function?  Or, is there a specific place to find it in the GUI?  I can't find that in the manuals by that name.

PeterUK

diag-info is in maintenance > diagnostics > click collect take about 5mins then go to files tab. 

DeanH

Hello PeterUK,

Thank you for that data.

I found it and did a collection to familiarize myself with the process.

Does this data collection interrupt services at all, or is it passive to normal operations of the unit?

We have multiple customer sites to which we have been deploying these and I want to let my techs know whether they can do this during working hours or not - unless, of course, the unit isn't processing a majority of traffic where it won't matter.

Zyxel_Cooldia

Hi @DeanH,

When you click “Collect Now”, a series of commands are run to save device status/information in compress file.

No service interruption during collecting diag-info. It will only require minimal CPU usage during the process.

DeanH

Thank you for that data.

I will definitely do this if it occurs again.