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

You need to go back to basic, if the tunnel is up and configured properly, then data has to go somewhere. It doesn' t vanish. Have you ran a ; diag vpn tunnel list " insert tunnel name and see if your txbit and rxbits counters are moving when you trying to ping the remote end? If you have counters at zero counts, than I would advise you to go back and look at the fwpolicies. Other options are to run a diag filter flow and a packet trace from the cisco side. You probably have some configuration error and it' s not related to your phase1 configuration. So you should not need to play around with dh, main/aggr mode or anything else. A tunnel should not be that hard to configure imho.

PCNSE 

NSE 

StrongSwan  

PCNSE NSE StrongSwan
FlashOver
New Contributor

I have tried to allow everything from everywhere in every directon on the ASA... havent solved that. I will open a post in a cisco ASA forum if I can find a good one. But maybe an idea. I have got the information, that between the FG60 is a transparent FG interface which is working on the same hardware on a different vdom. So eth1 and eth2 working in transparent and eth3 seems to be the vpn outside interface. the trnasparent vdom policy allows any... has anybody some experience with that and knows, that could be the reason? an IPSec with an other manufacturer on the remote site (draytek vigor 2900) works fine...
Not applicable

just skimmed this post so it might have been said, but: Could it be that you have another rule allowing traffic to any address before the vpn rule? If not, could it be that the Cisco is configured for encapsulation in transport-mode and that you would have to use GRE-tunneling? Regards Rikard
Announcements
Check out our Community Chatter Blog! Click here to get involved
Labels
Top Kudoed Authors