SRX Services Gateway
SRX Services Gateway

NAT Hairpinning Broken with Proxy ARP

‎06-22-2012 12:08 PM

We have a SRX650 cluster running 11.4R2 with about 30 security zones. Each zone gets its own source NAT address for egress traffic and static NAT for any servers that need to be accessible externally. 

 

We are trying to setup the network so that every server can a) ping its external static NAT IP address from the server itself and b) ping any other server in the other security zones by their external IP address. JUNOS 11.2 implemented NAT hairpinning which means this should all just work, but it doesn't.

 

This is the flow trace when I ping server A's external IP address (2.2.2.19) from server A (10.10.10.178):

<10.10.10.178/12->2.2.2.19/37497;1> matched filter f0:
packet [84] ipid = 0, @43e08524
---- flow_process_pkt: (thd 8): flow_ctxt type 14, common flag 0x0, mbuf 0x43e08300, rtbl_idx = 0
 flow process pak fast ifl 137 in_ifp reth0.10
  reth0.10:10.10.10.178->2.2.2.19, icmp, (8/0)
 find flow: table 0x51fa6bc8, hash 32245(0xffff), sa 10.10.10.178, da 2.2.2.19, sp 12, dp 37497, proto 1, tok 33
  no session found, start first path. in_tunnel - 0, from_cp_flag - 0
  flow_first_create_session
  flow_first_in_dst_nat: in <reth0.10>, out <N/A> dst_adr 2.2.2.19, sp 12, dp 37497
  chose interface reth0.10 as incoming nat if.
flow_first_rule_dst_xlate: DST no-xlate: 0.0.0.0(0) to 2.2.2.19(37497)
flow_first_routing: vr_id 0, call flow_route_lookup(): src_ip 10.10.10.178, x_dst_ip 2.2.2.19, in ifp reth0.10, out ifp N/A sp 12, dp 37497, ip_proto 1, tos 0
Doing DESTINATION addr route-lookup
  packet dropped, no route to dest
flow_first_routing: DEST route-lookup failed, dropping pkt and not creating session nh: 0
  flow find session returns error.
 ----- flow_process_pkt rc 0x7 (fp rc -1)

 You can see that the SRX does a destination route lookup for 2.2.2.19 and then fails. NAT doesn't even happen yet.

 

Here's a show route detail on 2.2.2.19:

inet.0: 150 destinations, 165 routes (150 active, 0 holddown, 0 hidden)
2.2.2.19/32 (1 entry, 1 announced)
        *Static Preference: 1
                Next hop type: Discard
                Address: 0x10bbf54
                Next-hop reference count: 138
                State: <Active Int ProxyArp>
                Age: 10w6d 17:19:59
                Task: RPD Unix Domain Server./var/run/rpd_serv.local
                Announcement bits (2): 0-KRT 2-Resolve tree 1
                AS path: I

The SRX deliberately discards traffic sent to this address. KB24709 says this is "security fix" as of 11.2R1 for addresses being proxy ARPed (why???). 

 

This is where I'm stuck. JTAC has been useless (they keep referring me to KB19400 which is *wrong*). In ScreenOS I could have setup a MIP and have been done days ago. 

 

Here's our NAT config:

nat {
        source {
            pool ZONEA_OUT {
                address {
                    2.2.2.119/32;
                }
            }
            pool ZONEB_OUT {
                address {
                    2.2.2.120/32;
                }
            }
            rule-set ZONEA_OUT {
                from zone ZONEA;
                to zone untrust;
                rule ZONEA_OUT {
                    match {
                        source-address 0.0.0.0/0;
                        destination-address 0.0.0.0/0;
                    }
                    then {
                        source-nat {
                            pool {
                                ZONEA_OUT;
                            }
                        }
                    }
                }
            }
            rule-set ZONEB_OUT {
                from zone ZONEB;
                to zone untrust;
                rule ZONEB_OUT {
                    match {
                        source-address 0.0.0.0/0;
                        destination-address 0.0.0.0/0;
                    }
                    then {
                        source-nat {
                            pool {
                                ZONEB_OUT;
                            }
                        }
                    }
                }
            }
        }
        destination {
            pool SERVERC_NAT {
                address 10.12.12.40/32;
            }
            rule-set DEST_NAT_RULES {
                from interface reth0.999;
                rule SERVERC_HTTP {
                    match {
                        destination-address 2.2.2.12/32;
                        destination-port 80;
                        protocol tcp;
                    }
                    then {
                        destination-nat pool SERVERC_NAT;
                    }
                }
            }
        }
        static {
            rule-set STATIC_NAT_RULES {
                from zone [ ZONE_A untrust ];
                rule SERVERA_NAT {
                    match {
                        destination-address 2.2.2.19/32;
                    }
                    then {
                        static-nat prefix 10.10.10.178/32;
                    }
                }
                rule SERVERB_NAT {
                    match {
                        destination-address 2.2.2.20/32;
                    }
                    then {
                        static-nat prefix 10.11.11.20/32;
                    }
                }
		[...]
            }
        }
        proxy-arp {
            interface reth0.999 {
                address {
                    2.2.2.19/32;
		    2.2.2.20/32;
		    2.2.2.21/32;
		    2.2.2.22/32;
		    [...]
		    2.2.2.253/32;
                }
            }
        }
    }

 

