Question about GRE over IPSEC

[ricewu2018]

Hi, Masters

    I ran into a problem about GRE over IPSEC. 

    For Cisco, it's quite common for such situation:

    router1 port1: 1.1.1.1/24   <---->  router2 port1: 1.1.1.2/24

    router1 tunnel0: 2.2.2.1/30 <---> router2 tunnel0: 2.2.2.2/30 (tunnel source and destination are port1 above)

    After S2S vpn is created based on port1 connection, dynamic routing can be enabled on tunnel0 interface, for instance, OSPF neighbor can be created between 2.2.2.1 and 2.2.2.2. 

    However, for Fortigate, it doesn't seem to work like that. 

    I used the VPN wizard to create S2S VPN between 2 fortigates. 

    Then there will be "automatically" created ipsec tunnel interfaces on both sides. Based on documents I read, we can set ip addresses on these two tunnel interfaces right? 

    First problem is that we can only set "/32" for tunnel interface ip address... 

    After I set up /32 tunnel interfaces on both sides (router1: 2.2.2.1/32; router2: 2.2.2.2/32), I created one static route on both sides, for instance, on router1, there's:

    destination 2.2.2.2/32,   outgoing interface: ipsec tunnel interface (2.2.2.1)

    There comes the 2nd problem (VPN already up): 

    From router1 CLI, I can't ping 2.2.2.2 from 2.2.2.1....  

    Could anyone please help answer the question?  Or where did I do anything wrong?  "Ping" option has been checked on both tunnel interfaces. 

    Thanks. 

[Ashik_Sheik]

Hi,

Can you follow below link .

http://help.fortinet.com/fos50hlp/52data/Content/FortiOS/fortigate-ipsecvpn-52/Protecting_OSPF_with_... 

Regds,

Ashik

[Toshi_Esumi]

As in ashik's link, you don't need GRE to set up OSPF or BGP peering over IPSec because FGT's default IPSec config is now interface-based (or route based in Cisco's term), which has end-point interface IP you can pear with or route toward. GRE is necessary when IPSec is policy-based. We don't use this much any more because GRE add quite significant overhead. Even with Cisco routers, you can use route-based (VTI based instead of cryptomap) IPsec to pass routing protocol over it without GRE tunnel.

[ede_pfau]

@OP:

1- why is a host address for a tunnel endpoint a problem? It's just for this tunnel end.

2- you don't need any static route to reach the remote tunnel end via it's IP address.

3- if ping doesn't work, it's probably because the source address used is not suitable for the tunnel (phase2 selectors). Use

exec ping-options source a.b.c.d

to change the source address used by the system.

[ricewu2018]

Thanks guys. I've found out the solution. The source and destination for phase2 must be both 0.0.0.0/0, then OSPF neighbor can be established. 

But no matter what I did, ipsec tunnel ip addresses still can't be pinged between each other. Still weird. 

[ricewu2018]

@ede_pfau, I emulated the scenario on Cisco platform, if tunnel ip addresses on both sides are 1.1.1.1/32 and 1.1.1.2/32, it's impossible to ping each other because they're on the different subnet.  Unless we add static route on both sides, say, on router1, add ip route 1.1.1.2 255.255.255.255 tunnel0, they can start to ping each other's tunnel ip. That's why I added those two static routes on both sides of FGT. Even if OSPF can be established now, ipsec tunnel ip addresses 1.1.1.1/32 and 1.1.1.2/32 can't ping each other. Maybe Fortigate has different mechanism... "Ping" option has been checked on "ipsec tunnel" interface settings.