Screen OS

Having an issue w/ a new configuration I'm applying to 2 SSG 20s at remote sites.  I'm trying to setup ospf to work properly in a broadcast connection.  I'm able to ping across from unit1 to unit2 w/ no problem and I can do a "get vrouter trust2-vr protocol ospf neighbor" and I see the remote unit, but not seeing the route advertisement for the internal network at that site.  I was thinking of removing trust2-vr and just making my e0/4 a member of trust-vr on both sites.  Or if RIP is a better option here I'm open to suggestions.  I have 8 sites that I need to connect with this interface being their primary connection and vpn to HQ as their backup.  I've attached the configs of the 2 sites I was working on today.  I've also attached a Visio of what I'm trying to accomplish.  The VPN's are already established so trying to make it that all 3 sites use ospf as their primary connection to each other and if a link fails to fail back to the vpn.  Both of the SSG20's are running 6.2.0.1.

Attachment(s)

unit2fw_now.txt   15 KB 1 version

unit1fw_now.txt   15 KB 1 version

Drawing1.pdf   13 KB 1 version

hi.

you need to export/import the 192.168.x.x subnet from trust-vr into trust2-vr, then redistribute into ospf.

here's example, using Unit 1 as reference:

set vrouter "trust-vr"
set access-list 1
set access-list 1 permit ip 192.168.12.0/24 1
set route-map name "to_trust2-vr" permit 1
set match ip 1
exit
set export-to vrouter "trust2-vr" route-map "to_trust2-vr" protocol connected
exit

set vrouter "trust2-vr"
set access-list 1
set access-list 1 permit ip 192.168.12.0/24 1
set route-map name "to_ospf" permit 1
set match ip 1
exit
set protocol ospf
set redistribute route-map "to_ospf" protocol imported
exit
exit

"get vr trust2-vr" should list route 192.168.12.0/24

"get vr trust2-vr protocol ospf database" should now show 192.168.12.0/24 as AS External LSA.

Regards,

sam

Ah, route-maps.  Didn't think about doing it that way as I'm used to how it's done in Cisco.  I'll give it a try tonight during off hours and see how it works.

Will I also need policies to allow traffic across or will this take care of that?

Yes, most definitely, a policy between lightpath and trust zones are needed.

In addition, you'll need to export ospf route,192.168.15.0/24 ,from trust2-vr to trust-vr, so that traffic coming in on bgroup0 will know how to route to the other side.

Regards,

Sam

Ok.  I just added this to the 2 SSG20's and confirmed all 3 now show the 2 trust-vr subnets in the ospf database.  I'll have to look at the admin guide in terms of figuring out how to get the ospf learned routes back into the bgroup0 and also setting up those policies.  I'm thinking something like this:

set vrouter "trust2-vr"
set access-list 2
set access-list 2 permit ip 192.168.15.0/24 1
set route-map name "from_ospf" permit 1
set match ip 2
exit
set export-to vrouter "vrouter" route-map "from_ospf" protocol ospf
exit

But I'll try to grab the guide again tomorrow and look.  I'd have to import into trust-vr as well I'd imagine.  And would I be able to add multiple lines to that acl since I'll have 6 different networks in ospf.  Sorry for all the questions, new to Juniper and want to follow best practice.

Ok.  I read the guide just now so from what I gather I should do the following:

set vrouter trust2-vr
set access-list 2
set access-list 2 permit 192.168.12.0/24 10
set access-list 2 permit 192.168.14.0/24 15
set route-map name from_ospf permit 10
set route-map name from_ospf permit 15
set match ip 2
exit

set export-to vrouter trust-vr route-map from_ospf protocol ospf
exit

set vrouter trust-vr
set access-list 5
set access-list 5 permit ip 192.168.12.0/24 5
set access-list 5 permit ip 192.168.14.0/24 10
set route-map name from-ospf-trust 2 permit 5
set route-map name from-ospf-trust 2 permit 10
set match ip 5
exit
set import-from vrouter trust2-vr route-map from ospf-trust2 protocol ospf
exit

This would be on unit2 so that it would export the routes for 192.168.12.0/24 and 192.168.14.0/24 that it learned via ospf from it's neighbors into the local trust-vr if I understand this correctly?  

