Hairpin routing NAT

Hi, Tim, and welcome to the User BB!

Alone among Live Logs, the Firewall Live Log presents limited information in a more-readable format.  It's not much good for analysis though, so please post the same line from the full log file.

If you have a NAT rule for this, please [Go Advanced] below and attach a picture of it.

Cheers - Bob

There is no nat rule for this, although I'm sure I need one.

2013:06:11-08:21:13 fwall ulogd[3368]: id="2012" severity="info" sys="SecureNet" sub="packetfilter" name="strict TCP state" action="strict TCP state" fwrule="60009" seq="0" initf="eth0" outitf="eth0" dstmac="00:15:17:24:aa:30" srcmac="00:03:47:71:5d:3d" srcip="192.168.25.21" dstip="10.10.39.138" proto="6" length="52" tos="0x00" prec="0x00" ttl="127" srcport="3389" dstport="51503" tcpflags="ACK SYN" 

2013:06:11-08:21:15 fwall ulogd[3368]: id="2012" severity="info" sys="SecureNet" sub="packetfilter" name="strict TCP state" action="strict TCP state" fwrule="60009" seq="0" initf="eth0" outitf="eth0" dstmac="00:15:17:24:aa:30" srcmac="00:03:47:71:5d:3d" srcip="192.168.25.21" dstip="10.10.39.138" proto="6" length="52" tos="0x00" prec="0x00" ttl="127" srcport="3389" dstport="51503" tcpflags="ACK SYN" 

2013:06:11-08:21:23 fwall ulogd[3368]: id="2012" severity="info" sys="SecureNet" sub="packetfilter" name="strict TCP state" action="strict TCP state" fwrule="60009" seq="0" initf="eth0" outitf="eth0" dstmac="00:15:17:24:aa:30" srcmac="00:03:47:71:5d:3d" srcip="192.168.25.21" dstip="10.10.39.138" proto="6" length="52" tos="0x00" prec="0x00" ttl="127" srcport="3389" dstport="51503" tcpflags="ACK SYN"

I assume I need to create a NAT rule
Network Security -> NAT -> DNAT/SNAT
When I try to create a SNAT rule I get "You did not enter all required data, or one or more settings are syntactically invalid."

Name: Donegal Crossover
Group: >
Name: Donegal Crossover
Position: Bottom
Traffic Source: sn.donegal_10/8    ***10.0.0.0/8***
Traffic Service: Any
 Traffic Destination: Internal (Network)   ***192.168.25.0/24***
 NAT mode: DNAT (Destination)SNAT (Source)Full NAT
Source:
Source Service:
Log initial packets:
Automatic packet filter rule:

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

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)

That was my guess, too, Drew, but I got the impression that he had a Static Route and maybe an Additional Address on the Internal interface because I would have expected a DNAT to cause a "mysterious" routing problem instead of a TCP state violation.

Tim, I know Drew's suggestion will solve your problem, but I'm still curious what was done to get those packets routed correctly but blocked.

Cheers - Bob
PS KnowledgeBase article: Accessing Internal or DMZ Webserver from Internal Network

"Use strict TCP session handling" will cause fwrule 60009. Turn it off and see what happens.

In this case hairpin routeing is when the Internal interface (192.168.25.1/24) of the Astaro is the default gateway for all the hosts in that subnet, but there is a seperate router on that subnet (192.168.25.222/24) with a second subnet behind it (10.0.0.0/8).

So when a host on the 192.168.25.0/24 network wants to get to a host on the 10.0.0.0/8 network it will send packet to it's gateway (Astaro Internal Interface) and Astaro needs to route that packet to the other router at 192.168.25.222

I turned off "Use strict TCP session handling" and that did not seem to help.

To be clear this does not appear to be a routing problem, icmp works, rdp does not.

As far as NAT goes, I don't want this traffic NAT'd at all, just routed while retaining the source and destination IPs

Hi Tim,

That's not hairpin routing in any sense of the term as I know it.

I have a similar setup at several of our offices where my Astaro is the default gateway, but points to a secondary router for specific IP ranges. I've achieved that using static routes in the astaro, no need for NATing the traffic.

Can we get a detailed diagram of your setup? Might make it easier to understand what's going on.