GRE over IPSEC UP but not working

[oliverlag]

hi, 

I'm trying an easy setup in my lab where I've FGT1---FGT_ISP---FGT4 connedted. 

I've an ipsec running b/w FGT1 and FGT4 that is up and traffic goes through. 

Then I've a gre-tunnel over the IPSEC and an ip address setup over the gre-tunnel itself.

Then I've the following policies:

from lan to wan permit any with NAT

from gre to ipsec permit any with no NAT and way back

from ipsec to wan permit any with no NAT and way back. 

configuration on FGT1 (FGT4 is symmetric) is like this:

config system interface   ## this is the wan interface edit "port1" set vdom "root" set ip 10.0.13.2 255.255.255.0 set allowaccess ping https ssh http fgfm set type physical set snmp-index 1

FGT1 (gre-tunnel) # show config system gre-tunnel edit "gre1" set interface "vpn1" set remote-gw 10.0.34.2 set local-gw 10.0.13.2 next end

next edit "gre1" set vdom "root" set ip 1.1.1.1 255.255.255.255   ### on FGT ip address is 4.4.4.4/32 set type tunnel set remote-ip 4.4.4.4 set snmp-index 14 set interface "vpn1" next

FGT1 # get router info routing-table all

S* 0.0.0.0/0 [10/0] via 10.0.13.1, port1 C 1.1.1.1/32 is directly connected, gre1 C 4.4.4.4/32 is directly connected, gre1

Whenever I try to ping from FGT4 to FGT1 from 4.4.4.4 to 1.1.1.1 (with source 4.4.4.4) 

I get this: 

filters=[host 4.4.4.4] 16.117410 gre1 out 4.4.4.4 -> 1.1.1.1: icmp: echo request 16.117434 root out 4.4.4.4 -> 4.4.4.4: icmp: host 1.1.1.1 unreachable 16.117434 root in 4.4.4.4 -> 4.4.4.4: icmp: host 1.1.1.1 unreachable 17.123150 gre1 out 4.4.4.4 -> 1.1.1.1: icmp: echo request 17.123183 root out 4.4.4.4 -> 4.4.4.4: icmp: host 1.1.1.1 unreachable 17.123183 root in 4.4.4.4 -> 4.4.4.4: icmp: host 1.1.1.1 unreachable 18.122841 gre1 out 4.4.4.4 -> 1.1.1.1: icmp: echo request 18.122883 root out 4.4.4.4 -> 4.4.4.4: icmp: host 1.1.1.1 unreachable

I'm not able to further troubleshoot this. 

If I remove the IPSEC and I make a GRE tunnel over "internet" everything works and I see packet encapsulated into proto 47. 

where am I wrong and how can I further trobleshoot this? 

Thanks

[emnoc]

The diag debug flow is the 1st step in your diagnostics

e.g

diag debug dis

diag debug reset

diag debug en

diag debug flow filter addr x.x.x.x

diag debug flow show console enable

diag debug flow trace start 100

Please your traffic and monitor the output. When your finished

diag debug reset

diag debug disable

Optional you can diag sniffer the tunnel interface to validate packets are sent and received from either end. In your case it could be routing, uRPF checks, bad fw-policies or a combination of the all.

[oliverlag]

Hi man!

I'm very familiar with those commands and sorry for having not mentioned I've already used. 

Unluckily this time I cannot get much info from what I see. 

This is the result:

on FGT4:

FGT4 # exec ping-options source 4.4.4.4

FGT4 # execute ping 1.1.1.1 PING 1.1.1.1 (1.1.1.1): 56 data bytes

--- 1.1.1.1 ping statistics --- 5 packets transmitted, 0 packets received, 100% packet loss

On another session I debugged the traffic and I don't see where is routed and what ACL it matches:

Can't uderstand why:

