SRX

 View Only

IMPORTANT MODERATION NOTICE

This community is currently under full moderation, meaning  all posts will be reviewed before appearing in the community. Please expect a brief delay—there is no need to post multiple times. If your post is rejected, you'll receive an email outlining the reason(s). We've implemented full moderation to control spam. Thank you for your patience and participation.



Expand all | Collapse all

Issue with traffic from internal host with Static NAT to SRX Chassis Cluster interface .local..0

Jump to Best Answer
This thread has been viewed 0 times
  • 1.  Issue with traffic from internal host with Static NAT to SRX Chassis Cluster interface .local..0

    Posted 03-07-2014 08:10

    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


  • 2.  RE: Issue with traffic from internal host with Static NAT to SRX Chassis Cluster interface .local..0

    Posted 03-08-2014 01:42

    love the ascii !

    have you gone through the nat hair pinning KB?

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



  • 3.  RE: Issue with traffic from internal host with Static NAT to SRX Chassis Cluster interface .local..0

    Posted 03-11-2014 13:49
    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.


  • 4.  RE: Issue with traffic from internal host with Static NAT to SRX Chassis Cluster interface .local..0
    Best Answer

    Posted 04-30-2014 08:13

    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.