Junos OS

 View Only
last person joined: yesterday 

Ask questions and share experiences about Junos OS.
  • 1.  SSH to a device behind an SRX Firewall

    Posted 09-25-2021 19:14
    I have a device that is sitting on the trusted side of a Juniper SRX.  I have a NAT built in the SRX for that device.  When I try to SSH to that device I get the following error, 

    ssh_exchange_identification: Connection closed by remote hos

    I do not believe it is and issue with the device, because from the local LAN I can SSH into the device just fine.

    Any ideas on the root cause of this error message?

    Thanks

    ------------------------------
    RICK HOPKIN
    ------------------------------


  • 2.  RE: SSH to a device behind an SRX Firewall

    Posted 09-25-2021 19:24
    There are at least two elements needed for the nat setup and possibly a third.

    As you have done the destination nat is setup.

    You also need a security policy from the ingress zone to the egress zone, this uses the post destination nat address and not the pool address.

    Finally, you may also need to add proxy-arp of the public address is not the physical interface address.

    Full examples are in this document.
    https://kb.juniper.net/library/CUSTOMERSERVICE/technotes/Junos_NAT_Examples.pdf

    ------------------------------
    Steve Puluka BSEET - Juniper Ambassador
    IP Architect - DQE Communications Pittsburgh, PA (Metro Ethernet & ISP)
    http://puluka.com/home
    ------------------------------



  • 3.  RE: SSH to a device behind an SRX Firewall

    Posted 09-26-2021 05:58

    Steve,

     

    Thank you for your response let me share some config snippets.  IP Addresses have changed for security reasons.

     

    set security nat static rule-set rs1 from zone untrust

    set security nat static rule-set rs1 rule Genband match destination-address 2.2.2.2/32

    set security nat static rule-set rs1 rule Genband then static-nat prefix 1.1.1.2/32

    set security nat static rule-set rs1 rule EX4200 match destination-address 2.2.2.3/32

    set security nat static rule-set rs1 rule EX4200 then static-nat prefix 1.1.1.3/32

    set security nat proxy-arp interface ge-0/0/3.0 address 2.2.2.2/32

    set security nat proxy-arp interface ge-0/0/3.0 address 2.2.2.3/32

    set security policies from-zone trust to-zone untrust policy trust-to-untrust match source-address any

    set security policies from-zone trust to-zone untrust policy trust-to-untrust match destination-address any

    set security policies from-zone trust to-zone untrust policy trust-to-untrust match application any

    set security policies from-zone trust to-zone untrust policy trust-to-untrust then permit

    set security policies from-zone untrust to-zone trust policy Genband match source-address any

    set security policies from-zone untrust to-zone trust policy Genband match destination-address Genband

    set security policies from-zone untrust to-zone trust policy Genband match application any

    set security policies from-zone untrust to-zone trust policy Genband then permit

    set security policies from-zone untrust to-zone trust policy EX4200 match source-address any

    set security policies from-zone untrust to-zone trust policy EX4200 match destination-address EX4200

    set security policies from-zone untrust to-zone trust policy EX4200 match application any

    set security policies from-zone untrust to-zone trust policy EX4200 then permit

    set security zones security-zone trust host-inbound-traffic system-services all

    set security zones security-zone trust host-inbound-traffic system-services ssh

    set security zones security-zone trust host-inbound-traffic system-services http

    set security zones security-zone trust host-inbound-traffic protocols all

    set security zones security-zone trust interfaces vlan.0

    set security zones security-zone trust interfaces ge-0/0/5.0 host-inbound-traffic system-services all

    set security zones security-zone trust interfaces ge-0/0/5.0 host-inbound-traffic protocols all

    set security zones security-zone untrust screen untrust-screen

    set security zones security-zone untrust host-inbound-traffic system-services ssh

    set security zones security-zone untrust host-inbound-traffic system-services ike

    set security zones security-zone untrust host-inbound-traffic system-services ping

    set security zones security-zone untrust interfaces ge-0/0/3.0

     

    As you can see, all 3 elements are there, I would also like to point out that the config for the ex4200 works with not issues.  The Genband only breaks when I ssh through the SRX, but even if I ssh to the SRX and then jump to the Genband it works.  So what is it about the NAT that the Genband does not like?

     

    Rick Hopkin
    Magna5
    Network Reliability Engineering Manager     

    469.409.1070 office                                                      
    469.360.4450 mobile
    rhopkin@magna5global.com
    www.magna5global.com 

    signature_1131737021

     






  • 4.  RE: SSH to a device behind an SRX Firewall

    Posted 09-26-2021 12:13
    What is the address object ex4200?  It needs to be the internal 1.1.1.3/32 address.

    You don't need to allow ssh for the inbound services on zones, this is for access to the actual SRX self traffic and does not affect transit.

    And when you attempt the ssh connection what is seen in the session table?
    show security flow session destination-prefix 1.1.1.3/32


    ------------------------------
    Steve Puluka BSEET - Juniper Ambassador
    IP Architect - DQE Communications Pittsburgh, PA (Metro Ethernet & ISP)
    http://puluka.com/home
    ------------------------------



  • 5.  RE: SSH to a device behind an SRX Firewall

    Posted 09-27-2021 10:25

    set security address-book book1 address Genband 1.1.1.2/32

    set security address-book book1 address EX4200 1.1.1.3/32

     

    Again attempted connections to 1.1.1.3 work while attempted connections to 1.1.1.2 do not work.

     

    root@cft01fwl01> show security flow session destination-prefix 1.1.1.3

    node0:

    --------------------------------------------------------------------------

     

    Session ID: 70106, Policy name: EX4200/6, State: Active, Timeout: 1690, Valid

      In: 4.4.4.4/37416 --> 2.2.2.3/22;tcp, If: ge-0/0/3.0, Pkts: 86, Bytes: 6654

      Out: 1.1.1.3/22 --> 4.4.4.4/37416;tcp, If: ge-0/0/5.0, Pkts: 94, Bytes: 12185

     

    However,

     

    root@cft01fwl01> show security flow session destination-prefix 1.1.1.2 

    node0:

    --------------------------------------------------------------------------

     

    Session ID: 70197, Policy name: Genband/5, State: Active, Timeout: 1798, Valid

      In: 4.4.4.4/37419 --> 2.2.2.2/22;tcp, If: ge-0/0/3.0, Pkts: 2, Bytes: 100

      Out: 1.1.1.2/22 --> 4.4.4.4/37419;tcp, If: ge-0/0/5.0, Pkts: 1, Bytes: 52

     

    And the results.

    [rhopkin@bounce01 ~]$ ssh -vv root@2.2.2.2

    OpenSSH_3.9p1, OpenSSL 0.9.7a Feb 19 2003

    debug1: Reading configuration data /etc/ssh/ssh_config

    debug1: Applying options for *

    debug2: ssh_connect: needpriv 0

    debug1: Connecting to 2.2.2.2 [2.2.2.2] port 22.

    debug1: Connection established.

    debug1: identity file /home/rhopkin/.ssh/identity type -1

    debug1: identity file /home/rhopkin/.ssh/id_rsa type -1

    debug1: identity file /home/rhopkin/.ssh/id_dsa type -1

    ssh_exchange_identification: Connection closed by remote host

     

     

     






  • 6.  RE: SSH to a device behind an SRX Firewall

    Posted 09-27-2021 20:11
    Thanks for the data.  This is showing that the SRX side of this is working.  The session is created and the nat occurring as designed.  And the single return packet rejecting the connection is coming from the ex4200 switch.

    On the switch check the loopback interface configuration and look for a firewall filter applied to the input.  Typical name would be protect-re (re for routing engine).  The filter itself with the details will be under firewalls > inet > filter hierarchy.  

    I suspect one is applied here and is limiting ssh to particular subnets.   Check the terms on the filter and adjust as desired.

    ------------------------------
    Steve Puluka BSEET - Juniper Ambassador
    IP Architect - DQE Communications Pittsburgh, PA (Metro Ethernet & ISP)
    http://puluka.com/home
    ------------------------------



  • 7.  RE: SSH to a device behind an SRX Firewall

    Posted 09-28-2021 10:24

    Let me reiterate that I can successfully log into the EX4200 (1.1.1.3) with no problem.  It is the GENBAND (1.1.1.2) that rejects the SSH session through the firewall.  However if I ssh into the EX4200 I can then SSH into the GENBAND.  Perhaps there issome sort of ACL on the GENBAND, I will get someone to check that out more fully.  I did remove the firewall filter from use on the EX4200, but no change.

     

    Thanks again for all your help. 

     






  • 8.  RE: SSH to a device behind an SRX Firewall

    Posted 09-29-2021 06:27
    Sorry I wasn't clear. 

    But the SRX is NOT the source of your block, and is working correctly per the policy and nat.

    When traffic like the ssh connection from the internet to the public ip address on that interface hits the SRX it runs through this process.
    Resulting in your case finding the correct desired policy.  We know this because this session was created 

    root@cft01fwl01> show security flow session destination-prefix 1.1.1.2 

    node0:

    --------------------------------------------------------------------------

     

    Session ID: 70197, Policy name: Genband/5, State: Active, Timeout: 1798, Valid

      In: 4.4.4.4/37419 --> 2.2.2.2/22;tcp, If: ge-0/0/3.0, Pkts: 2, Bytes: 100

      Out: 1.1.1.2/22 --> 4.4.4.4/37419;tcp, If: ge-0/0/5.0, Pkts: 1, Bytes: 52

     This notes that the traffic matches policy Genband..
    And it shows that the static nat was correctly engaged changing 2.2.2.2 to 1.1.1.2
    And that a reply packet came back into the SRX on ge-0/0/5.0

    Thus the reject packet you see on the ssh attempt is coming from a device down stream of the SRX and not the SRX itself.

    If the SRX had been the blocked the ssh session, the following chain of events would have occurred.

    The inbound traffic evaluation at the policy step would find a reject policy evaluation step would find one of two outcomes and neither of these will create a session as we have above.
    1- A policy does not exist for the traffic at all.   The default blocking behavior will kick in.
    In this case the traffic is silently dropped and you would just time out. 
    And there is no session, log or any other activity for the traffic to see.

    2 - A policy to block the traffic exists.   This will not create a session and will only log activity if the log on session-init option is set on the policy.  Logs can be seen in the messages file.
    This has two options:
    A - The policy uses the deny action and it will silently drop the traffic with no response as the default does.  The user session just times out.
    B - The policy uses the reject action and it does send a response closing the tcp session and blocking the traffic. 

    So the only way the SRX would be the responder blocking the ssh session you have is if there were a policy with the reject action matching the traffic without any policy allowing the traffic in the chain before this policy.

    So the block of the ssh session you see is coming from down stream of the SRX.  This could be from a security appliance in the path.  But is most likely because a protect-re firewall filter is applied on your ex4200.  But in any case, the SRX is working and permitting the traffic.

    The protect-re filter best practice is to create an ssh term that limits the source address  to a known good list of trusted management workstation ranges.  This is the term that would need to be updated to allow the external access.

    Best practice would be to expand the term to the known public ip addresses that trusted administrators would be coming from.

    The other option is to remove the reject all ssh term that follows the ip restriction term.

    On the SRX, you could get around the restriction by changing the nat policy.   
    You would need to:
    Remove the static nat
    Create the inbound direction destination nat instead of static
    Then create an inbound source nat policy that changes the source of the inbound ssh session to an address on the allowed list of the protect-re
    And making sure that the reply traffic to that address does go back to the SRX so it can match the session and is not sent somewhere else.



    ------------------------------
    Steve Puluka BSEET - Juniper Ambassador
    IP Architect - DQE Communications Pittsburgh, PA (Metro Ethernet & ISP)
    http://puluka.com/home
    ------------------------------



  • 9.  RE: SSH to a device behind an SRX Firewall

    Posted 09-29-2021 10:51

    Steve,

     

    Thanks again for the feedback and explanation.  It has been very helpful in determining the issues.  Based upon your explanation I removed the SSH_ACCESS policy from the EX4200 switch and still got the same result.  This tells me that some security is applied to the Genband device which is a Linux based voice appliance and based upon the services running has a firewall of some sort running on it. 

     

    I have passed on some of the details of our conversation to the voice engineers so they can dive deeper into the issue.  Your assistance is very much appreciated and your detailed explanations helped me convince the voice team that they need to own the issue at this point.

     

    Thanks,

     

    Rick

     






  • 10.  RE: SSH to a device behind an SRX Firewall

    Posted 09-29-2021 20:01
    Thanks for the update.

    I missed that the device target was not the ex4200 switch but a server connected to the switch.  
    I had thought you were using ssh to the ex4200 itself.

    In this case then the firewall filter on the ex4200 loopback is NOT in play at all.
    Loopback filters apply ONLY to traffic with a source or destination address of one of the ip interfaces of the ex4200 itself.
    They will NOT touch transit traffic ingressing the ex4200 from the SRX and egressing to a host device.

    ------------------------------
    Steve Puluka BSEET - Juniper Ambassador
    IP Architect - DQE Communications Pittsburgh, PA (Metro Ethernet & ISP)
    http://puluka.com/home
    ------------------------------