Guest User!

You are not Sophos Staff.

Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 39 replies
  • Subscribers 28 subscribers
  • Views 3883 views
  • Users 0 members are here
Options
Suggested
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

XGS 2100 Loopback NAT

Robert Reid

We are looking to deploy an HA pair of XGS2100 firewalls to our data centre. My issue is I cannot get a loopback NAT to work when I am starting the conversation from the same zone as the destination server is in. IF the loopback is to a different zone all is good.

I have googled this for hours and spent hours on the phone with support to no avail. I do have a support ticket open already but I hoping someone might have some additional insight into this.

The Firewall currently have 18.5 MR1 installed.



This thread was automatically locked due to age.
Parents Reply Children
  • 0 in reply to LuCar Toni

    We have cloud servers (RDS) that need to be able to connect to servers in the same network using either the public DNS name or the public IP address.  We currently have Sophos SG firewalls here that have no problem accomplishing this task and every other firewall vendor I have ever used has no issue with loopback/hairpinning. I believe at one point I also had this working on an XG firewall. 

    Without loopback working these firewalls will not be a fit for our deployment and we will have to stay with the SGs.  

  • 0 in reply to Robert Reid

    This should be possible, no problem. But you need always to use SNAT. Without SNAT; the loopback packets will go directly, causing issues within the network. 

    Your first Screenshot should use MASQ as SNAT. 

  • 0 in reply to LuCar Toni

    As said before we have tried it both ways and it doesn’t work either way.  Either way when I do a packet capture on the destination device I do not see any packets from the source.   And in true hairpinning you should not have to source nat.  

  • 0 in reply to Robert Reid

    From my understanding, SNAT is required on most products, because otherwise it will break stateful firewalling.

    If you come from a client (192.168.1.1) and talk to the WAN IP (1.2.3.4), XG will redirect it to the Server (10.0.0.1).

    If you do not use SNAT, the traffic will get to the server with 192.168.1.1. It will send it back to the 192.168.1.1 directly. Therefore the server expect 1.2.3.4 to communicate to him, but in fact the handshake will be send back from 10.0.0.1. Therefore you need a SNAT. 

  • 0 in reply to LuCar Toni

    Again I have tried with and without snat. Neither work. In my scenario the two machine are in the same subnet. 

  • 0 in reply to Robert Reid

    That is even worse. Without SNAT this will not work. Try a tcpdump on the appliance on the port and check what is going on. I assume the tcp handshake is not correct. 

  • 0 in reply to LuCar Toni

    That has already been done the firewall is not getting return packets and running  wireshark on the destination host there are no packets being sent to it like the firewall is not forwarding the packet. This happens wether the snat is on or off.  Loopback is not working on this model. I know how it works, I understand the concept and I’ve worked with and made it work on multiple different firewall vendors including the Sophos SG and I believe even Sophos XG.  It is not working on the XGS when going to the same LAN it works fine going to a different zone.  

  • 0 in reply to Robert Reid

    Whats the tcpdump on the firewall? Please show us the tcpdump. I have a loopback on my XGS. There is no different. There has to be a configuration issue. 

  • 0 in reply to LuCar Toni

    When I get to the office in a few hours I will do that.  Are there any particular parameters you would like added.?

    is your loopback going to the same subnet? Cause I’ve spent hours on this and have not had any luck   

  • 0 in reply to Robert Reid

    Yes. It uses a NTP Loop back. I am using a NTP loopback. 

    Do a tcpdump -ni any port (used service). 

    Then open the connection on your client.