SRX

Hello colleagues!

Does anyone have an idea on how to access srx device using its wan ip address?

Also I have some internal servers which are available through DNAT. And I managed to get access to them using public addresses thanks to one, two and three. However, the initial problem isn't resolved.

Hi,

Do you just mean for management accessing over SSH?  If so make sure you have enabled SSH as a host inbound system service on the untrust interface.  You should then be able to use something like Putty to connected via IP.

It's a good idea to also use a firewall input filter so only allowed IPs can access the device.

Yes, I mean ssh management access. SSH system service is enabled and I can access juniper srx from external network (or branch offices). Nevertheless, I can't do it from LAN where juniper srx is located.

user@r2# show security zones security-zone trust                                                
address-book {
    address server x.x.x.x/32;
}
host-inbound-traffic {
    system-services {
        all;
    }
}
interfaces {
    fe-0/0/4.0;
}

[edit]
user@r2# show security zones security-zone untrust      
screen untrust-screen;
host-inbound-traffic {
    system-services {
        ike;
        ssh;
    }
}
interfaces {
    fe-0/0/0.0 {
        host-inbound-traffic {
            system-services {
                ssh;
                ike;
                ping;
                https;
            }
        }
    }
}

Not really sure what you are asking in this post. According to the config shown below traffic destined for the SRX will be allowed in on the fe-0/0/0 I/F if it is ssh, ike, ping or https. You don't have any other I/F's shown in untrust zone (in what you pasted) so the first setion of the host-inbound-traffic rules doesn't accomplish anything.

In the trust zone traffic destined for the box coming in fe-0/0/4 will be allowed. As you have have host-inbound all then any traffic type will be allowed. 

So what is failing? Are you trying to come in through the trust zone I/F fe-0/0/4 but reach fe-0/0/0? For that to work will require a security policy.

Thank you for the answer. You're right on security zones.

There are two interfaces. Fe-0/0/0.0 (external) in untrust zone. Let's suppose that it's IP is 1.1.1.1. Fe-0/0/4.0 (internal - LAN) in trust zone. LAN is 192.168.20.0/24.

I need to be able successfully run "ssh user@1.1.1.1" from hosts in LAN.

user@r2# show security policies from-zone trust to-zone untrust         
policy trust-to-untrust {
    match {
        source-address any;
        destination-address any;
        application any;
    }
    then {
        permit;
    }
}

Well just based on the config snippet shown it should certainly work. You obviously allow ssh traffic on untrust fe-0/0/0 and your trust to untrust rule will allow it to flow out. I wonder if your NAT rules are involved.

Yes, simple source NAT to the interface IP. I have 2 Juniper SRX and both of them behave similarly. I suppose that it is a typical situation which can be gotten around.

I can successfully ssh to the fe-0/0/4.0 interface from LAN, but not to the fe-0/0/0.0.

Hi

When trying SSH from inside, did you try to look up your session in "show security flow session"? I assume NAT may be spoiling things for you.

Did you try to SSH from some outside ip?

SSH access from outside is successful.

When I try SSH from inside, I get the following:

user@r2> show security flow session source-prefix 192.168.20.135 destination-prefix 1.1.1.1    
Session ID: 13040, Policy name: trust-to-untrust/4, Timeout: 18, Valid
  In: 192.168.20.135/54707 --> 1.1.1.1/22;tcp, If: fe-0/0/4.0, Pkts: 1, Bytes: 60
  Out: 1.1.1.1/22 --> 1.1.1.1/16837;tcp, If: .local..0, Pkts: 0, Bytes: 0
Total sessions: 1

I believe local host is not being evaluated for NAT. The local zone should be included in the nat destination rule-set context. Add a destination NAT rule set for the local host traffic to match ssh traffic destined for the ssh server’s public IP address.

Assuming that the internal address you want to ssh to is 192.168.20.10 and 1.1.1.1 is the external address. If there is a switch the solution requires a slight modification.

[edit security nat destination]

admin@srx-fw1# show

pool ssh-Server {

    address 192.168.20.10/32;

}

rule-set To-ssh-Server {

    from zone Trust;

    rule ssh-Server {

        match {

            source-address 192.168.20.0/24;

            destination-address 1.1.1.1/32;

            destination-port 22;

        }

        then {

            destination-nat pool ssh-Server;

        }

    }

}

Unfortunately, it didn't help. I tried use DNAT as you wrote and use DNAT+SNAT. Something like this:

[edit security nat source]
      rule-set trust-to-untrust { ... }
+     rule-set trust-to-trust {
+         from zone trust;
+         to zone trust;
+         rule snat-internal {
+             match {
+                 source-address 0.0.0.0/0;
+             }
+             then {
+                 source-nat {
+                     interface;
+                 }
+             }
+         }
+     }
[edit security nat]
+    destination {
+        pool r2-local {
+            address 192.168.20.10/32;
+        }
+        rule-set rs1 {
+            from zone trust;
+            rule r2-ssh {
+                match {
+                    source-address 192.168.20.0/24;
+                    destination-address 1.1.1.1/32;
+                    destination-port 22;
+                }
+                then {
+                    destination-nat pool r2-local;
+                }
+            }
+        }
+    }
[edit security policies]
     from-zone untrust to-zone vpn { ... }
+    from-zone trust to-zone trust {
+        policy trust-to-trust {
+            match {
+                source-address any;
+                destination-address any;
+                application any;
+            }
+            then {
+                permit;
+            }
+        }
+    }

 Nothing helped.

Hi

From show security flow session it is clear that source NAT happens for the session (192.168.20.135 is translated to 1.1.1.1) and the return flow tries to go from 1.1.1.1 to 1.1.1.1 hence session is not working.

I guess this is "by design". To make it work you can turn off NAT for packets going from inside to 1.1.1.1

(match on destination address, NAT action "off" in your rules; make sure everything else is NATed as needed). 

I'm agree that it's "by design". But I don't understand why there is no reverse source NAT mapping in this case.

However, you're right. It was much easier than I thought. After making "source nat off":

user@r2> show security flow session source-prefix 192.168.20.135 destination-prefix 1.1.1.1
Session ID: 16603, Policy name: trust-to-untrust/4, Timeout: 1800, Valid
  In: 192.168.20.135/63678 --> 1.1.1.1/22;tcp, If: fe-0/0/4.0, Pkts: 11, Bytes: 1721
  Out: 1.1.1.1/22 --> 192.168.20.135/63678;tcp, If: .local..0, Pkts: 10, Bytes: 2281
Total sessions: 1

 Thanks everyone.