I still have to look up the policies to make it work.

you only need one entry per route-map.  Each route-map will match a group of ip access-lists.

So remove "set route-map name from_ospf permit 15"

and remove "set route-map name from-ospf-trust 2 permit 10"

Regards,

Sam

For exporting ospf-learned routes from trust2-VR to trust-VR, only one route-map is necessary.

On Unit2:

set vrouter trust2-vr
set access-list 2
set access-list 2 permit 192.168.12.0/24 10
set access-list 2 permit 192.168.14.0/24 15
set route-map name from_ospf permit 10
set match ip 2
exit
set export-to vrouter trust-vr route-map from_ospf protocol ospf
exit

Regards,

Sam

Thanks Sam.  Just reread it again and I see what you're saying.  So this will export all the routes from trust2-vr into trust-vr.  For arguments sake, if I wanted to limit the learned routes into trust-vr I could just deny that in the ACL rather than create a separate route-map for importing.

Ok, now it looks like just policies are in order.  I'd imagine something like this should work:

set policy id 8 from "Lightpath" to "Trust" "Any" "192.168.15.0/24" "ANY" permit
set policy id 8

Where 15.0/24 is my local segment.  Would a second policy, like this:

set policy id 9 from  "Trust" to "Lightpath"  "192.168.15.0/24"  "Any" "ANY" permit
set policy id 9

be needed?  Or I imagine I could use the address book entry to filter down the allowed list to the subnets that I know will be coming over that circuit, with the exception of the 172.16.0.0/24 network.

And then I just have to remove my vpn routes and add them back w/ a preference above 60 or modify the ospf preference to less than 25 and disable/enable ospf on the firewall to re-learn the routes?

Hello.

Since you have multiple subnets to deal with, I recommend creating an address group. This way, if IP addressing changes for any reasons, you can just add/delete the address object rather than having to play around with the policy itself.

set address Trust 192.168.15.0/24 192.168.15.0 255.255.255.0

set address Trust 192.168.16.0/24 192.168.16.0 255.255.255.0

...

then

set group address Trust <name of address group>

set group address Trust <name of address group> add 192.168.15.0/24

set group address Trust <name of address group> add 192.168.16.0/24

then apply to policy.  most likely, you'll need policies in both directions.

set policy id 8 from "Lightpath" to "Trust" "Any" "<name of address group>" "ANY" permit

set policy id 9 from  "Trust" to "Lightpath" "<name of address group>"  "Any" "ANY" permit

You can also further restrict via policy, by adding in address objects for the Lightpath zone.

in reference to route preference, yes.  I'm not sure what the pref is for routes imported from OSPF. 

Regards,

Sam

Thanks.  Yes, it makes more sense to do it as an address group rather than having to modify policies down the road.  I believe the ospf routes are coming in w/ a preference of 60, but I'll confirm that when I log in again.  If they are I'll set the preference on the static routes to 85 or so to make sure these routes are preferred.

Just writing it up before I apply tonight.  Unit1 and Unit2 already have the trust-vr routes exported into trust2-vr and I've verified I see them on the remote firewalls routing tables.

Unit1 - 192.168.15.0

set vrouter trust2-vr
set access-list 2
set access-list 2 permit 192.168.12.0/24 10
set access-list 2 permit 192.168.16.0/24 15
set route-map name from_ospf permit 10
set match ip 2
exit
set export-to vrouter trust-vr route-map from_ospf protocol ospf
exit

set address Trust 192.168.12.0/24 192.168.12.0 255.255.255.0
set address Trust 192.168.16.0/24 192.168.16.0 255.255.255.0

set group address "Trust" "Remote_Offices"
set group address "Trust" "Remote_Offices" add 192.168.12.0/24
set group address "Trust" "Remote_Offices" add 192.168.12.0/24

set policy id 8 from "Lightpath" to "Trust" "Any" "Remote_Offices" "ANY" permit
set policy id 8
set policy id 9 from "Trust" to "Lightpath" "Remote_Offices" "Any" "ANY" permit
set policy id 9

Unit2 - 192.168.12.0

