Allow OSPF traffic over IPSEC tunnel

[ggntt]

Hi all

We have spend a lot of time trying to get IPSEC FG to FG to work as shown in this video.  http://www.youtube.com/watch?v=01KEgxqC4WI

The plan is to use OSPF as the routing protocol, so that should WAN 1 fail WAN 2 becomes the new route etc.

We managed to get the tunnel up and working....(we are using the latest version of FW 5.2.1, so we had to add in quick mode selector ip's for the local lan AND the ipsec interfaces)

Eventually we managed to pass pings from a PC over the tunnel, but had to use static routes to get it to work.

No matter what we tried we cannot get OSPF updates over the tunnel, so without the static routes one side cant reach the other!

Having the static routes in place defeats the whole purpose of using the routing protocol.

(running cli commands to see the OSPF neighbour show nothing on both sides)

Just  a thought, but I suspect the FW rules are restricting OSPF traffic, if I look at the rules they tend to only allow traffic from internal to external and visa versa. Is there a way to specific allow OSPF traffic from FW1 in on Interface ipsec 1 for example ?

Any help would be very much appreciated

Thanks

greg

[emnoc]

I never seen or have used  fwpolicies to ospf working. Here's what I would do;

1: double check you have address assigned to the interfaces ( I'm assuming your using rt-based mode policy based will not do ospf )

2:Ensure the local<>remote  fgt1 and  <remote to local > fgt2 ) matches

3: make sure you applied and enabled ospf on the  actual tunnel interfaces & in the right areas and the ares matches

4: run the diag sniffer packet < tunnel name> "any" and see if ospf packets are coming and going

I hope that helps or share your  tunnel interface cfg and router ospf cfg

[ggntt · Accepted solution]

Hi again

We managed to get this to work eventually.

The video is outdated as the new FW version 5.2.1 requires quick mode selectors in the IPSEC setup. 

We had to specify 0.0.0.0 0.0.0.0 as the local and remote side on both FW's for OSPF traffic to pass. (as they were the default ip's assigned in the OSPF setup)   You also have to specify the ipsec tunnel interfaces local and remote on both sides in the quick mode selector setup.

Took us a good bit of time to find this out.

I have one other question

As we are using OSPF now we don't have any static routes specified.

In fact when we specified a default static route it caused our VPN fail over behavior to become very flaky. 

When we removed any static routes the IPSEC VPN failover works fine.

What is the best way now to force internet traffic (non vpn) over one of the WAN links without introducing static IP routes.

Thanks for your help

greg

[emnoc]

I you are running into what we say "recursive routing" So no you probably don't want to route a default over the vpn but if you do you need to probably set "host /32 specific routes to your internet ISP uplink next-hop.

Is that what you trying to do? Inject a default thru the vpn via OSPF so the site#2 sends all traffic to site #1 like branch to headquarters.

If you need to control what you push thru the OSPF dynamic routing protocol updates, you will need to build a route-policy and allow or drop prefixes that you don't want advertised over the  tunnel.

Back to your  QM selectors, yes when you use FGT-2-FGT with dynamic routing protocols like OSPF, you typically set  0.0.0.0./0:0,  but I'm not quite catching you on the following part tho.

You also have to specify the ipsec tunnel interfaces local and remote on both sides in the quick mode selector setup.

Can you post what you actually configured on the  vpn-phase2 settings? None of my cfg have the actually tunnel interface address in a P2-selector.