Support Forum
The Forums are a place to find answers on a range of Fortinet products from peers and product experts.
FlashOver
New Contributor

Tunnel is up but no data flow / Cisco ASA-FG60B

Hello togehter. Cause I could not fine any solution within older posts, I will write here some lines and hope somebody can help me. At first - I already have configured FG systems with Site2Site VPNs when on the other end is a different vendor like Juniper or Check Point but this Cisco ASA (lates OS) is frustrating me. I can see on both sites that the tunnel is up but I get 0 data on RX or TX. Also in the FG IPSec montitor I can see a green tunnel but no data flow. On FG I get this message... and that repeats all the time. 2011-01-02 19:10:27 ike 2: comes 188.195.188.215:500->80.19.191.189:500,ifindex=14.... 2011-01-02 19:10:27 ike 2: IKEv1 exchange=Informational id=78bd6d0b4f34568b/79226ef04d7f1790:bf26a430 len=92 2011-01-02 19:10:27 ike 2: found 188.195.188.215 80.19.191.189 14 -> 188.195.188.215:500 2011-01-02 19:10:27 ike 2:188.195.188.215:592: notify msg received: R-U-THERE-ACK 2011-01-02 19:10:32 ike 2:188.195.188.215:592: send IKEv1 DPD probe, seqno 536 2011-01-02 19:10:32 ike 2:188.195.188.215:592: sent IKE msg (R-U-THERE): 80.19.191.189:500->188.195.188.215:500, len=92 2011-01-02 19:10:32 ike 2: comes 188.195.188.215:500->80.19.191.189:500,ifindex=14.... 2011-01-02 19:10:32 ike 2: IKEv1 exchange=Informational id=78bd6d0b4f34568b/79226ef04d7f1790:d5e9c69d len=92 2011-01-02 19:10:32 ike 2: found 188.195.188.215 80.19.191.189 14 -> 188.195.188.215:500 2011-01-02 19:10:32 ike 2:188.195.188.215:592: notify msg received: R-U-THERE-ACK diag debu di2011-01-02 19:10:37 ike 2:188.195.188.215:592: send IKEv1 DPD probe, seqno 537 2011-01-02 19:10:37 ike 2:188.195.188.215:592: sent IKE msg (R-U-THERE): 80.19.191.189:500->188.195.188.215:500, len=92 2011-01-02 19:10:37 ike 2: comes 188.195.188.215:500->80.19.191.189:500,ifindex=14.... 2011-01-02 19:10:37 ike 2: IKEv1 exchange=Informational id=78bd6d0b4f34568b/79226ef04d7f1790:49ddaab4 len=92 2011-01-02 19:10:37 ike 2: found 188.195.188.215 80.19.191.189 14 -> 188.195.188.215:500 2011-01-02 19:10:37 ike 2:188.195.188.215:592: notify msg received: R-U-THERE-ACK Cisco ASA shows that. Jan 02 18:20:19 [IKEv1]: IP = 80.190.191.189, IKE_DECODE RECEIVED Message (msgid=262186a9) with payloads : HDR + HASH (8) + NOTIFY (11) + NONE (0) total length : 84 Jan 02 18:20:19 [IKEv1 DEBUG]: Group = 80.190.191.189, IP = 80.190.191.189, processing hash payload Jan 02 18:20:19 [IKEv1 DEBUG]: Group = 80.190.191.189, IP = 80.190.191.189, processing notify payload Jan 02 18:20:19 [IKEv1 DEBUG]: Group = 80.190.191.189, IP = 80.190.191.189, Received keep-alive of type DPD R-U-THERE (seq number 0x1be) Jan 02 18:20:19 [IKEv1 DEBUG]: Group = 80.190.191.189, IP = 80.190.191.189, Sending keep-alive of type DPD R-U-THERE-ACK (seq number 0x1be) Jan 02 18:20:19 [IKEv1 DEBUG]: Group = 80.190.191.189, IP = 80.190.191.189, constructing blank hash payload Jan 02 18:20:19 [IKEv1 DEBUG]: Group = 80.190.191.189, IP = 80.190.191.189, constructing qm hash payload Jan 02 18:20:19 [IKEv1]: IP = 80.190.191.189, IKE_DECODE SENDING Message (msgid=eb657dd6) with payloads : HDR + HASH (8) + NOTIFY (11) + NONE (0) total length : 84 Jan 02 18:20:24 [IKEv1]: IP = 80.190.191.189, IKE_DECODE RECEIVED Message (msgid=9f2feb84) with payloads : HDR + HASH (8) + NOTIFY (11) + NONE (0) total length : 84 Jan 02 18:20:24 [IKEv1 DEBUG]: Group = 80.190.191.189, IP = 80.190.191.189, processing hash payload Jan 02 18:20:24 [IKEv1 DEBUG]: Group = 80.190.191.189, IP = 80.190.191.189, processing notify payload Jan 02 18:20:24 [IKEv1 DEBUG]: Group = 80.190.191.189, IP = 80.190.191.189, Received keep-alive of type DPD R-U-THERE (seq number 0x1bf) Jan 02 18:20:24 [IKEv1 DEBUG]: Group = 80.190.191.189, IP = 80.190.191.189, Sending keep-alive of type DPD R-U-THERE-ACK (seq number 0x1bf) Jan 02 18:20:24 [IKEv1 DEBUG]: Group = 80.190.191.189, IP = 80.190.191.189, constructing blank hash payload Jan 02 18:20:24 [IKEv1 DEBUG]: Group = 80.190.191.189, IP = 80.190.191.189, constructing qm hash payload So, can somebody help me how to find the problem please? I already have changed DH groups, Main to Aggressive mode and so on and so on... same result all the time. Hope sombody can help me. If required, I can provide a full configuration set from both devides. Maybe somebody has a tutorial which describes the complete diagnose command set on CLI so I will find help in this way. That' s the only thing I miss a manual from fortinet. thanks in advance.
12 REPLIES 12
emnoc
Esteemed Contributor III