set vrouter trust2-vr
set access-list 2
set access-list 2 permit 192.168.15.0/24 10
set access-list 2 permit 192.168.16.0/24 15
set route-map name from_ospf permit 10
set match ip 2
exit
set export-to vrouter trust-vr route-map from_ospf protocol ospf
exit

set address Trust 192.168.15.0/24 192.168.15.0 255.255.255.0
set address Trust 192.168.16.0/24 192.168.16.0 255.255.255.0

set group address "Trust" "Remote_Offices"
set group address "Trust" "Remote_Offices" add 192.168.15.0/24
set group address "Trust" "Remote_Offices" add 192.168.16.0/24

set policy id 8 from "Lightpath" to "Trust" "Any" "Remote_Offices" "ANY" permit
set policy id 8
set policy id 9 from "Trust" to "Lightpath" "Remote_Offices" "Any" "ANY" permit
set policy id 9

Unit3 - 192.168.16.0/24

set vrouter "trust-vr"
set access-list 1
set access-list 1 permit ip 192.168.16.0/24 1
set route-map name "to_trust2-vr" permit 1
set match ip 1
exit
set export-to vrouter "trust2-vr" route-map "to_trust2-vr" protocol connected
exit

set vrouter "trust2-vr"
set access-list 1
set access-list 1 permit ip 192.168.16.0/24 1
set route-map name "to_ospf" permit 1
set match ip 1
exit
set protocol ospf
set redistribute route-map "to_ospf" protocol imported
exit
exit

set vrouter trust2-vr
set access-list 2
set access-list 2 permit 192.168.12.0/24 10
set access-list 2 permit 192.168.15.0/24 15
set route-map name from_ospf permit 10
set match ip 2
exit
set export-to vrouter trust-vr route-map from_ospf protocol ospf
exit

set address Trust 192.168.12.0/24 192.168.12.0 255.255.255.0
set address Trust 192.168.15.0/24 192.168.15.0 255.255.255.0

set group address "Trust" "Remote_Offices"
set group address "Trust" "Remote_Offices" add 192.168.12.0/24
set group address "Trust" "Remote_Offices" add 192.168.15.0/24

set policy id 8 from "Lightpath" to "Trust" "Any" "Remote_Offices" "ANY" permit
set policy id 8
set policy id 9 from "Trust" to "Lightpath" "Remote_Offices" "Any" "ANY" permit
set policy id 9

Does that look right?  I'll have to modify the policy numbers based on the site, but the general idea.

Nice! 

One thing...On Units 1&2, I believe you have the zones reversed.  The OSPF learned routes should be part of the "Lightpath" zone. Eth0/4 is Lightpath zone, and Bgroup0 is Trust zone.

set address Lightpath 192.168.15.0/24 192.168.15.0 255.255.255.0
set address Lightpath 192.168.16.0/24 192.168.16.0 255.255.255.0
 
set group address "Lightpath" "Remote_Offices"
set group address "Lightpath" "Remote_Offices" add 192.168.15.0/24
set group address "Lightpath" "Remote_Offices" add 192.168.16.0/24
 
set policy id 8 from "Lightpath" to "Trust" "Remote_Offices" "Any" "ANY" permit
set policy id 8
set policy id 9 from "Trust" to "Lightpath" "Any" "Remote_Offices" "ANY" permit
set policy id 9

Same with Unit3:

set address Lightpath 192.168.12.0/24 192.168.12.0 255.255.255.0
set address Lightpath 192.168.15.0/24 192.168.15.0 255.255.255.0
 
set group address "Lightpath" "Remote_Offices"
set group address "Lightpath" "Remote_Offices" add 192.168.12.0/24
set group address "Lightpath" "Remote_Offices" add 192.168.15.0/24
 
set policy id 8 from "Lightpath" to "Trust" "Remote_Offices" "Any" "ANY" permit
set policy id 8
set policy id 9 from "Trust" to "Lightpath" "Any" "Remote_Offices" "ANY" permit
set policy id 9

Regards,

Sam

Good catch.  I'll make the change.  

Do I need these statements still:

set area 0.0.0.0 range 192.168.15.0 255.255.255.0 advertise

set area 0.0.0.0 range 172.16.0.0 255.255.255.0 advertise

I see they routes are still added without them, just want to be sure.

