Screen OS

I've been reading so many How-To articles that I'm reaching burn out. I just want to know if this is possible and what magic words I have to use to find an example to explain what settings I need to make.

 

I have an SSG5 with a local subnet attached to bgroup0 for a Corporate Headquarters (192.168.18.0/24). On the same device bgroup1 is routing down to two remote offices (192.168.5.0/24, 192.168.4.0/24). The phone company takes care of all the traffic so all I do is send the packets to a gateway and off they go. All communications between these three subnets is working.

 

I've recently configured a Policy Based VPN to a remote employee and set up a 4th subnet to a second SSG5 (192.168.6.0/24). Following online guides the traffic between 18.0 and 6.0 is working fine. Now I need to complete the trifecta and get 4.0 and 5.0 to communicate with 6.0.

 

I thought that I simply needed to get the packets to the bgroup1 interface and the SSG5 would recognize where the next hop to 6.0 was but that is not to be. I can trace packets from 5.0 up to the bgroup1 interface but then it jumps to the default gateway instead entering the tunnel for the 6.0 subnet. Since the policy based link between 18.0 and 6.0 was so easy, it seems like it is not a hard stretch to connect the remaining subnets.

 

Hopefully, I'm right.

Your policy only allows for the single subnet

 

set policy id 9 from "Untrust" to "Trust"  "192.168.6.0/24" "192.168.18.0/24" "ANY" tunnel vpn "Griffis VPN" id 0x2 pair-policy 8 
set policy id 9
exit
set policy id 8 from "Trust" to "Untrust"  "192.168.18.0/24" "192.168.6.0/24" "ANY" tunnel vpn "Griffis VPN" id 0x2 pair-policy 9 
set policy id 8

You would need to include the other subnets into the policy as well.  My recommendation is to change the policy on both sides from 192.168.18.0/24 to 192.168.0.0/16.  Make sure to leave the 192.168.6.0/24 the same.

 

The other option is to use a route based VPN, which would then rely on routing to get the traffic to/from the VPN.  To do this, you would simply remove the VPN policies, create a tunnel interface, bind the VPN to the tunnel interface and create a route for 192.168.6.0 to use the tunnel interface.  Example:

 

set interface "tunnel.1" zone "Trust"

set interface tunnel.1 ip unnumbered interface bgroup0

set vpn "Griffis VPN" bind tunnel.1

set route 192.168.6.0/24 interface tunnel.1

 

 

Also, I would recommend not using "permanent" in your route statements. This will force the route to remain active even if the physical interface is down.

Can I define the rule using overlapping masks? 192.168.6.0/24 is in 192.168.0.0/16. Or do I need to reassign IP to remove the overlap, say assign the remote VPN subnet to 192.168.32.0/19 so that the subnets I'm going to are not in the same space as the one I'm coming from.

You can use address objects that overlap.  You would need to change your policy to something like

 

set policy id 9 from "Untrust" to "Trust" "192.168.6.0/24" "192.168.0.0/16" "ANY" tunnel vpn "Griffis VPN" id 0x2 pair-policy 8 set policy id 9 exit set policy id 8 from "Trust" to "Untrust" "192.168.0.0/16" "192.168.6.0/24" "ANY" tunnel vpn "Griffis VPN" id 0x2 pair-policy 9 set policy id 8

 

You would also need to create an address entry in Trust for 192.168.0.0/16

Thank you, thank you, thank you.

 

It worked perfectly the first time. I have my fully routed network now and I expect all the complaints about the VOIP phone intercom feature will go away now that everybody can ping everybody else.

 

I'll learn from your solution and tuck away another trick in my toolbox.