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
- (Working) WAN to Static NAT SVCS host
- Internet ping 192.16.1.10/Host1-10
- Internet ssh 192.16.1.10/Host1-10
- (Working) SVCS to Static NAT SVCS host
- 10.1.0.10/Host1-10 ping 192.16.1.10/Host1-10
- 10.1.0.10/Host1-10 ssh 192.16.1.10/Host1-10
- 10.1.0.20/Host1-20 ping 192.16.1.10/Host1-10
- 10.1.0.20/Host1-20 ssh 192.16.1.10/Host1-10
- (Working) MGMT to Static NAT SVCS host
- 10.2.0.30/Host2-30 ping 192.16.1.10/Host1-10
- 10.2.0.30/Host2-30 ssh 192.16.1.10/Host1-10
- (Working) SVCS to MGMT host
- 10.1.0.10/Host1-10 ping 10.2.0.30/Host2-30
- 10.1.0.10/Host1-10 ssh 10.2.0.30/Host2-30
- (Mostly Broken) SVCS to MGMT interface on SRX Chassis Cluster
- (Working) 10.1.0.10/Host1-10 ping 10.2.0.1/SRX
- (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