GRE over IPSEC UP but not working

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.

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!

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

Thanks.

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

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:

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