Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 10 replies
  • Subscribers 2 subscribers
  • Views 15254 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

Hairpin routing NAT

timdoty17545
I'm hairpin routeing off my Internal interface between 2 subnets and can ping but not RDP.  When I RDP from 10.10.39.138 t0 192.168.25.21 I only see return traffic in the logs.

13:51:45         Suspicious TCP state          TCP          192.168.25.21:51485→ 10.10.39.138:52438          [ACK RST]          len=40          ttl=127          tos=0x00          srcmac=00:03:47:71:5d:3d          dstmac=00:15:17:24:aa:30    

Any suggestions?  Something with nat perhaps?


This thread was automatically locked due to age.
Parents
  • 0
    That's not a NAT rule that you need.

    The log only shows blocked packets unless you have a Firewall rule that logs accepted packets.

    initf="eth0" outitf="eth0" - I don't think that's going to work without a little trickiness.  Please show a simple diagram of your network showing the IPs and netmasks on the interfaces.

    Cheers - Bob
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
Reply
  • 0
    That's not a NAT rule that you need.

    The log only shows blocked packets unless you have a Firewall rule that logs accepted packets.

    initf="eth0" outitf="eth0" - I don't think that's going to work without a little trickiness.  Please show a simple diagram of your network showing the IPs and netmasks on the interfaces.

    Cheers - Bob
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
Children
  • 0 in reply to BAlfson
    Hi Tim,

    The most common "Hairpin NAT" or "Hairpin Routing" scenario, as I understand the term, is where you have a server on a private IP but you access it via the firewall's public IP through a Port Forward (DNAT).

    The 'hairpin' comes in when you try to access the same server via it's public IP and you are on the same private (internal) subnet as the server. When the server responds to the request, it sees the same IP subnet as itself in the source IP, so broadcasts the reply directly (ignoring the router). The client PC is expecting a reply from the public IP of the router, so discards the direct reply.

    Normally the solution for a "Hairpin NAT" is a Full NAT rule in the UTM for the internal clients, which rewrites both source and destination IP's. It's main disadvantage is that all internal requests to the NAT'd server will show the router's IP address, not the original client IP, so tracking internal usage within the logs is impossible.

    The second solution to this, used mostly where the NAT'd server in question is public facing and has a DNS name, is to use split horizon DNS. Split horizon basically means that your internal clients see one set of DNS records (showing the private IP of the server) while the external clients see a different set of DNS records (showing the public IP of the server)
Unfiltered HTML