I cannot figure out why my virtual Sophos XG in Azure is NAT'ing traffic across my IPSec VPN tunnel. There is no NAT rule in place for this. In fact, there's only one NAT rule on the whole XG. But all traffic from my local network, going over the tunnel, gets its source IP translated to the WAN IP of the XG.
Here's a relevant packet capture screen shot, in which you can see that no NAT rule is being applied to ICMP traffic. This is happening with all traffic, for the record. PortA is my LAN port, PortB is my WAN port, and ipsec0 is my IPSec tunnel.
Here's the ONLY NAT rule on the entire XG. "Internal Networks" is a network group that contains only my LAN network. The network definition has been verified multiple times.
Here's my IPSec tunnel. "Corporate Primary LAN Network" has been verified to be accurate multiple times. The tunnel status is all green, and traffic coming FROM the other side of the tunnel behaves properly, without NAT translation. Pings from Corporate work perfectly, but pings from the Azure network do not.
Here's the relevant firewall rule it's hitting on my Azure XG (rule #3). "Internal Secure Networks" is a group that also currently only contains my Primary LAN Network (the Azure LAN). "IPSec Networks" is a group that currently only contains the Corporate Primary LAN Network. There are no filtering or security features turned on for this rule, and it is not linked to my NAT rule.
There are no SD-WAN route rules, no static routes, and I have not manually added any routes via the CLI. This is a fresh install that was created using the Sophos GitHub template here. I've used this template multiple times in the past without issue in nearly identical deployments. I have the no Network Security Groups in my Azure deployment, and I have the standard Route Table in Azure for destination 0.0.0.0/0 in the LAN subnet pointing to Virtual Appliance 10.101.1.4 (my XG's LAN port IP). I can confirm on a VM in that subnet that the traffic is properly hitting the XG then flowing out to the internet using the Public IP assigned to the XG's WAN interface in Azure. Again, I have many of these set up in the past, so this is all nothing new.
Interestingly, my only NAT rule for masquerading traffic out to the internet isn't increasing its usage counter. However, the source IP is being translated anyways, in the same manner that my IPSec traffic is being translated, just out of a different port. (PortB vs. ipsec0)
My route precedence is static, VPN, SD-WAN, confirmed in the GUI and CLI. My original firmware version was 18.5.1, but I tried to upgrade to 19.0.0, with no change. The firewall has been rebooted multiple times.
Here's my full current routing table according to the CLI. I've compared this to known-good firewalls and it seems to be similar.
Thanks in advance...
A two-hour phone call with Sophos support, ending with me being hung up on while on hold, resulted in no resolution. They gave me a Case ID, but the ID did not show up in my Support Portal, nor did I get an email notification. I created my own support request with a new Case ID, and referenced this post as well as the original Case ID I was given, but didn't hear back in 24 hours.
Since this was getting more and more critical by the hour, I kept digging. After going through various CLI commands to try to parse my NAT'ed traffic (come on Sophos, disabling the netstat-nat command??), I stumbled on another problem: My 30 day trial license had never been applied. I had selected "I don't have a serial number (start a trial)" when I created the firewall several days ago, but apparently MySophos thought that serial number had already had a 30-day trial applied to it. I don't know if virtual XG's randomly generate a serial number, if they pull a serial number from Sophos, or if they all generate the same serial, but MySophos would not let me set up a new 30-day trial against that serial number.
Wondering if the issues were related, I dug further. Apparently, as of v18, a firewall without a valid license or an expired license, will DISABLE all NAT rules, and then APPLY ITS OWN NAT RULES INSTEAD. These rules don't show up in your NAT rules list, nor do they show up in packet captures. These NAT rules will masquerade pretty much all traffic, even from LAN to LAN, where no masquerading typically takes place in 99% of networks. Here's an article in Sophos Community spelling out the specifics:
Despite the article saying "No VPN cannot be established", I was still able to establish an IPSec VPN tunnel, and I was still able to send traffic through it from my Corporate side to my Azure side without issue. The article also does not specifically say that traffic between LAN and VPN gets masqueraded, but it sure looks like that's happening to me. I'll update this post again if the new license fixes it, whenever Sophos gets back to me about that.
I was about to ask you about your base license. The base license or a system IPsec Rule are the only indicator to result in such NAT.
This case is actually rare, as Hardware Appliance will not expire (they do not have a Base License Trial).
Instead only software Appliance can expire or be deactivated (due 90 Days no contact to the sophos licensing backend server).
If you select "Dont have a serial number" it should be a 30 days xstream protection trial. You can double check this by checking the /log/licensing.log.
__________________________________________________________________________________________________________________
Sophos Support was able to transfer an old license of mine to the new virtual XG, and after doing a license sync and a "conntrack -F", everything is working as it should.
For the future, some kind of banner along the top of the NAT rules page, the firewall rules page, and the IPSec tunnels page would be helpful, similar to the banners that come up along the top of Advanced Protection or Zero Day Protection when you don't have a license for those. But that's for the Ideas / Feature Request site.