- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-09-2023 06:36 AM - edited 01-10-2023 03:25 AM
Communication issues - ikev1 vpn Cisco IOS <-> Fortigate
I configured a ikev1 tunnel between Cisco IOS and Fortigate.
The tunnel comes up but communication only works after a client of the remote site (cisco) initiated some traffic.
As you can see in the Fortigate capture, the packet to 10.183.2.1 is sent into the tunnel IPsec tunnel-1.2.3.62 which is the correct tunnel.
The capture on the cisco router shows nothing until I start a ping.
The exact same configuration works with other remote router i tested like pfsense and a linux based system also using policy based vpn.
----------------------------------------------------------------------
Cisco configuration
----------------------------------------------------------------------
!
crypto isakmp policy 9
encryption aes 256
authentication pre-share
group 14
lifetime 28800
crypto isakmp key ****** address 1.2.3.36 no-xauth
crypto isakmp keepalive 30 5
crypto isakmp nat keepalive 15
!
crypto ipsec transform-set AES256-SHA1 esp-aes 256 esp-sha-hmac
mode tunnel
!
crypto map IPSECMAP 9 ipsec-isakmp
set peer 1.2.3.36
set transform-set AES256-SHA1
set pfs group14
match address 191
qos pre-classify
!
interface GigabitEthernet1
description *** wan ***
ip address 1.2.3.62 255.255.255.224
ip nat outside
negotiation auto
no mop enabled
no mop sysid
crypto map IPSECMAP
!
ip nat inside source list 180 interface GigabitEthernet1 overload
!
ip access-list extended 180
10 deny ip 10.183.2.0 0.0.0.255 100.64.0.0 0.0.0.7
20 deny ip 10.183.2.0 0.0.0.255 10.199.1.0 0.0.0.255
30 deny ip 10.183.2.0 0.0.0.255 172.18.0.0 0.0.255.255
40 deny ip 10.183.2.0 0.0.0.255 192.168.201.72 0.0.0.7
50 permit ip 10.183.2.0 0.0.0.255 any
!
ip access-list extended 191
10 permit ip 10.183.2.0 0.0.0.255 172.18.0.0 0.0.255.255
20 permit ip 10.183.2.0 0.0.0.255 192.168.201.72 0.0.0.7
30 permit ip 10.183.2.0 0.0.0.255 100.64.0.0 0.0.0.7
!
----------------------------------------------------------------------
Fortigate configuration
----------------------------------------------------------------------
Fortigate # show vpn ipsec phase1-interface 1.2.3.62
config vpn ipsec phase1-interface
edit "1.2.3.62"
set interface "port1"
set local-gw 1.2.3.36
set keylife 28800
set peertype any
set net-device disable
set proposal aes256-sha1
set localid "1.2.3.36"
set localid-type address
set dhgrp 14
set remote-gw 1.2.3.62
set psksecret ENC ******
set keepalive 20
next
end
Fortigate # show vpn ipsec phase2-interface 1.2.3.62
config vpn ipsec phase2-interface
edit "1.2.3.62"
set phase1name "1.2.3.62"
set proposal aes256-sha1
set dhgrp 14
set auto-negotiate enable
set src-addr-type name
set dst-addr-type name
set keylifeseconds 3600
set src-name "SN_local-lan"
set dst-name "SN_remote-lan"
next
end
Fortigate # show router static 421
config router static
edit 421
set device "1.2.3.62"
set dstaddr "SN_remote-lan"
next
end
----------------------------------------------------------------------
Fortigate Capture when trying to initiate traffic from
forti site to remote after tunnel was down
----------------------------------------------------------------------
id=20085 trace_id=1 func=print_pkt_detail line=5824 msg="vd-root:0 received a packet(proto=1, 172.18.96.201:111->10.183.2.1:2048) from port9.717. type=8, code=0, id=111, seq=1."
id=20085 trace_id=1 func=init_ip_session_common line=5995 msg="allocate a new session-00008443"
id=20085 trace_id=1 func=iprope_dnat_check line=5058 msg="in-[port9.717], out-[]"
id=20085 trace_id=1 func=vf_ip_route_input_common line=2621 msg="find a route: flag=04000000 gw-10.183.2.1 via 1.2.3.62"
id=20085 trace_id=1 func=get_new_addr line=1194 msg="find SNAT: IP-10.9.0.254(from IPPOOL), port-60527"
id=20085 trace_id=1 func=__iprope_check_one_policy line=2175 msg="policy-572 is matched, act-accept"
id=20085 trace_id=1 func=iprope_reverse_dnat_check line=1270 msg="in-[port9.717], out-[1.2.3.62], skb_flags-02000000, vid-0"
id=20085 trace_id=1 func=fw_snat_check line=509 msg="NAT disabled by central SNAT policy!"
id=20085 trace_id=1 func=fw_forward_handler line=808 msg="Allowed by Policy-572:"
id=20085 trace_id=1 func=ipsecdev_hard_start_xmit line=790 msg="enter IPsec interface-1.2.3.62"
id=20085 trace_id=1 func=_ipsecdev_hard_start_xmit line=667 msg="IPsec tunnel-1.2.3.62"
Solved! Go to Solution.
- Labels:
-
Other VPN Topics
Accepted Solutions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-12-2023 01:05 AM - edited 01-12-2023 03:05 AM
Thanks for your help MHM. The documentation you shared is for older releases.
I spoke to support about it, here is the summary.
I was using group address objects in fortigates phase2-interface local and remote network which is supported according to Fortigates support. But, some other routers on the remote site do not support this. Fortigate Support has now added this note to their documentation.
https://docs.fortinet.com/document/fortigate/6.4.11/administration-guide/604285
I had to split and create a phase2-interface per remote or local subnet.
Although the cisco router actually showed both networks in the ipsec session of the tunnel.
EDIT:
I received a better solution from another forum: https://community.fortinet.com/t5/FortiGate/Technical-Tip-Dynamic-creation-of-IPsec-tunnels-IKEv1-dynamic/ta-p/190346
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-09-2023 08:20 AM
I see NAT run in interface, you must config NAT exception,
you need to excluded LOCAL-Remote LAN from NAT overload.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-09-2023 08:38 AM
You're right, I forgot to add these lines here. I edited my original post.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-09-2023 10:20 AM
debug crypto isakmp <<- share this please ?
debug crypto ipsec <<- share this please ?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-10-2023 01:55 AM
I added the debug logs to my original post.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-10-2023 02:54 AM
10 permit ip 10.183.2.0 0.0.0.255 172.18.0.0 0.0.255.255 <<- this meaning 10.183.2.0/24 172.18.0.0/16
but what I see in debug is
local_proxy= 10.183.2.0/255.255.255.0/256/0, remote_proxy= 100.64.0.0/255.255.255.248/256/0 <<- this sure not match.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-10-2023 03:24 AM
Sorry I missed some lines of the config. Here are the right acl.
Extended IP access list 180
10 deny ip 10.183.2.0 0.0.0.255 100.64.0.0 0.0.0.7
30 deny ip 10.183.2.0 0.0.0.255 172.18.0.0 0.0.255.255
40 deny ip 10.183.2.0 0.0.0.255 192.168.201.72 0.0.0.7
50 permit ip 10.183.2.0 0.0.0.255 any
Extended IP access list 191
10 permit ip 10.183.2.0 0.0.0.255 172.18.0.0 0.0.255.255
20 permit ip 10.183.2.0 0.0.0.255 192.168.201.72 0.0.0.7
30 permit ip 10.183.2.0 0.0.0.255 100.64.0.0 0.0.0.7
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-10-2023 03:28 AM
show ip crypto ipsec sa <<- share this please
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-10-2023 03:44 AM
testrouter#show crypto ipsec sa
interface: GigabitEthernet1
Crypto map tag: IPSECMAP, local addr 1.2.3.62
protected vrf: (none)
local ident (addr/mask/prot/port): (10.183.2.0/255.255.255.0/0/0)
remote ident (addr/mask/prot/port): (172.18.0.0/255.255.0.0/0/0)
current_peer 1.2.3.36 port 500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0
#pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#send errors 0, #recv errors 0
local crypto endpt.: 1.2.3.62, remote crypto endpt.: 1.2.3.36
plaintext mtu 1500, path mtu 1500, ip mtu 1500, ip mtu idb GigabitEthernet1
current outbound spi: 0x0(0)
PFS (Y/N): N, DH group: none
inbound esp sas:
inbound ah sas:
inbound pcp sas:
outbound esp sas:
outbound ah sas:
outbound pcp sas:
protected vrf: (none)
local ident (addr/mask/prot/port): (10.183.2.0/255.255.255.0/0/0)
remote ident (addr/mask/prot/port): (192.168.201.72/255.255.255.248/0/0)
current_peer 1.2.3.36 port 500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0
#pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#send errors 0, #recv errors 0
local crypto endpt.: 1.2.3.62, remote crypto endpt.: 1.2.3.36
plaintext mtu 1500, path mtu 1500, ip mtu 1500, ip mtu idb GigabitEthernet1
current outbound spi: 0x0(0)
PFS (Y/N): N, DH group: none
inbound esp sas:
inbound ah sas:
inbound pcp sas:
outbound esp sas:
outbound ah sas:
outbound pcp sas:
protected vrf: (none)
local ident (addr/mask/prot/port): (10.183.2.0/255.255.255.0/0/0)
remote ident (addr/mask/prot/port): (100.64.0.0/255.255.255.248/0/0)
current_peer 1.2.3.36 port 500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0
#pkts decaps: 6646, #pkts decrypt: 6646, #pkts verify: 6646
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#send errors 0, #recv errors 0
local crypto endpt.: 1.2.3.62, remote crypto endpt.: 1.2.3.36
plaintext mtu 1438, path mtu 1500, ip mtu 1500, ip mtu idb GigabitEthernet1
current outbound spi: 0x38CCB538(952939832)
PFS (Y/N): Y, DH group: group14
inbound esp sas:
spi: 0xF2ED15CF(4075623887)
transform: esp-256-aes esp-sha-hmac ,
in use settings ={Tunnel, }
conn id: 2051, flow_id: CSR:51, sibling_flags FFFFFFFF80004048, crypto map: IPSECMAP
sa timing: remaining key lifetime (k/sec): (4607937/3100)
IV size: 16 bytes
replay detection support: Y
Status: ACTIVE(ACTIVE)
inbound ah sas:
inbound pcp sas:
outbound esp sas:
spi: 0x38CCB538(952939832)
transform: esp-256-aes esp-sha-hmac ,
in use settings ={Tunnel, }
conn id: 2052, flow_id: CSR:52, sibling_flags FFFFFFFF80004048, crypto map: IPSECMAP
sa timing: remaining key lifetime (k/sec): (4608000/3100)
IV size: 16 bytes
replay detection support: Y
Status: ACTIVE(ACTIVE)
outbound ah sas:
outbound pcp sas:
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-11-2023 02:28 AM
Site to Site VPN between Cisco route and FortiGate - YouTube
I check your Cisco IOS IPsec config it OK for me,
I think the issue in FortiGate FW,
I view above video to see what make one side work initiate the traffic
there is some detail I see in FortiGate can make one way issue, the IPv4 policy
the IPv4 policy in FortiGate must allow LAN-Tunnel and Tunnel-LAN (two ways)
please can check this point in FortiGate
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-11-2023 03:08 AM
Thanks for your time. I watched the video.
The vpn interfaces in the policies are there because Fortigate is using route-based vpn by default. Currently I have a rule that allows any traffic on any interfaces until I'm able to solve this problem. I already tested it by using the vpn interfaces in the policies like the guy from the video.
I also suspect that the problem is with the Fortigate FW. Only the fact that the same vpn configuration works with other non-Cisco routers unsettles me.
Is there a way to capture the packets entering end leaving the vpn tunnel on cisco (not on vlan/lan int)?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-11-2023 03:19 AM
but I totally sure the cisco config I see is for policy-based not for route-based VPN and hence the FortiGate is also config as policy-based not route-based VPN.
make review the video again
for debug I will check how we can DEBUG traffic
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-11-2023 04:12 AM - edited 01-12-2023 12:55 AM
Yes the cisco config is policy-based and I also tried route-based.
I think I found the problem, by try and error princip....
On Fortigate in Phase 2 we are using a group object for source network (set src-name) and as soon as I replaced it with a single network object it worked. I didn't found a description from forti who forbids this and the support didn't figure it out either, maybe this is a bug. I will do more tests and get in touch with their support again.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-11-2023 09:07 AM - edited 01-11-2023 09:14 AM
check the FortiGate guide how you can add multi subnet to VPN
I think it really this is what make issue here.
Enter the following commands to create firewall addresses for each subnet.
config firewall address
edit "local_subnet_1"
set subnet 4.2.1.0 255.255.255.0
next
edit "local_subnet_2"
set subnet 4.2.2.0 255.255.255.0
next
edit "remote_subnet_3"
set subnet 4.2.3.0 255.255.255.0
next
edit "remote_subnet_4"
set subnet 4.2.4.0 255.255.255.0
next
edit "remote_subnet_5"
set subnet 4.2.5.0 255.255.255.0
end
And then put the five firewall addresses into two firewall address groups.
config firewall addrgrp
edit "local_group"
set member "local_subnet_1" "local_subnet_2"
next
edit "remote_group"
set member "remote_subnet_3" "remote_subnet_4" "remote_subnet_5"
end
Now, use the firewall address groups in the Phase 2 configuration:
config vpn ipsec phase2-interface
edit "to-fgt2"
set phase1name "to-fgt2"
set src-addr-type name <<-
set dst-addr-type name <<-
set src-name "local_group" <<-
set dst-name "remote_group" <<-
end
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-12-2023 01:05 AM - edited 01-12-2023 03:05 AM
Thanks for your help MHM. The documentation you shared is for older releases.
I spoke to support about it, here is the summary.
I was using group address objects in fortigates phase2-interface local and remote network which is supported according to Fortigates support. But, some other routers on the remote site do not support this. Fortigate Support has now added this note to their documentation.
https://docs.fortinet.com/document/fortigate/6.4.11/administration-guide/604285
I had to split and create a phase2-interface per remote or local subnet.
Although the cisco router actually showed both networks in the ipsec session of the tunnel.
EDIT:
I received a better solution from another forum: https://community.fortinet.com/t5/FortiGate/Technical-Tip-Dynamic-creation-of-IPsec-tunnels-IKEv1-dynamic/ta-p/190346
