This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

SNAT not working, getting NAT 0

Help please, 

I have internal server 192.168.99.168 SNAT to x.x.x.168

I have internal server 192.168.99.169 SNAT to x.x.x.169

I have both x.x.x.168 and x.x.x.169 setup as aliases on WAN1 

Here is the SNAT rule and its setup identically for the .169

When they try to send email this is the packet capture showing NAT rule 0 is being applied and it's NOT leaving the device as evidenced by no outgoing port. You also see the DNAT is working. 

Any ideas? Please help



This thread was automatically locked due to age.
Parents Reply Children
  • Who is initialize the traffic? Because right now, this rule seems to pick up the traffic and of course we are not using SNAT, because its not configured.

    XG is stateful, which means, a connection (depending from the initial connection start) will be threaded with the same rule for the entire traffic.

    So if a somebody uses your DNAT to your Client, XG will always use this NAT Rule (15) for the entire connection.

    SNAT Should not be needed, as the client interact with this IP anyway (Port2:4). You cannot force the client to interact with another IP midflow. 

    Or does your SNAT from your 192.168.99.168 to a internet IP does not work? 

  • How is SNAT not configured? I sent a screenshot of the SNAT. It seems my SNAT from my 192.168.99.168 to a internet IP does not work because the rule hasn't been used even once.

    DNAT works in that traffic hitting port2:4 is translated  to 192.168.99.168 via rule 15 but when 192.168.99.168 responds it doesn't go out any port as seen in the traffic capture.

    The thing is the client wants traffic from 192.168.99.168 to hit the cloud server as x.x.x.168.

    WAN1 is x.x.x.162 with an alias of x.x.x.168 so I was translating traffic from 192.168.99.168 to x.x.x.168 and then passing it to the WAN1 gateway. This same configuration works with another client who confirms the traffic from the internal server is seen as the alias address. 

    So what is happening is, this client can receive email, but sent emails from 192.168.99.168 email server fail.

  • Email send via SMTP? 

    Can you perform a conntrack and tcpdump and verify, which NAT is used for outbound?

  • Its currently not in production, that will take a while. Will that show something different than the packet capture showing NAT 0?

  • Conntrack will show you the entire connection. It will also show you the NAT was used. 

    If there is also NAT=0 , your matching criteria are not met. 

    So you have to expand those matching criteria and look for the issue in the SNAT rule. 

    At least your Default NAT rule should pickup the traffic.