Skip to main content
FlashOver
FlashOver
New Member
January 2, 2011
Question

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

  • January 2, 2011
  • 10 replies
  • 11397 views
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.

    10 replies

    emnoc
    emnoc
    New Member
    January 3, 2011
    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
    FlashOver
    FlashOverAuthor
    New Member
    January 3, 2011
    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
    ede_pfau
    SuperUser
    January 3, 2011
    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.
    emnoc
    emnoc
    New Member
    January 3, 2011
    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.
    FlashOver
    FlashOverAuthor
    New Member
    January 5, 2011
    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
    ede_pfau
    SuperUser
    January 5, 2011
    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.
    rwpatterson
    rwpatterson
    New Member
    January 5, 2011
    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.
    FlashOver
    FlashOverAuthor
    New Member
    January 5, 2011
    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
    rwpatterson
    New Member
    January 6, 2011
    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...
    emnoc
    emnoc
    New Member
    January 5, 2011
    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.
    FlashOver
    FlashOverAuthor
    New Member
    January 7, 2011
    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...
    A
    Anonymous_User
    Contributor
    February 3, 2011
    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
    Terms & ConditionsAccessibility statement