Description

This article provides some guidance on steps to troubleshoot if SSH from one Junos switch to another using lo0 as the source is not working.

Symptoms

Setup:

 

Switch1 lo0 10.0.0.1 >>> 172.16.0.1 Switch2 irb.7

 

 

Protect_RE filter configured on Switch1 showing ssh allowed.

 

family inet {

  filter protect_re {

    term allow_mist_obssh {

      from {

        source-port 2200;

      }

      then accept;

    }

    term allow_cloudx {

      from {

        source-port 443;

      }

      then accept;

    }

    term allow_dhcp {

      from {

        protocol udp;

        source-port [ 67 68 ];

        destination-port [ 67 68 ];

      }

      then accept;

    }

    term allow_icmp {

      from {

        protocol icmp;

      }

      then accept;

    }

    term allow_ssh {

      from {

        protocol tcp;

        destination-port 22;

      }

      then accept;

    }

    term allow_igmp {

      from {

        protocol igmp;

      }

      then accept;

    }

    term allow_ospf {

      from {

        protocol ospf;

      }

      then accept;

    }

    term allow_pim {

      from {

        protocol pim;

      }

      then accept;

    }

    term otherwise {

      then {

        discard;

      }

    }

  }

}

 

 

Ping from switch1 to switch2 works fine:

 

>ping 172.16.0.1 source 10.0.0.1

  • 64 bytes from 172.16.0.1: icmp_seq=0 ttl=64 time=20.275 ms
  • 64 bytes from 172.16.0.1: icmp_seq=1 ttl=64 time=21.242 ms

 

But ssh fails

 

>ssh [email protected] source 10.0.0.1

 

 

 

 

 

Solution

Monitoring the irb on switch2 >monitor traffic interface irb.7 no-resolve layer2-headers size 2000 matching "port 22"

We could see the SSH packet initiated by the Switch1 as "switch1-ip.port local >> switch2-ip.destination port 22":

 

10.0.0.1.51478 >> 172.16.0.1.22

 

The reply from switch2 is the opposite "switch2-ip.source port 22 >>switch1-ip.dest port local":

 

172.16.0.1.22 >> 10.0.0.1.51478

 

After checking the terms in the lo0 filter, there was no term matching this packet, so it was falling into the last term otherwise that discards the packet.

 

After adding the term:

 

  term source-ssh {

   from {

    source-port ssh;

   }

   then accept;

  }

 

 

The return packet was falling into the source-ssh term and the ssh session established.

Modification History

2026-08-20 : Article Created