FGT4 # FGT4 # 2015-09-10 05:08:12 id=20085 trace_id=10021 func=print_pkt_detail line=4420 msg="vd-root received a packet(proto=1, 4.4.4.4:14336->1.1.1.1:8) from local. code=8, type=0, id=14336, seq=0." 2015-09-10 05:08:12 id=20085 trace_id=10021 func=init_ip_session_common line=4569 msg="allocate a new session-0000389c" 2015-09-10 05:08:13 id=20085 trace_id=10022 func=print_pkt_detail line=4420 msg="vd-root received a packet(proto=1, 4.4.4.4:14336->1.1.1.1:8) from local. code=8, type=0, id=14336, seq=256." 2015-09-10 05:08:13 id=20085 trace_id=10022 func=resolve_ip_tuple_fast line=4479 msg="Find an existing session, id-0000389c, original direction" 2015-09-10 05:08:14 id=20085 trace_id=10023 func=print_pkt_detail line=4420 msg="vd-root received a packet(proto=1, 4.4.4.4:14336->1.1.1.1:8) from local. code=8, type=0, id=14336, seq=512." 2015-09-10 05:08:14 id=20085 trace_id=10023 func=resolve_ip_tuple_fast line=4479 msg="Find an existing session, id-0000389c, original direction" 2015-09-10 05:08:15 id=20085 trace_id=10024 func=print_pkt_detail line=4420 msg="vd-root received a packet(proto=1, 4.4.4.4:14336->1.1.1.1:8) from local. code=8, type=0, id=14336, seq=768." 2015-09-10 05:08:15 id=20085 trace_id=10024 func=resolve_ip_tuple_fast line=4479 msg="Find an existing session, id-0000389c, original direction" 2015-09-10 05:08:16 id=20085 trace_id=10025 func=print_pkt_detail line=4420 msg="vd-root received a packet(proto=1, 4.4.4.4:14336->1.1.1.1:8) from local. code=8, type=0, id=14336, seq=1024." 2015-09-10 05:08:16 id=20085 trace_id=10025 func=resolve_ip_tuple_fast line=4479 msg="Find an existing session, id-0000389c, original direction"

Thanks!

[oliverlag]

Hey @emnoc, I was wondering if you were able to read my reply. 

Thanks.

[emnoc]

No i haven't sat down enough,but can you pop the gre tunnel configuration and phase1/2  cfgs for the  ipsec portions?

if we ar eheaving your right you have a ipsec between  4.4.4.1<>1.1.1.1 but you also want to run  GRE between these 2 and encapsulated within the IPSEC? ( right? )

Also  why do you need to run GRE within a IPSEC tunnel? You you know you will loose  approx 78bytes or more with the headers and overhead. This will directly effect mtu and might require tcp-mss adjustments.

Thinking outside of the box, could you run the GRE sources off another  interface (loopback ) and carry these across the ipsec-tunnel? You could define these in a phase2 proxy-id src_subnet/dst_subnet

See my drawing

Ken

[oliverlag]

Hi Ken and thanks for your reply. 

1st. Why I need gre over ipsec? 

I'm trying to reproduce an issue I've with a customer of mine where I need to run ipsec from my site to his site (from FGT to ASA) and after that I need to establish a gre tunnel with a bgp speaker he has behind the ASA and I need to establish BGP peering with him. 

Unluckily I can't assign ip addresses to the ipsec interface on FGT since he cannot do that on ASA. (now I'm testing this in my lab with 2 FGT. Later I will put a cisco behind one FGT, just to reproduce the same scenario).

So I tried this:

Gre tunnel with no IPSEC.. it works. 

Gre tunnel over IPSEC.. does not work. 

the only difference between the two is that the gre-tunnel interface (the one configured on config system gre-tunnel) leans on ipsec interface instead of wan interface. 

As far as I've understood the ipsec interface gets the ip address assigned to the tunnel (kinda ip unumbered interface on cisco). 

After that, even w/o assigning an ip address to the tunnel interface I would expect that tunnel goes up and traffic passes. 

I've also setup transport mode and protocol 47 into phases 2. 

I see routes "connected" into the FGTs but I cannot ping the point-to-point ip. 

I've created the "needed" policies as well and when I ping from one side to the other I don't see traffic matching at all:

from gre to ipsec (and viceversa)

from ipsec to wan (and viceversa)

from gre to wan (and viceversa). 

Btw. I will try what you suggested in your last point and I will get back to you. Thanks so far for your help.

Oliver

[emnoc]

the only difference between the two is that the gre-tunnel interface (the one configured on config system gre-tunnel) leans on ipsec interface instead of wan interface. 

Not following you on that. The address for the GRE tunnel can be want ever you want, but it must be an address on the system. It doesn't lean on anything.