And I'm guessing I could replace this all w/ RIP using the same route-map information, just updating the configuration to be rip instead of OSPF?  Wondering what advantage it would offer over OSPF since this is for a small 7 site network.

Hello.

Yes, the ospf ... range ... advertise is not needed.

Yes, RIP with route-map will work the same.

I would stick with OSPF.  faster convergence, and as you mentioned, since it's not a big network, there wouldn't be much overhead.

Regards,

Sam

Just wanted to say Thanks.  So far it's working great.  Might play with the timers a bit to get the failover to work a bit faster, but was able to get this going Friday night and test site to site traffic.  I have 1 more site to bring up tomorrow and then another later in the week, but so far so good.  Thanks for all the help on this one.  

That's great news.

Thanks for the letting the forum know of the outcome!

Looks like I spoke too soon.  Just got a call that 2 of the sites were having an issue getting back to the main office.  The main office hasn't been done yet so all of the remote sites should just be going over the vpn's they have locally to get back there.  As soon as I disabled ospf on the 2 firewalls they were able to get to it without any problem.  

I just noticed that a good 5 minutes after I disabled the ospf process on those 2 firewalls the routing information is still in the databse when I do a "get vr trust2-vr protocol ospf database".  I'm seeing this:

AS External LSA(s)
Link-State-Id            Adv-Router-Id     Age               Sequence#   CheckSum
--------------------------------------------------------------------------------
192.168.11.0              0.0.0.11            2766             0x80000028 0x8aed
192.168.12.0              0.0.0.12            409               0x800000b2 0x6487
192.168.13.0              0.0.0.13            1374             0x800000ac 0x5f90
192.168.14.0              0.0.0.14            788               0x8000049e 0x5e99
192.168.15.0              0.0.0.15            1346             0x800000ad 0x3baf
192.168.16.0              0.0.0.16             1650            0x800000ae 0x28bf

I stopped ospf on router 11 and router 16.  It seems like new entries are being added to the table but things are dropping out.  I say that because I stopped the ospf process before and deleted those "advertise" statements but I still see them on some of the firewalls when I check the database.

Wondering if RIP would be a better choice right now or if I need to start tweaking OSPF to adjust timers and add costs to each location?

The route from router 11 just dropped out of the table after about 30 minutes. 

Disabled ospf on the interface of all of the firewalls and deleted the instance completely on 1 (router 11).  Waited 10 minutes and re-enabled it on 2 of them.  The neighbor list is correct, but all the routes remain in the database except the route to the network behind router 11.  This is supposed to be for a fault-tolerant network where if this link goes down it fails back to the vpn that is configured on the firewall but I'm worried that won't happen if the routes are going to remain in the routing table.  After waiting another 10 minutes or so a couple more routes dropped out of the database. I was hoping it would be more on the order of 2-3 minutes at most of downtime, with it being more like 30-45 seconds if the link went down.

Did some more testing tonight and confirmed that while the networks are in the database for ospf, the routes do drop out of the routing tables rather quickly.

Hello.

Were you able to capture any data prior to disabling/bouncing ospf? 

Odd that it was working fine and then suddenly stopped working...

Regards,

Sam

I actually think I got it sorted out.  Looks like there was a duplex mismatch from ISP to our equipment.  Fixed it and so far so good.

Found another issue this weekend when I went live with the final site though.  This is a hub and spoke network where users SSL vpn to the main site, and from there they are able to access the remote networks.  Previously those remote networks were going over a vpn from the main site, so I would suspect those were in the Untrust zone and it was untrust to untrust traffic.  Now when I moved them over to the ospf network I could ping from site to site (from firewall to firewall), but when users connected via ssl they timed out trying to get to their remote sites.

I can post the config of the main site if it helps?

Here's the config from the main office.  So users would use an ssl vpn to 242.141.149.3 and from there they are able to access the remote offices over the already configured vpn.  If I delete the routes for the remote sites over vpn and then re-add w/ a preference of 150 (so they are secondary to the imported routes that are 140), external users need to be able to still get to the remote offices over the now ospf connection.  So I was thinking I would need to add policies to allow traffic from City_VPN_Net, or at the very least City-SSLVPN, to the RemoteOffices group.

Attachment(s)

Main_office.txt   41 KB 1 version