Routing
Reply
Visitor
Chris_Pope
Posts: 3
Registered: ‎12-12-2008
0

SSG320M unable to reach subnets on second interface

I've got an SSG320M, which is nice.  It's got ScreenOS6.1 and 1GB of memory.

 

I'm using three of its four interfaces.  Eth0/0 (Trust) is connected to the LAN.  Eth0/2 (Untrust) is connected to the internet through a Cisco Router.  Eth0/3 (Untrust 2) is also connected to the internet, through a different Cisco Router.  The two untrusted interfaces each have a separate internet connection, and each has a route to 0.0.0.0

 

Our remote sites connect to the LAN through IPSEC VPN tunnels.  Half of the sites come into the SSG320 on Eth0/2 and the other half come into the SSG320 on Eth0/3.  The reason for this is load balancing - if one of the interfaces goes down, only half the remote sites are affected, instead of all of them.

 

All these remote sites can reach servers and services on the LAN, no problem there.

 

From my computer on the LAN (192.168.1.176),  I can ping, tracert, connect to file sharing etc to all the computers that are on Eth0/2.  For example, I can ping a remote PC's LAN address (192.168.152.2) that's connected through Eth0/2.  For example, doing a tracert to192.168.152.2 does this:

 

Tracing route to 192.168.152.2 over a maximum of 30 hops 1 <1 ms <1 ms <1 ms 192.168.1.14 2 25 ms 19 ms 19 ms 192.168.152.1 3 21 ms 26 ms 21 ms 192.168.152.2 Trace complete.

 

 

I can't, however, ping a computer that's on Eth0/3, for example, 192.168.149.2.  What appears to be happening is that the SSG320 is sending traffic that should go to Eth0/3 through an 'internet' policy on Eth0/2 instead.  For example:

 

Tracing route to 192.168.149.2 over a maximum of 30 hops 1 <1 ms <1 ms <1 ms 192.168.1.14 2 <1 ms <1 ms <1 ms 217.33.181.194 3 * * * Request timed out. 4 * * * Request timed out. 5 * * * Request timed out. 6 * * * Request timed out. 7 * * * Request timed out. 8 * ^C

 

 

This stops us from remotely managing the PCs that are attached to Eth0/3.  Has anyone else had something similar?  Or has anyone got an idea what I can do?

Distinguished Expert
rkim
Posts: 755
Registered: ‎11-06-2007
0

Re: SSG320M unable to reach subnets on second interface

How do you have your VPNs setup? Is it route-based or policy-based? I would recommend route-based in your case. The idea is you can direct traffic to whichever VPN by configuring a route for 192.168.x.x with next-hop as the tunnel interface. Check out the VPN Configuration and Troubleshooting Guide and look for route-based VPNs.
 
-Richard
Visitor
Chris_Pope
Posts: 3
Registered: ‎12-12-2008
0

Re: SSG320M unable to reach subnets on second interface

Our VPNs are policy based.  I will do an experiment with a Route based VPN to see if it helps.

 

However, surely the device should be spotting traffic destined for a configured subnet or IP address, and point it at the correct policy regardless of VPN type? 

Visitor
Chris_Pope
Posts: 3
Registered: ‎12-12-2008
0

Re: SSG320M unable to reach subnets on second interface

One of the KB articles in your link mentioned checking the VR's route.  I did this for one of the IP addresses on Eth0/3 (Untrust2) and got the following:

 

 

SSG320M-> get route ip 192.168.149.2
Dest for 192.168.149.2
-----------------------------------------------------------------------
trust-vr : => 0.0.0.0/0 (id=10) via 217.33.181.194 (vr: trust-vr)
Interface ethernet0/2 , metric 1

 

This is obviously wrong, as the 192.168.149.0 subnet is not connected to eth0/2 - it is connected to eth0/3.  This led me to realise that I might need a VR for eth0/3, so I created one, and got this:

 

 

SSG320M-> get route ip 192.168.149.2
Dest for 192.168.149.2
-----------------------------------------------------------------------
------
trust-vr : => 0.0.0.0/0 (id=10) via 217.33.181.194 (vr: trust-vr)
Interface ethernet0/2 , metric 1

potential routes in other vrouters:

VR-1025 : => 0.0.0.0/0 (id=1) via 217.33.221.194 (vr: trust-vr)
Interface ethernet0/3 , metric 1
SSG320M->

 

When I checked the  Zone for the Untrust 2 zone, the VR is set to trust-vr, the same as the Untrust zone on Eth0/2.

 

Would changing the  VR for the Untrust 2 zone to the new VRbe the answer to my problem?

 

 

Distinguished Expert
rkim
Posts: 755
Registered: ‎11-06-2007
0

Re: SSG320M unable to reach subnets on second interface

So you have eth3 in a different VR? That would explain your routing issue. To check route from a particular VR you need to append your get route with the VR name.

 

Example:

  get vrouter <vr-name> route ip <dest-ip>

 

If you need to route traffic from one VR to another then you need to add a route pointing to the VR.

 

Example:

  set route <dest-net> vrouter <vr-name>

 

-Richard

Copyright© 1999-2013 Juniper Networks, Inc. All rights reserved.