Juniper SRX - OSPF over GRE over IPSEC

Hi everyone,

As promised, and as a continuation of my JNCIE-SEC studies, a follow up to the basic Route Based VPN article. This is how you can join two separate OSPF domains together across an IPSEC/GRE tunnel. Keep in mind running GRE is not necessary on an SRX<->SRX IPSEC tunnel, however more limited platforms like ASA's require it.

As a recap, this is the topology we're working with:

We'll do this for SRX210_A only, mirror the config to SRX210_B with slight adjustments if you're following along:

Create the GRE Tunnel and add it to our DMZ Zone, making sure to use st0 as the source/destination:

set interfaces gr-0/0/0.0 tunnel source 172.16.30.1
set interfaces gr-0/0/0.0 tunnel destination 172.16.30.2
set interfaces gr-0/0/0.0 family inet address 172.16.30.5/30
set security zones security-zone DMZ interfaces gr-0/0/0.0 host-inbound-traffic system-services ping

Ensure VPN allows any system service for the time being (lock it down later):

set security zones security-zone VPN host-inbound-traffic system-services any-service

Test time - Make sure your GRE tunnel is up and running by trying to reach the remote side:

ping 172.16.30.6 rapid 
PING 172.16.30.6 (172.16.30.6): 56 data bytes
!!!!!
--- 172.16.30.6 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss

round-trip min/avg/max/stddev = 4.811/5.521/6.624/0.703 ms

OSPF Area 0  configuration for GRE and DMZ interfaces:

set security zones security-zone DMZ host-inbound-traffic protocols ospf
set protocols ospf area 0 interface gr-0/0/0.0
set protocols ospf area 0 interface fe-0/0/5.0

Verify OSPF neighbor adjacency across gr-0/0/0.0 and that you're receiving the correct routes:

show ospf neighbor
Address          Interface              State     ID               Pri  Dead
172.16.30.6      gr-0/0/0.0             Full      10.200.200.1     128    39

show route protocol ospf 
inet.0: 16 destinations, 17 routes (16 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.200.200.0/24    *[OSPF/10] 00:03:17, metric 2
                    > via gr-0/0/0.0
172.16.30.4/30      [OSPF/10] 00:03:28, metric 1
                    > via gr-0/0/0.0
224.0.0.5/32       *[OSPF/10] 00:03:38, metric 1
                      MultiRecv

You'll notice if you try and ping the remote hosts you'll get drop logs for DMZ -> DMZ:

May  2 09:47:27 192.168.0.212 RT_FLOW: RT_FLOW_SESSION_DENY: session denied 10.200.200.100/1->10.100.100.101/36102 icmp 1(8) global_drop_all(global) DMZ DMZ UNKNOWN UNKNOWN N/A(N/A) fe-0/0/5.0 No 

Finally, create a new policy to allow the new DMZ<->DMZ traffic we've just bridged:

set security policies from-zone DMZ to-zone DMZ policy DMZ_to_DMZ match source-address 10.100.100.0/24
set security policies from-zone DMZ to-zone DMZ policy DMZ_to_DMZ match source-address 10.200.200.0/24
set security policies from-zone DMZ to-zone DMZ policy DMZ_to_DMZ match destination-address 10.200.200.0/24
set security policies from-zone DMZ to-zone DMZ policy DMZ_to_DMZ match destination-address 10.100.100.0/24
set security policies from-zone DMZ to-zone DMZ policy DMZ_to_DMZ match application any
set security policies from-zone DMZ to-zone DMZ policy DMZ_to_DMZ then permit
set security policies from-zone DMZ to-zone DMZ policy DMZ_to_DMZ then log session-init

Verify our connectivity again by pinging from the remote hosts across the tunnel:

show security flow session destination-prefix 10.100.100/24 
Session ID: 38948, Policy name: DMZ_to_DMZ/15, Timeout: 2, Valid
  In: 10.200.200.100/17 --> 10.100.100.101/36614;icmp, If: gr-0/0/0.0, Pkts: 1, Bytes: 84
  Out: 10.100.100.101/36614 --> 10.200.200.100/17;icmp, If: fe-0/0/5.0, Pkts: 1, Bytes: 84

And we're done!

Full configuration will be uploaded to github shortly (once they're done their maintenance).
Full configuration on github