SRX Services Gateway
Highlighted
SRX Services Gateway

outbound ssh -- and just ssh -- does not work with static NAT

[ Edited ]
‎06-11-2014 11:10 AM

EDIT: the problem was found to be an upstream firewall filter which was only affecting SSH.  Changing the filter resolved the issue.

 

Hello all,

 

I am having a very odd issue right now.  I have a pair of SRX 650s set up as an active/passive cluster, and I have set up a static NAT to connect a server in our trust zone to the internet with a public IP address.  Inbound services all work fine, and all outbound services from the server also work -- all except for ssh.

 

(note: IP addresses have been changed to protect the innocent.)

 

I have configured the static NAT as follows:

 

rule-set nats {
    from zone untrust;
    rule dashboard {
        match {
            destination-address 2.2.151.245/32;
        }
        then {
            static-nat {
                prefix {
                    10.64.151.245/32;
                }
            }
        }
    }
}

 Then from the server itself, I attempt to connect to a known internet server on various ports using telnet.  http and ftp work just fine:

 

user@dashboard-app-1:~$ telnet 1.1.1.82 80
Trying 1.1.1.82...
Connected to 1.1.1.82.
Escape character is '^]'.
^]

user@dashboard-app-1:~$ telnet 1.1.1.82 21
Trying 1.1.1.82...
Connected to 1.1.1.82.
Escape character is '^]'.
220-Security Notice
220-You are about to access a secured resource. OurCompany Security reserves
220 the right to monitor and/or limit access to this resource at any time.
^]

 When I try to connect via ssh, however:

 

user@dashboard-app-1:~$ telnet 1.1.1.82 22
Trying 1.1.1.82...

 It simply hangs like that.  Simply running "ssh user@1.1.1.82" has the same result.

 

During each of these tests, I checked for security flows on the SRX cluster to see if traffic was going, and it does appear to do so.  Again, for http and ftp:

 

user@firewalls> show security flow session destination-prefix 1.1.1.82/32    
node0:
--------------------------------------------------------------------------

Session ID: 246335, Policy name: outbound-access/4, State: Active, Timeout: 1798, Valid
  In: 10.64.151.245/50327 --> 1.1.1.82/80;tcp, If: reth2.0, Pkts: 2, Bytes: 112
  Out: 1.1.1.82/80 --> 2.2.151.245/50327;tcp, If: reth0.0, Pkts: 1, Bytes: 60
Total sessions: 1

node1:
--------------------------------------------------------------------------

Session ID: 414494, Policy name: outbound-access/4, State: Backup, Timeout: 14412, Valid
  In: 10.64.151.245/50327 --> 1.1.1.82/80;tcp, If: reth2.0, Pkts: 0, Bytes: 0
  Out: 1.1.1.82/80 --> 2.2.151.245/50327;tcp, If: reth0.0, Pkts: 0, Bytes: 0
Total sessions: 1

user@firewalls> show security flow session destination-prefix 1.1.1.82/32    
node0:
--------------------------------------------------------------------------

Session ID: 228727, Policy name: outbound-access/4, State: Active, Timeout: 1798, Valid
  In: 10.64.151.245/37341 --> 1.1.1.82/21;tcp, If: reth2.0, Pkts: 4, Bytes: 180
  Out: 1.1.1.82/21 --> 2.2.151.245/37341;tcp, If: reth0.0, Pkts: 3, Bytes: 296
Total sessions: 1

node1:
--------------------------------------------------------------------------

Session ID: 421153, Policy name: outbound-access/4, State: Backup, Timeout: 14404, Valid
  In: 10.64.151.245/37341 --> 1.1.1.82/21;tcp, If: reth2.0, Pkts: 0, Bytes: 0
  Out: 1.1.1.82/21 --> 2.2.151.245/37341;tcp, If: reth0.0, Pkts: 0, Bytes: 0
Total sessions: 1

 And with ssh, the session is there, although the packets and bytes are very low:

 

user@firewalls> show security flow session destination-prefix 1.1.1.82/32    
node0:
--------------------------------------------------------------------------

Session ID: 240870, Policy name: outbound-access/4, State: Active, Timeout: 18, Valid
  In: 10.64.151.245/49328 --> 1.1.1.82/22;tcp, If: reth2.0, Pkts: 2, Bytes: 120
  Out: 1.1.1.82/22 --> 2.2.151.245/49328;tcp, If: reth0.0, Pkts: 0, Bytes: 0
Total sessions: 1

node1:
--------------------------------------------------------------------------

Session ID: 421508, Policy name: outbound-access/4, State: Backup, Timeout: 14408, Valid
  In: 10.64.151.245/49328 --> 1.1.1.82/22;tcp, If: reth2.0, Pkts: 0, Bytes: 0
  Out: 1.1.1.82/22 --> 2.2.151.245/49328;tcp, If: reth0.0, Pkts: 0, Bytes: 0
Total sessions: 1

 When running a trace on the security flows, the only thing I noticed was that there I did not see an ack packet coming back in for the ssh session, but there was one for ftp and http.  I have no idea what could cause that however or how to correct it.

 

So, any ideas what might be causing this?  I can post relevant parts of my configs if anyone wants to see them.  Thanks in advance for any and all help!

2 REPLIES 2
Highlighted
SRX Services Gateway

Re: outbound ssh -- and just ssh -- does not work with static NAT

‎06-16-2014 01:42 AM

Hi msingerman,

 

From the Flow session for SSH , there is no return packets hitting the reverse wing .

 

Session ID: 240870, Policy name: outbound-access/4, State: Active, Timeout: 18, Valid

  In: 10.64.151.245/49328 --> 1.1.1.82/22;tcp, If: reth2.0, Pkts: 2, Bytes: 120
  Out: 1.1.1.82/22 --> 2.2.151.245/49328;tcp, If: reth0.0, Pkts: 0, Bytes: 0 <<<<<<<<<<<<<<< counter 0.

 

so SYN-ACK reply from the server 1.1.1.82 is not making to the SRX.

 

To confirm this: upload the following:

 

1. sampling capture from the Reth2.0 interface or  packet captures taken reth2.0 upstream device .


Through packet captures , we can identify if return SYNACK traffic is dropped by SRX.

 

without captures , it looks more of a Server or upstream issue.

 

Regards,
rparthi
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

[Please Mark My Solution Accepted if it Helped, Kudos are Appreciated Too] .....

Highlighted
SRX Services Gateway

Re: outbound ssh -- and just ssh -- does not work with static NAT

[ Edited ]
‎10-07-2015 01:03 AM

Hi msingerman,

 

I'm experiencing quite the same issue with a M-Series M7i router. Static NAT on a particular host, applied when reaching certain subnets, blocks ssh flows between other subnets that aren't (or at least shouldn't be) concerned by the NAT rules and aren't using the interfaces on which i applied them.

 

Your edit says you found the problem to be an "upstream" firewall filter. Could you please tell me more about it ? What exactly did you change to make it work ?

 

Thanks in advance,

Cedric

Feedback