As far as I've understood the ipsec interface gets the ip address assigned to the tunnel (kinda like a ip unumbered interface on cisco).  After that, even w/o assigning an ip address to the tunnel interface I would expect that tunnel goes up and traffic passes.

You understanding of this is 100% correct BUT you can configure a address on the ipsec-tunnel in your route-mode vpns.

In your case I don't think you need this tho.

Also in the cisco ASA you can use a VTI-like approach , by using a ipv4-interface, but most do not do this & i don't think you need this to accomplish your goal. The ipsec tunnel interface in cisco can be used  dynamic routing when you deploy this method.

note: technically with a route-based vpn your could do the BGP between the cisco ASA to FGT ;)

Since your goal is just the GRE-tunnel & to a device behind the cisco ASA & over the ipsec-tunnel, you can set the tunnel up and with  the network-hop gateway and ensure that carried in the ipsec-tunnel

e.g ( a gre tunnel going to a vm-bgp machine of mine)

 config system interface     edit "GREtestVM1"         set vdom "root"         set ip 1.1.1.1 255.255.255.255         set type tunnel         set remote-ip 1.1.1.2         set interface "wan1"     next end

In the above our GRE tunnel is actually sourced from a loop-back interface named "loopback"

(A santized cfg  example  192.0.2.199 == my interface named loopback type loopback )

#

#

config system interface     edit "loop"         set vdom "root"         set ip 192.0.2.199 255.255.255.255         set type loopback     next end

#

config system gre-tunnel     edit "test"         set interface "wan1"         set local-gw 192.0.2.199         set remote-gw 9.9.9.9     next end

#

Now I'm doing this for something similar, BUT without the encryption.

In your case gre-tunnel interface src/dst address  would be in your phase2 proxy-id as what you hinted to. If I wanted to encrypt the above gre-traffic,  I would just apply the correct phase2 cfg for the gre src/dst.

hints:

[ul]

Just run the  "diag sniffer packet wan1 "proto 47" command you will see the packets src/dst of the gretunnel and ad these in in the vpn cfg.[/ul][ul]

Use the cisco packet-tracer on the cisco side to make sure all is in order[/ul][ul]

Take note of any mtu issues ( GRE overhead = 24bytes , IPSEC == 54 bytes maybe more )[/ul][ul]

 be aware of any routes you need over the gre o ipsec interfaces[/ul][ul]

Just becarefull of any recursive routing if you run any dynamic-routing and you should be golden[/ul]

[Draco]

Hey Sorry to hijack this but i think i have a similar issue trying to replicate this cisco config.

Basically i want to replicate the below Cisco config for gre and put it on a 200D running 5.2.5

interface Tunnel20 description GRE to Greece ip address 169.254.253.33 255.255.255.252 ip mtu 1400 ip tcp adjust-mss 1380 cdp enable tunnel source Loopback0 tunnel destination 172.20.22.1

Loopback0 is 172.20.20.1

Current Configuration looks like the following for the GRE as suggested by tac however i think i need to change the local-gw and remote-gw

set local-gw 172.20.20.1 set remote-gw 172.20.22.1

---------Full GRE Config--------

IPSEC tunnel address  -------------------------  config system interface  edit "togreece"  set vdom "root"  set ip wan1 IP Address set type tunnel  set remote-ip Public IP of Remote Cisco set interface wan1 next  end  GRE tunnel  -------------------------  config system gre-tunnel  edit "gre1"  set interface "togreece"  set local-gw wan1 IP Address - think i need to make 172.20.20.1 set remote-gw Public IP of Remote Cisco - think i need to make 172.20.22.1 next  end  config system interface  edit "gre1"  set vdom "root"  set ip 169.254.253.33 255.255.255.255 set type tunnel  set remote-ip 169.254.253.34 set interface "togreece"  next  end 

[emnoc]

It's 05:59AM and my eyes are still sleepy but it looks good ;)

http://socpuppet.blogspot.com/2015/09/gre-tunnels-fortigate.html

[Draco]

Seem to now be having issues setting the MTU on the GRE interface to match the cisco... Fortinet will be the death of me as i can't add set mtu-ovveride to the tunnel interface. I can however set it on wan1 which is not what i want as it will gimp all my wan traffic.

Cheers for any advise.