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
Nominating a forum post submits a request to create a new Knowledge Article based on the forum post topic. Please ensure your nomination includes a solution within the reply.
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.
PCNSE
NSE
StrongSwan
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.
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
PCNSE
NSE
StrongSwan
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:
[ul]
[ul]
[ul]
[ul]
[ul]
PCNSE
NSE
StrongSwan
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
It's 05:59AM and my eyes are still sleepy but it looks good ;)
http://socpuppet.blogspot.com/2015/09/gre-tunnels-fortigate.html
PCNSE
NSE
StrongSwan
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.
Select Forum Responses to become Knowledge Articles!
Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.
User | Count |
---|---|
1547 | |
1031 | |
749 | |
443 | |
210 |
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.
Copyright 2024 Fortinet, Inc. All Rights Reserved.