SNAT not working, getting NAT 0

Is WAN1 = Port1? 

No, Port 1 is LAN Port2 is WAN1

Lucar,

You assisted me in https://community.sophos.com/xg-firewall/f/discussions/122835/xg18-snat-to-wan-alias . I got that Source NAT working and the site has used that source NAT rule over 4,000,000 times. Customer also tested and confirmed communication from the server is seen as the desired alias. 

Back to this discussion: I configured the NAT rule identically but its not even forwarding traffic out any interface now. Also, I don't need the internal 192.168.99.168 server to respond using x.x.x.168, I need all of its external traffic(webmail) to be seen at all times as coming from x.x.x.168. 

NAT is not forwarding anything. NAT is translating traffic. 

Routing stack is responsible for using the correct interface. 

Even if there is no NAT at all, XG will forward the traffic to the interface. 

Ok, so take the packet translate the source IP from 192.168.99.168  to  x.x.x.168 and send it out the WAN1 port. Does it not change the Source IP in the IP header when it does this before sending it to the WAN1 gateway? 

There are independent services running. 

See: https://community.sophos.com/xg-firewall/f/recommended-reads/122357/life-of-a-packet---sophos-xg-v18-0

Basically those services are picking the service as the connection is coming. 

The easy form:

Connection is coming from A to B. 

XG is looking for a NAT (DNAT). 

XG is looking for a Firewall Rule matching.

XG is looking for a Routing decision.

XG is looking for a NAT (SNAT). 

As you can see, one or all could be true and matching. 

What is NAT rule 15? 

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. 

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.