How do you create a loopback/hairpin NAT to an Interface IP?

I am trying to publish multiple services to the Internet.  It is working fine using business rules.  But, I want to be able to add a loopback/hairpin NAT so that if someone inside the network uses the public IP to access the service they are redirected to the internal network.  I would also like this bound to an interface IP and not an IP object because it will not always be a static IP.

  • It is technially possible using Linux Kernel but it may be restricted by Sophos engineers for security reasons. I was unable to use NAT this way but it is possible to make a loop connection to a Web server published by XG. However it is not a NAT of course, but Reverse Web Proxy.

    For other services I have created internal DNS records pointing to the right servers inside LAN. I used built-in DNS service but you can also use another DNS service running on one of those servers and create a fake zone.

    This is not a solution but a workaround.
  • Is there a domain name attached to the public IP address? If so its very easy to do.
  • In reply to Big Ray:

    Yes there is. I just have several services using the same domain name on different ports.
  • In reply to JasonKnott:

    OK that's great then this is very easy, Here is what I did and it works great.
    Login to XG and on the left side select system->DNS now scroll down and under DNS Host Entry click add and enter your full domain name such as abc.com fill in the IP address of you internal server that is hosting the services click save and test. Good luck and please post back the results for others to learn.

    Happy New Year!
  • Please see if this resolves your issue:

    community.sophos.com/.../39478

    For UTM, it was as easy as:

    www.sophos.com/.../115191.aspx
  • In reply to ArunGupta:

    Ok, I made some tests and found definitive answer.

    Yes it is possible. How to do that. Just create a Business Rule for non-HTTP Policy and specify as follows:

    Section: Source

    Host: Any

    Exceptions: none defined

    Section: Hosted Server

    Source Zone: Any

    Hosted Address: #Port2-a.b.c.d

    Section: Protected Application Server(s)

    Protected Zone: LAN (or DMZ)

    Protected Application Server(s): YourServerHost

    Forward all ports: no (off)

    Section: Port Forwarding

    as required

    Section: Routing

    Rewrite source address (Masquerading): Yes (On)

    Use Outbound Address: MASQ (or any NAT policy if you have more than one public IP address)

    Other sections: as required.

    The MOST important is "Hosted Server" section. You MUST select "Any" zone because it defines interface which the traffic will come from (as I understand it). You must also select hosted address from firewall supplied #Port2 (or any other WAN port you use) because this is your public IP.

    If you select Source Zone as WAN you will limit originating connection to come from any interface marked as WAN and automatically disable access to that rule from LAN side.

    I have tested this on IMAP and SSH published to the Internet. When I was connecting from LAN side using external public address, the server reported connection from the XG IP not my LAN workstation IP.

  • In reply to Slawski:

    Thanks for the info. I was wondering for the Hosted Address: #Port2-a.b.c.d, This this your internal or external NIC?
  • In reply to Big Ray:

    It is public IP and the interface is WAN.
  • Slawek, the "Source Any" solution solved the problem for me. Thank you!!
  • In reply to Slawski:

    Thanks for the update.
  • In reply to Slawski:

    Actually the Source Zone could be LAN which works and makes more sense.

  • In reply to ShaunLovatt:

    It depends on you ruleset. If you want to use the same rule from WAN and LAN, LAN alone does not work.

  • In reply to Slawski:

    This is a pretty good answer and a step in the right direction, but by following your steps, all traffic that appears at the destination host will have a source IP of the firewall, which is pretty dangerous for logging and control.

     

    What you could do instead is to create 2 rules. A standard WAN->LAN DNAT Business Application rule (NO MASQ), and the same again, using the source zone as LAN (WITH MASQ).

    This is obviously still not perfect, as the LAN traffic will show up on the destination host as the firewall, but this is arguably a lot safer than all of the WAN traffic, as well.

  • In reply to Josh Leisk:

    That was my final solution until my server went to cloud ;) Haven't updated the thread though.

  • In reply to Slawski:

    Awesome, this just help me resolve my issue today.