Things to check Have you validated FWpolicy from both sides? Are you defining the left & right subnets on the FGT to match the ASA? Are you using interface or policy mode, and if the former, do you have a static route point for the remote-network(s) and your using your defined phase1 interface? For starters, what does you fgt diagnose vpn shows? e.g diag vpn tunnel list Do spi matches the cisco ASA e.g sh crypto ipsec sa peer " fgt-peer-address" How does a packet trace from the cisco show? e.g packet input " lan-interface " tcp " src_address" " src_port" " dst_net" " dst_port" det You want to ensure it shows encrypt at the action and does not fail e.g ( reduce output from a cisco packet trace ) Phase: 11 Type: VPN Subtype: encrypt Result: ALLOW Config: Additional Information: Forward Flow based lookup yields rule: out id=0xdbe2ea48, prio

PCNSE 

NSE 

StrongSwan  

PCNSE NSE StrongSwan
FlashOver
New Contributor

Hello. I have tried all what you told me. Traffic flow on ASA is fine and encrypted. I have changed the configuration to be as simple as pissible with DES and SHA1 and so on without any luck yet. I attach a file with some output from both devices. maybe somebody have a great idea. I' m frustrated and also have tried is with a dedicated blank FG without more sucess. Tried NAT-T (no NAT router between both devices and the internet)... HELP!!
ede_pfau
SuperUser
SuperUser

Hi, the tunnel seems to be up as the Cisco receives and answeres R-U-THERE (keepalive) packets from the FG. You should be able to see the UP status in the FG VPN IPSec monitor. What seems strange to me is that you run in Main mode but towards a dynamic gateway (berlin.company.net is resolved via DNS). So, the gateway IP cannot be part of the identity exchange. In similar scenarios I use aggressive mode and the exchange of local ID/peer ID. There are excellent examples of site-to-site VPNs with dynamic gateways in the FortiOS Handbook (new, for 4.00MR2) and, to a lesser extent, the IPSec VPN Guide. OTOH, if the tunnel is up and no traffic flowing, then there must be something wrong with the policy. As the FG policy is simple to check, have you had a look at the Cisco policy (ACL?)? Tunnel control traffic is separate from payload traffic.
Ede Kernel panic: Aiee, killing interrupt handler!
Ede Kernel panic: Aiee, killing interrupt handler!
emnoc
Esteemed Contributor III

Q:for pfs, is the default on the ASA group 2 reference: crypto map outside_map0 1 set pfs I want to say it is, but I would hard set on the cisco to group2. if that doesn' t make a difference, than I would say to review your policies on the FGT for interface internal and internal2. On main vrs agressive mode, with dyn-dns, I' ve had no problems using Main-mode on my FGT.

PCNSE 

NSE 

StrongSwan  

PCNSE NSE StrongSwan
FlashOver
New Contributor

I tried to switch from Main- to Aggressive mode and also played arround with DH group without any success. Also played around with NAT-T. I can see in the IPSec Monitor that this tunnel is up but an RX and TX is just can see 0 and 0. Thats frustrating. Even when only the ACK will flow, that should be enought to cound some bits. Has somebody one more helpful idea?
ede_pfau
SuperUser
SuperUser

OTOH, if the tunnel is up and no traffic flowing, then there must be something wrong with the policy. As the FG policy is simple to check, have you had a look at the Cisco policy (ACL?)? Tunnel control traffic is separate from payload traffic.
Ede Kernel panic: Aiee, killing interrupt handler!
Ede Kernel panic: Aiee, killing interrupt handler!
rwpatterson
Valued Contributor III

If you defined the tunnel in interface mode, you will need to create a matching static route for all the tunnel traffic. From a workstation, run a traceroute and see where your traffic ends up going.

Bob - self proclaimed posting junkie!
See my Fortigate related scripts at: http://fortigate.camerabob.com

Bob - self proclaimed posting junkie!See my Fortigate related scripts at: http://fortigate.camerabob.com
FlashOver
New Contributor

but it' s policy based and for that there is no use for a static route as far as I know. Just Phase1 and Phase2 with a firewall policy with action = IPSec from inside to outside and service ANY. I would love to have mure debugging details at this time. Problem is that I can not fine any packet drops (Cisco monitring and Fortinet) don' t show me any packet blockings from an ACL or firewall policy. frustrating.
rwpatterson
Valued Contributor III

Personally, I would dump the policy mode tunnel and switch to interfaced based. This way you have control over the routing and such. The ' FortiMagic' routing doesn' t always work as desired, and leaves you with your a** in the wind...

Bob - self proclaimed posting junkie!
See my Fortigate related scripts at: http://fortigate.camerabob.com

Bob - self proclaimed posting junkie!See my Fortigate related scripts at: http://fortigate.camerabob.com
Announcements
Check out our Community Chatter Blog! Click here to get involved
Labels
Top Kudoed Authors