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

DeanH
DeanH Posts: 23  Freshman Member
edited April 2021 in Security
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.

Accepted Solution

All Replies

  • DeanH
    DeanH Posts: 23  Freshman Member
    Well, I guess it just needed the old kick.  I rebooted it after hours and everything appears to be working again.
  • Zyxel_Cooldia
    Zyxel_Cooldia Posts: 940  Zyxel Employee
    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
    DeanH Posts: 23  Freshman Member
    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
    PeterUK Posts: 1,344  Guru Member
    diag-info is in maintenance > diagnostics > click collect take about 5mins then go to files tab. 
  • DeanH
    DeanH Posts: 23  Freshman Member
    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.
  • DeanH
    DeanH Posts: 23  Freshman Member
    Thank you for that data.

    I will definitely do this if it occurs again.

Security Highlight