SRX

Diagram

         /\/\/\/\/\/\/\/\/\
        |       WAN        |
         \/\/\/\/\/\/\/\/\/
                     |
192.168.1.0/24       |
SRX Chassis Cluster  |
+--------------------------+
|SVCS          MGMT        |
|reth1.0       reth2.0     |
|10.1.0.1      10.2.0.1    |
+--------------------------+
      |              |
 /\/\/\/\/\/\   /\/\/\/\/\/\
|SVCS       |  |MGMT       |
|10.1.0.0/24|  |10.2.0.0/24|
 \/\/\/\/\/\/   \/\/\/\/\/\/

 Host1-10       Host2-30
 10.1.0.10      10.2.0.30

 Host1-20
 10.1.0.20

Diagram Notes

• 192.168.1.0/24 represents a public IP block routed to the SRX Chassis Cluster
• A one-to-one relationship for 192.16.1.10-to-10.1.0.10 is configured via Static NAT
• proxy-arp is configured but is unnecessary due to the public block being routed to the SRX. While it is currently configured, the issues described below persists even if it is disabled

Goals

1. (Working) WAN to Static NAT SVCS host
   1. Internet ping 192.16.1.10/Host1-10
   2. Internet ssh 192.16.1.10/Host1-10
2. (Working) SVCS to Static NAT SVCS host
   1. 10.1.0.10/Host1-10 ping 192.16.1.10/Host1-10
   2. 10.1.0.10/Host1-10 ssh 192.16.1.10/Host1-10
   3. 10.1.0.20/Host1-20 ping 192.16.1.10/Host1-10
   4. 10.1.0.20/Host1-20 ssh 192.16.1.10/Host1-10
3. (Working) MGMT to Static NAT SVCS host
   1. 10.2.0.30/Host2-30 ping 192.16.1.10/Host1-10
   2. 10.2.0.30/Host2-30 ssh 192.16.1.10/Host1-10
4. (Working) SVCS to MGMT host
   1. 10.1.0.10/Host1-10 ping 10.2.0.30/Host2-30
   2. 10.1.0.10/Host1-10 ssh 10.2.0.30/Host2-30
5. (Mostly Broken) SVCS to MGMT interface on SRX Chassis Cluster
   1. (Working) 10.1.0.10/Host1-10 ping 10.2.0.1/SRX
   2. (Broken) 10.1.0.10/Host1-10 ssh 10.2.0.1/SRX

Items 1-3 above are also known as Hairpin NAT

Issue

There seems to be a nasty interaction between Static NAT and traffic destined for the SRX Chassis Cluster itself.

• (?) Why does ssh work to a host in the MGMT zone (item 4.2 above), but not to the SRX interface in the MGMT zone (item 5.2 above).
• (?) Why does ping to the SRX interface work (item 5.1 above), but not ssh (item 5.2 above).

If I disable static NAT for the MGMT zone then it fixes item 5.2 above, but breaks items 4.1 and 4.2

The show security flow session information for ssh to the SRX interface (item 4.2 above):

  In: 10.1.0.10/41314 --> 10.2.0.30/22;tcp, If: reth2.0, Pkts: 25, Bytes: 4563
  Out: 10.2.0.30/22 --> 192.168.1.2/41314;tcp, If: reth1.0, Pkts: 22, Bytes: 3871

The show security flow session information for ssh to the SRX interface (item 5.2 above):

  In: 10.1.0.10/37995 --> 10.2.0.1/22;tcp, If: reth1.0, Pkts: 3, Bytes: 180
  Out: 10.2.0.1/22 --> 192.168.1.2/37995;tcp, If: .local..0, Pkts: 0, Bytes: 0

Note the 0 packets and 0 bytes.

Configuration

[security nat]
source {
    rule-set Hairpin {
        from zone [ MGMT SVCS WAN ];
        to zone SVCS;
        rule hairpin-source-match {
            match {
                source-address [ 10.1.0.0/24 10.2.0.0/24 ];
            }
            then {
                source-nat {
                    interface;
                }
            }
        }
    }
}
static {
    rule-set Static-Rule {
        from zone [ MGMT SVCS WAN ];
        rule Host1-10 {
            match {
                destination-address 192.16.1.10/32;
            }
            then {
                static-nat {
                    prefix {
                        10.1.0.10/32;
                    }
                }
            }
        }
    }
}
proxy-arp {
    interface ge-0/0/4.0 {
        address {
            10.1.0.10/32;
        }
    }
    interface ge-5/0/4.0 {
        address {
            10.1.0.10/32;

        }
    }
}

Thank you Cogenesis

Thank you Cogenesis, for linking to the How to setup Hairpin NAT knowledge base article. It helped narrow down the issue!

Changelog

2014-03-13: Superfluous network segments removed. Hairpin NAT incorporated. Goals expanded and clarified.

2014-03-07: Initial post

#staticnat
#.local..0

love the ascii !

have you gone through the nat hair pinning KB?

http://kb.juniper.net/InfoCenter/index?page=content&id=KB24639&smlogin=true

Thank you Cogenesis, the KB you linked to improved the behavior, but did not resolve the primary issue. I updated the Post to try to clarify the primary issue.

Additional Information

The reason that SSH traffic and ICMP behave differently is because:

• ICMP is handled by the Packet Forwarding Engine (PFE)
• SSH is handled by the Routing Engine (RE)

Won't Fix

Juniper does not support this configuration. JTAC does not consider the Static NAT behavior described as a bug in the Routing Engine (RE). I don't, therefore, expect the behavior will ever improve.

Mitigation options

• Restructure network topology so that hosts only connect to the SRX on the interface for their subnet (so that no NAT is performed)
• Repalce Static NAT with a combination of Source NAT and Destination NAT. This allows Source NAT exclusions via rules with source-nat off.