Screen OS

Alright, so here it goes:

 

I nailed up a simple lab environment, after a few attempts of failing, and now successfully have a functional Route-based IPSEC Tunnel between an SRX100B and SSG5. The code on the SSG5 is latest release, and the SRX isn't that far behind either. 

 

Now that I've conquered such, I wanted to take it to the next level and incorporate dynamic routing, namely OSPF, by creating about 10 fictitious subnets on each side ---- using a single Area. (Yes, I just want to keep it simple for now). 

 

The confusion is about GRE? I noticed in the following Juniper forum, someone recommended using a 2014 DayOne Cookbook, in which they clearly layout how to established OSPF over IPSEC between SRX and SSG5 (see Recipe #12 under "DAY ONE: JUNIPER AMBASSADORS’ COOKBOOK FOR 2014")  ... but not once do they mention configuration of a GRE tunnel? Strange?? I'm finding highly subjective info around community between different vendors, and I want to get an authoritative answer on this if possible. As a caveat, I do prefer to run GRE to ensure OSPF is securely encapsulated  ... I just want to understand the constraints entirely. 

 

Secondly, I read that GRE over IPSEC is possible between SRX/SSG5, you just need to ensure that the GRE tunnel is created prior to the IPSEC tunnel, otherwise it may lead to connectivity issues. As defined here: https://kb.juniper.net/InfoCenter/index?page=content&id=KB19954&actp=search

 

So I guess, in conclusion, what is the proper way to do this? 

 

The IPSEC tunnel is currently alive and well betwen SRX100B and SSG5, disregard J series router in place of the SRX in the graphic below:

 

 

 

 

I'm the author of Recipe #12 in the 2014 Cookbook.  I have not generally used gre over ipsec in recent years because I'm comfortable with the level of encryption security provided by current IPSEC tunneling.  And thus I don't see the need to run the gre inside of this IPSEC encryption.  So the basic layout presented in the book is one I've used for deploying OSPF over the internet IPSEC branch connections.

 

You can run GRE over IPSEC, I think you are reading the kb incorrectly.  The error message about GRE coming first is a result of having the zone configuration for the GRE interface not match the IPSEC interface zone.  I don't think they are suggesting running IPSEC over GRE but making the zone change to allow the GRE tunnel to come up over the IPSEC tunnel.

Steve,

 

Thanks kindly for your reply, but I think are signals are getting a bit crossed here:

 

- I'm not attempting to "run IPSEC over GRE", I would like to run "GRE inside/through IPSEC", which is very common --- namely used to secure dynamic routing protocols like OSPF. Without encapsulating OSPF inside of GRE tunnel, which will in turn be encapsulated in IPSEC tunnel, your multicast traffic would NOT be secure (at least in the truest sense). 

 

So again, what I'm looking to do is ensure that all OSPF/Multicast traffic is encrypted through IPSEC tunnel ... and to my knowledge, GRE is necessary to do this. 

 

 

GRE over IPSEC is supported by both ScreenOS and Junos.  I think you read the kb incorrectly.

 

What the kb seems to me to say is that you need the screenOS vpn tunnel interface and gre interface in the same zone.

 

Can you post the config you have on each side?

In Juniper (both ScreenOS and Junos) OSPF and multicast are supported natively in the IPSEC tunnel - no need of GRE tunnel inside the IPSEC tunnel.
This scenario is only needed for compatibility with Cisco, as there you need GRE tunnel for dynamic routing protocols.

Thanks, Mircho. It would be helpful if I could find some literature that spells that out 100%, even if it's a specs sheet, or whitepaper, etc. 

 

There seems to be a lot ot ambiguity about it. 

 

To plainly state my intentions, I would prefer to not have to run commands at interface level on each side to force convertsion of multicast to unicast (for OSPF), prior to sending over IPSEC tunnel. 

 

The recurring theme of knowledge I see posted everywhere is that OSPF w/ multicast over IPSEC tunnel simply isn't supported (vendor-neutral). So are you saying between my SSG5 and SRX100B, I can natively establish OSPF adjacency (with a single area 0), directly over IPSEC tunnel ---- out of the box --- without any unique configuration to interfaces, other than general OSPF config?

 

Thanks for confirmation in advance. If you're reply is yes, then I'll refer to Recipe 12 in the Day One guide (previously mentioned here: http://forums.juniper.net/jnet/attachments/jnet/Day1Books/336/1/DO_Ambassadors_2014.pdf)

 

Thanks again for contributing!

I can't find any clear documentation for you.  But I can assure you that both ScreenOS and Junos can run OSPF directly on the vpn tunnel interfaces and pass the OSPF multicast making full neighbors.  This feature was in ScreenOS for many years and was used to create automatic hub and spoke mulitpoint tunnels where you would not need to create any of the necessary routes for the sites to interconnect.

 

The feature was also then implemented in the SRX Junos code and works there as well.

 

I created the recipe because I encountered a some nuances getting this to work between ScreenOS and Junos so wanted to document and share the working example.

I follow you now. Thanks. 

 

So I'm looking at the syntax from the Day One guide, and it looks like it assumes you are only passing a single network between SRX/SSG. 

 

In the even that you wanted to advertise numerous subnets/networks, would you add another line of code for each respective vlan interface? I understand summarization is out of scope for this post, so I'm doing the labor intensive way for argument's sake:

 

Enable OSPF on the SRX and assign the local VLAN interface and the
tunnel interface to OSPF area 0:

set protocols ospf area 0 interface vlan.0

set protocols ospf area 0 interface vlan.10     

set protocols ospf area 0 interface vlan.20

set protocols ospf area 0 interface st0.0

 

Configure vlan.0 to announce OSPF routes:   *Except here I would need to add additional vlan interfaces? RVIs?
set protocols ospf area 0 interface vlan.0 passive

set protocols ospf area 0 interface vlan.10 passive

set protocols ospf area 0 interface vlan.20 passive

 

In most of the environments I work in, it's more common that the RVIs/subnets are defined on L3 switch, for example EX4200, and we have a default route between L3 switch and upstream firewall/SRX. In that sense, no VLANs are defined on the firewall other than native VLAN that exists (untagged). 

 

As an alternative to the above, if I wanted to pass 10 OSPF routes from my L3 Juniper switch up to the SRX, and over to SSG side, would I still need to configured the SRX/SSG the same as the Day One guide? If I were advertising the 10 routes from the L3 Juniper switch on each side of the VPN tunnel? Or would the SRX/SSG drop/not forward the OSPF traffic across the tunnel? 

 

Sorry if I'm confusing you ... definitely not my intentions. Normally this would be a non-issue, because we would have a L2VPN/VPLS (Metro Ethernet) solution ... but this exercise really has me intrigued about capabilities of SRX/SSG with L3 switches in the mix, and forwarding OSPF across tunnel. I have an environment with this exact scenario actually. 

 

 

 

 

 

 

Yes, the sample is showing just on local subnet and the vlan interface on the SRX.  This could also be multiple interfaces as your note.

 

But you can have the vlan side of the OSPF setup on the switch.  But naturally the SRX has to neighbor with the switch to get those routes to be learned on the SRX.

 

In shout you can consider the tunnel interface neighbors as if they were just two routers on your standard OSPF setup.  And thne arrange the rest of the area configuration as you would if that link were a normal point to point OSPF link.  Just forget about it being over an IPSEC tunnel.