4 REPLIES 4
SRX Services Gateway

Re: NAT Hairpinning Broken with Proxy ARP

‎06-25-2012 06:20 PM

There was a change in 11.2 with regards to proxy-arp behavior.  See below details (you can inform TAC about this - reference Case 2012-0517-0744):

 

:    "The nexthop type of proxy-arp route entries changed from "receive" to "discard" from 11.2."

 

Reason: 

Before this behavior change, we found we can telnet to our device by the proxy-arp address - almost like a back door to our device. The "receive" route can make RE allow telnet access. It’s unsafe for our device. When we add proxy-ndp support in pr 549969, we prefer to set the nexthop type of proxy-arp route to "discard", not "receive". In order to unify the behavior of proxy-arp and proxy-ndp, we also changed proxy-arp’s behavior. (There are other two prs 746457 and 781977 about this issue. 




This behavior change slipped documentation (a slip to mark pr fix it as a external customer visible change so that technical publications can pick it up). We will get it rectified and make sure this gets documented. (the pr will be cloned or new one opened just for tech pubs).

 

In this case we did get NAT Hairpinning to work, so again I suggest when you talk to JTAC have them refer to this case, for the time period around May 22nd:

 

We changed your configuration according to the KB
http://kb.juniper.net/InfoCenter/index?page=content&id=KB19400

 and everything started
working.
- In this case you need not bother about the change in behavior of proxy-arped IP
addresses in the routing table.

 

Hope this info and KB can get you pointed in right direction, as this does work.

SRX Services Gateway

Re: NAT Hairpinning Broken with Proxy ARP

‎08-06-2012 12:42 PM

I'm having issues hairpinning on a SRX240.  I've set this up exactly like KB19400 says to but my webserver is in a seperate zone called "dmz" and not sure if this is causing the issue.  Should this work?  Thanks...

 

On traceoptions here is the error that I see...

 

Aug  6 14:35:26 14:35:25.1269617:CID-2:RT:  packet dropped, no route to dest

 

///////// Configuration ////////////

 

admin@CORPFW1# show security nat proxy-arp
interface reth0.0 {
address {
12.1.1.10/32;
}
}

 

admin@CORPFW1# show security nat static rule-set untrust 

rule-set untrust {
from zone untrust;

rule untrust-webserver {
match {
destination-address 12.1.1.10/32;
}
then {
static-nat prefix 10.160.100.9/32;
}
}

 

admin@CORPFW1# show security nat source pool src_nat_dummy_pool 
address {
192.168.254.1/32;
}

 

admin@CORPFW1# show security nat source rule-set internal-to-dmz
from zone trust;
to zone dmz;
rule webserver {
match {
source-address 192.168.250.53/32;
destination-address 10.160.100.9/32;
}
then {
source-nat {
pool {
src_nat_dummy_pool;
}
}
}
}

SRX Services Gateway

Re: NAT Hairpinning Broken with Proxy ARP

‎09-26-2013 06:06 AM

Hello.

 

I am having the same problem.

 

Sep 26 14:31:23 14:31:23.427211:CID-1:RT: no session found, start first path. in_tunnel - 0x0, from_cp_flag - 0
Sep 26 14:31:23 14:31:23.427211:CID-1:RT: flow_first_create_session
Sep 26 14:31:23 14:31:23.427515:CID-1:RT: flow_first_in_dst_nat: in <reth0.0>, out <N/A> dst_adr 10.10.3.16, sp 39710, dp 3389
Sep 26 14:31:23 14:31:23.427515:CID-1:RT: chose interface reth0.0 as incoming nat if.
Sep 26 14:31:23 14:31:23.427515:CID-1:RT:flow_first_rule_dst_xlate: DST no-xlate: 0.0.0.0(0) to 10.10.3.16(3389)
Sep 26 14:31:23 14:31:23.427515:CID-1:RT:flow_first_routing: vr_id 0, call flow_route_lookup(): src_ip 192.168.200.12, x_dst_ip 10.10.3.16, in ifp reth0.0, out ifp N/A sp 39710, dp 3389, ip_proto 6, tos 0
Sep 26 14:31:23 14:31:23.427515:CID-1:RT:doing DESTINATION addr route-lookup
Sep 26 14:31:23 14:31:23.427515:CID-1:RT: packet dropped, no route to dest
Sep 26 14:31:23 14:31:23.427515:CID-1:RT:flow_first_routing: DEST route-lookup failed, dropping pkt and not creating session nh: 0

 

I created dummy pool for source nat like it's stated in KB19400, but it doesn't help, packet is dropped because route of route action discard. Did anybody find solution for this?

SRX Services Gateway

Re: NAT Hairpinning Broken with Proxy ARP

‎08-22-2015 09:27 AM

Did you actually figure this out?   I'm facing the same problem and can't solve it with a static route or alternate route table...