Contributor

Question

IPSEC VPN tunnel up but no Data from the other side

Forum|Forum|16 years ago
June 24, 2009
8 replies
15972 views

Hello together, i have a customer with a Fortigate 60b conneting via Side-to-Side VPN to a Cisco PIX The firmware version of the Fortigate-60B is 3.00-b0741(MR7 Patch 5) We already tried the 4.0.2 but we have a lot of trouble with this version (not only VPN) and switched back to 3.0 The Tunnel is UP and shows green at the Fortigate VPN Monitor The Network looks like:

  customer-Network:                                                           Partner-network:  10.10.0.0/24-----Fortigate-(WANIP: AAA.BBB.CCC.238)---------INTERNET--------(WANIP: XXX.YYY.ZZZ.139)-Cisco PIX----10.0.1.0/24----translated to: 10.2.12.0/24

the AAA.BBB.CCC.233 is the gateway of the fortigate The Tunnel comes up but there is no traffic transmittet trough the tunnel We pinged from the internel server (10.10.0.32) to the remote Server (10.0.1.13) i see the packets on the fortigate (see debug flow protokoll) but i donÂ´t see any reply i also see the packets with the sniffer (see sniffer protokoll) but still no reply The remote admin see the packets from me comming in and answered by his mashine (see remote side protokoll) but i donÂ´t see this packets on my side comming back again. Fortigate IPSEC-P1 config:

  config vpn ipsec phase1-interface      edit " IPSEC-P1-Emsys"           set interface " wan1"           set dhgrp 2          set proposal 3des-sha1          set keylife 86400          set remote-gw xxx.yyy.zzz.139          set psksecret ENC <shared-secret>      next  end

Fortigate IPSEC-P2 config:

  config vpn ipsec phase2-interface      edit " IPSEC-P2-Emsys"           set dhgrp 2          set keepalive enable          set pfs enable          set phase1name " IPSEC-P1-Emsys"           set proposal 3des-sha1          set dst-subnet 10.0.1.0 255.255.255.0          set keylifeseconds 3600          set src-subnet 10.10.0.0 255.255.0.0      next  end

Fortigate Firewall policies: Incoming policy

  config firewall policy      edit 15          set srcintf " IPSEC-P1-Emsys"           set dstintf " internal"               set srcaddr " Emsys-Netzwerk"               set dstaddr " Appl-Intranet"           set action accept          set schedule " always"               set service " ANY"       next  end

outgoing policy

  config firewall policy      edit 16          set srcintf " internal"           set dstintf " IPSEC-P1-Emsys"               set srcaddr " Appl-Intranet"               set dstaddr " Emsys-Netzwerk"           set action accept          set schedule " always"               set service " ANY"       next  end

Fortigate Addresses:

  config firewall address      edit " Appl-Intranet"           set associated-interface " internal"           set subnet 10.10.0.0 255.255.0.0      next  end  config firewall address      edit " Emsys-Netzwerk"           set associated-interface " IPSEC-P1-Emsys"           set subnet 10.0.1.0 255.255.255.0      next  end

Fortigate debug flow protokoll:

  FGT60B3908660513 # diagnose debug flow trace start 2    FGT60B3908660513 # id=20085 trace_id=1681 func=resolve_ip_tuple_fast line=2810 msg=" vd-root received a packet(proto=1, 10.10.0.32:5912->10.0.1.13:8) from internal."   id=20085 trace_id=1681 func=resolve_ip_tuple_fast line=2837 msg=" Find an existing session, id-00211841, original direction"   id=20085 trace_id=1681 func=ipv4_fast_cb line=57 msg=" enter fast path"   id=20085 trace_id=1681 func=ipsecdev_hard_start_xmit line=122 msg=" enter IPsec interface-IPSEC-P1-Emsys"   id=20085 trace_id=1681 func=esp_output4 line=467 msg=" encrypted, and send to xxx.yyy.zzz.139 with source AAA.BBB.CCC.238"   id=20085 trace_id=1681 func=ipsec_output_finish line=133 msg=" send to AAA.BBB.CCC.233 via intf-wan1"     id=20085 trace_id=1682 func=resolve_ip_tuple_fast line=2810 msg=" vd-root received a packet(proto=1, 10.10.0.32:5912->10.0.1.13:8) from internal."   id=20085 trace_id=1682 func=resolve_ip_tuple_fast line=2837 msg=" Find an existing session, id-00211841, original direction"   id=20085 trace_id=1682 func=ipv4_fast_cb line=57 msg=" enter fast path"   id=20085 trace_id=1682 func=ipsecdev_hard_start_xmit line=122 msg=" enter IPsec interface-IPSEC-P1-Emsys"   id=20085 trace_id=1682 func=esp_output4 line=467 msg=" encrypted, and send to xxx.yyy.zzz.139 with source AAA.BBB.CCC.238"   id=20085 trace_id=1682 func=ipsec_output_finish line=133 msg=" send to AAA.BBB.CCC.233 via intf-wan1"

Fortigate Sniffer protokoll:

  FGT60B3908660513 # diagnose sniffer packet any ' host 10.0.1.13'  3  interfaces=[any]  filters=[host 10.0.1.13]  1.302700 10.10.0.32 -> 10.0.1.13: icmp: echo request  0x0000   0000 0000 0001 000c 2945 cff6 0800 4500        ........)E....E.  0x0010   0054 0000 4000 4001 2573 0a0a 0020 0a00        .T..@.@.%s......  0x0020   010d 0800 4953 1718 2ab2 e6c4 414a 55d0        ....IS..*...AJU.  0x0030   0400 0809 0a0b 0c0d 0e0f 1011 1213 1415        ................  0x0040   1617 1819 1a1b 1c1d 1e1f 2021 2223 2425        ...........!" #$%  0x0050   2627 2829 2a2b 2c2d 2e2f 3031 3233 3435        &' ()*+,-./012345  0x0060   3637                                           67    1.302740 10.10.0.32 -> 10.0.1.13: icmp: echo request  0x0000   0000 0000 0000 0000 0000 0000 0800 4500        ..............E.  0x0010   0054 0000 4000 3f01 2673 0a0a 0020 0a00        .T..@.?.&s......  0x0020   010d 0800 4953 1718 2ab2 e6c4 414a 55d0        ....IS..*...AJU.  0x0030   0400 0809 0a0b 0c0d 0e0f 1011 1213 1415        ................  0x0040   1617 1819 1a1b 1c1d 1e1f 2021 2223 2425        ...........!" #$%  0x0050   2627 2829 2a2b 2c2d 2e2f 3031 3233 3435        &' ()*+,-./012345  0x0060   3637                                           67    2.329639 10.10.0.32 -> 10.0.1.13: icmp: echo request  0x0000   0000 0000 0001 000c 2945 cff6 0800 4500        ........)E....E.  0x0010   0054 0000 4000 4001 2573 0a0a 0020 0a00        .T..@.@.%s......  0x0020   010d 0800 0f4f 1718 2ab3 e7c4 414a 8ed3        .....O..*...AJ..  0x0030   0400 0809 0a0b 0c0d 0e0f 1011 1213 1415        ................  0x0040   1617 1819 1a1b 1c1d 1e1f 2021 2223 2425        ...........!" #$%  0x0050   2627 2829 2a2b 2c2d 2e2f 3031 3233 3435        &' ()*+,-./012345  0x0060   3637

Remote Side Cisco protokoll:

  ICMP echo-request from outside:10.10.0.32 to 10.0.1.13 ID=5912 seq=1780 length=64  3361: ICMP echo-request: translating outside:10.10.0.32 to inside:10.2.12.11  3362: ICMP echo-reply from inside:10.0.1.13 to 10.2.12.11 ID=5912 seq=1780 length=64  3363: ICMP echo-reply: untranslating inside:10.2.12.11 to outside:10.10.0.32

Any idee what problem we have ?

rwpatterson

New Member

Welcome to the forums. With interface mode policies, you need to add a static route back down the tunnel for returning traffic... Send 10.0.1.0/24 traffic back down the " IPSEC-P1-Emsys" tunnel.

Anonymous_UserAuthor

Contributor

on my side of the tunnel we have setup the following static routes

  edit 4          set device " IPSEC-P1-Emsys"           set dst 10.0.1.0 255.255.255.0  next

or do you mean a route on the other side of the tunnel at the cisco router? i ask because we donÂ´t know exactly the configuration of the cisco router ItÂ´s not configured by us. Regards

rwpatterson

New Member

No, what you have is correct. What does a traceroute show from the LAN?

Anonymous_UserAuthor

Contributor

here the traceroute from the server at the internal interface of the fortigate 10.10.0.1 is the fortigate 10.0.1.13 is a pingable server on the other side

  PSSAWESRV01:~# traceroute 10.0.1.13  traceroute to 10.0.1.13 (10.0.1.13), 30 hops max, 40 byte packets   1  10.10.0.1 (10.10.0.1)  3.625 ms  0.276 ms  0.277 ms   2  * * *   3  * * *   4  *

rwpatterson

New Member

The Cisco boys may need to add a static back to you.... If they run a traceroute and the traffic hits the Internet, you found the problem.

Anonymous_UserAuthor

Contributor

thats the answer on that from the " Cisco Boys" I have checked the loggings once again. I can see the packets from your side entering, my server sends a reply, and it goes through the firewall. I really think something is being blocked at your side.

Who is the fool now? ItÂ´s me again

g3rman

New Member

Here is a way to prove your point diagnose sniffer packet any ' host 10.0.1.13 or host XXX.YYY.ZZZ.139' Now you can see the outgoing pings as well as packets on port 500 to the Cisco firewall. You will see the icmp ping followed by a UDP 500 packet to the remote firewall. If the packets are actually encrypted on the remote side and sent back you should at least see a UDP 500 packet coming back from the remote firewall. If there is no UDP 500 from the remote firewall then you know for sure it' s on the remote end. I have used this method in a lot of cases where the remote side insisted their configuration was working. And in every single case I was able to prove that their configuration was bad and they eventually had to look and figure out where the problem was :)

Anonymous_UserAuthor

Contributor

Hello again thank you for this tip here are the output at line 137. the ping was startet from the inside server to the remote server [size=1]

    diagnose sniffer packet any ' host 10.0.1.13 or host xxx.yyy.zzz.139'      interfaces=[any]  filters=[host 10.0.1.13 or host xxx.yyy.zzz.139]  0.325727 xxx.yyy.zzz.139.500 -> AAA.BBB.CCC.238.500: udp 172  0.554582 xxx.yyy.zzz.139.500 -> AAA.BBB.CCC.238.500: udp 172  1.865384 xxx.yyy.zzz.139.500 -> AAA.BBB.CCC.238.500: udp 172  1.865434 xxx.yyy.zzz.139.500 -> AAA.BBB.CCC.238.500: udp 172  2.264660 xxx.yyy.zzz.139.500 -> AAA.BBB.CCC.238.500: udp 172  5.324775 xxx.yyy.zzz.139.500 -> AAA.BBB.CCC.238.500: udp 172    .  .  .  .  .  45.555418 xxx.yyy.zzz.139.500 -> AAA.BBB.CCC.238.500: udp 172  51.039926 xxx.yyy.zzz.139.500 -> AAA.BBB.CCC.238.500: udp 352  51.041446 AAA.BBB.CCC.238.500 -> xxx.yyy.zzz.139.500: udp 100  51.143344 xxx.yyy.zzz.139.500 -> AAA.BBB.CCC.238.500: udp 256  51.175829 AAA.BBB.CCC.238.500 -> xxx.yyy.zzz.139.500: udp 180  51.276803 xxx.yyy.zzz.139.500 -> AAA.BBB.CCC.238.500: udp 68  51.281502 AAA.BBB.CCC.238.500 -> xxx.yyy.zzz.139.500: udp 68  51.323903 xxx.yyy.zzz.139.500 -> AAA.BBB.CCC.238.500: udp 84  51.324468 xxx.yyy.zzz.139.500 -> AAA.BBB.CCC.238.500: udp 172  51.329935 AAA.BBB.CCC.238.500 -> xxx.yyy.zzz.139.500: udp 84  51.556746 xxx.yyy.zzz.139.500 -> AAA.BBB.CCC.238.500: udp 84  55.765353 xxx.yyy.zzz.139.500 -> AAA.BBB.CCC.238.500: udp 172  56.316778 xxx.yyy.zzz.139.500 -> AAA.BBB.CCC.238.500: udp 172  .  .  .    137.898364 xxx.yyy.zzz.139.500 -> AAA.BBB.CCC.238.500: udp 172  137.898416 xxx.yyy.zzz.139.500 -> AAA.BBB.CCC.238.500: udp 172  142.477898 10.10.0.32 -> 10.0.1.13: icmp: echo request  142.477985 10.10.0.32 -> 10.0.1.13: icmp: echo request  142.512715 AAA.BBB.CCC.238.500 -> xxx.yyy.zzz.139.500: udp 292  142.527333 xxx.yyy.zzz.139.500 -> AAA.BBB.CCC.238.500: udp 84  143.476616 10.10.0.32 -> 10.0.1.13: icmp: echo request  143.476645 10.10.0.32 -> 10.0.1.13: icmp: echo request  144.476560 10.10.0.32 -> 10.0.1.13: icmp: echo request  144.476594 10.10.0.32 -> 10.0.1.13: icmp: echo request  144.478381 AAA.BBB.CCC.238.500 -> xxx.yyy.zzz.139.500: udp 104  144.580308 xxx.yyy.zzz.139.500 -> AAA.BBB.CCC.238.500: udp 84  144.612735 AAA.BBB.CCC.238.500 -> xxx.yyy.zzz.139.500: udp 180  144.713433 xxx.yyy.zzz.139.500 -> AAA.BBB.CCC.238.500: udp 256  144.747626 AAA.BBB.CCC.238.500 -> xxx.yyy.zzz.139.500: udp 100  144.789254 xxx.yyy.zzz.139.500 -> AAA.BBB.CCC.238.500: udp 68  144.790619 xxx.yyy.zzz.139.500 -> AAA.BBB.CCC.238.500: udp 100  144.828780 AAA.BBB.CCC.238.500 -> xxx.yyy.zzz.139.500: udp 292  144.989654 xxx.yyy.zzz.139.500 -> AAA.BBB.CCC.238.500: udp 324  144.991814 AAA.BBB.CCC.238.500 -> xxx.yyy.zzz.139.500: udp 60  145.475813 10.10.0.32 -> 10.0.1.13: icmp: echo request  145.475844 10.10.0.32 -> 10.0.1.13: icmp: echo request  145.475965 AAA.BBB.CCC.238 -> xxx.yyy.zzz.139:  ip-proto-50 116  146.475895 10.10.0.32 -> 10.0.1.13: icmp: echo request  146.475933 10.10.0.32 -> 10.0.1.13: icmp: echo request  146.476003 AAA.BBB.CCC.238 -> xxx.yyy.zzz.139:  ip-proto-50 116  147.475870 10.10.0.32 -> 10.0.1.13: icmp: echo request  .  .    171.477868 10.10.0.32 -> 10.0.1.13: icmp: echo request  171.477906 10.10.0.32 -> 10.0.1.13: icmp: echo request  171.477972 AAA.BBB.CCC.238 -> xxx.yyy.zzz.139:  ip-proto-50 116  172.029199 xxx.yyy.zzz.139.500 -> AAA.BBB.CCC.238.500: udp 172  172.478264 10.10.0.32 -> 10.0.1.13: icmp: echo request  172.478298 10.10.0.32 -> 10.0.1.13: icmp: echo request  172.478365 AAA.BBB.CCC.238 -> xxx.yyy.zzz.139:  ip-proto-50 116  .  305 packets received by filter  0 packets dropped by kernel

[/size] iÂ´m not sure if this is now good or bad maybe someone else can explain me if the data comes back or not

severach

New Member

To help I switched one of my policy VPN over to this router' s first route VPN. After some missteps I got everything set up according to the example. The tunnel would come up but no traffic would pass either way. After checking way too many times for a missing step I restarted my router. Traffic passed. Here' s the sniffer output when it works. To help go to your policy screen and click â€œColumn Settingsâ€. Add â€œCountâ€ to your columns. Refresh to watch numbers go up on the policies that are being used. Local=192.168.0.0/24 Remote=172.16.0.0/24 Computer=192.168.0.11 Remote Router=172.16.0.1 diagnose sniffer packet any ' host 172.16.0.1 or host yu.yu.yu.yu' Ping 172.16.0.1 from 192.168.0.11 command line 817.782516 192.168.0.11 -> 172.16.0.1: icmp: echo request 817.782725 192.168.0.11 -> 172.16.0.1: icmp: echo request 817.782795 me.me.me.me -> yu.yu.yu.yu: ip-proto-50 92 817.848721 yu.yu.yu.yu -> me.me.me.me: ip-proto-50 92 817.848721 172.16.0.1 -> 192.168.0.11: icmp: echo reply 817.848868 172.16.0.1 -> 192.168.0.11: icmp: echo reply 818.783314 192.168.0.11 -> 172.16.0.1: icmp: echo request 818.783385 192.168.0.11 -> 172.16.0.1: icmp: echo request 818.783456 me.me.me.me -> yu.yu.yu.yu: ip-proto-50 92 818.849149 yu.yu.yu.yu -> me.me.me.me: ip-proto-50 92 818.849149 172.16.0.1 -> 192.168.0.11: icmp: echo reply 818.849257 172.16.0.1 -> 192.168.0.11: icmp: echo reply 819.783208 192.168.0.11 -> 172.16.0.1: icmp: echo request 819.783283 192.168.0.11 -> 172.16.0.1: icmp: echo request 819.783354 me.me.me.me -> yu.yu.yu.yu: ip-proto-50 92 819.849336 yu.yu.yu.yu -> me.me.me.me: ip-proto-50 92 819.849336 172.16.0.1 -> 192.168.0.11: icmp: echo reply 819.849438 172.16.0.1 -> 192.168.0.11: icmp: echo reply 820.783184 192.168.0.11 -> 172.16.0.1: icmp: echo request 820.783230 192.168.0.11 -> 172.16.0.1: icmp: echo request 820.783292 me.me.me.me -> yu.yu.yu.yu: ip-proto-50 92 820.849780 yu.yu.yu.yu -> me.me.me.me: ip-proto-50 92 820.849780 172.16.0.1 -> 192.168.0.11: icmp: echo reply 820.849888 172.16.0.1 -> 192.168.0.11: icmp: echo reply diagnose sniffer packet any ' (host 172.16.0.1 or host yu.yu.yu.yu) and port not 443' Ping 192.168.0.11 from 172.16.0.1 at remote router command line 305.032720 yu.yu.yu.yu -> me.me.me.me: ip-proto-50 116 305.032720 172.16.0.1 -> 192.168.0.11: icmp: echo request 305.032960 172.16.0.1 -> 192.168.0.11: icmp: echo request 305.033108 192.168.0.11 -> 172.16.0.1: icmp: echo reply 305.033159 192.168.0.11 -> 172.16.0.1: icmp: echo reply 305.033216 me.me.me.me -> yu.yu.yu.yu: ip-proto-50 116 306.028042 yu.yu.yu.yu -> me.me.me.me: ip-proto-50 116 306.028042 172.16.0.1 -> 192.168.0.11: icmp: echo request 306.028167 172.16.0.1 -> 192.168.0.11: icmp: echo request 306.028336 192.168.0.11 -> 172.16.0.1: icmp: echo reply 306.028363 192.168.0.11 -> 172.16.0.1: icmp: echo reply 306.028420 me.me.me.me -> yu.yu.yu.yu: ip-proto-50 116 307.026703 yu.yu.yu.yu -> me.me.me.me: ip-proto-50 116 307.026703 172.16.0.1 -> 192.168.0.11: icmp: echo request 307.026821 172.16.0.1 -> 192.168.0.11: icmp: echo request 307.026987 192.168.0.11 -> 172.16.0.1: icmp: echo reply 307.027015 192.168.0.11 -> 172.16.0.1: icmp: echo reply 307.027073 me.me.me.me -> yu.yu.yu.yu: ip-proto-50 116 308.026457 yu.yu.yu.yu -> me.me.me.me: ip-proto-50 116 308.026457 172.16.0.1 -> 192.168.0.11: icmp: echo request 308.026601 172.16.0.1 -> 192.168.0.11: icmp: echo request 308.026768 192.168.0.11 -> 172.16.0.1: icmp: echo reply 308.026797 192.168.0.11 -> 172.16.0.1: icmp: echo reply 308.026854 me.me.me.me -> yu.yu.yu.yu: ip-proto-50 116 309.026395 yu.yu.yu.yu -> me.me.me.me: ip-proto-50 116 309.026395 172.16.0.1 -> 192.168.0.11: icmp: echo request 309.026505 172.16.0.1 -> 192.168.0.11: icmp: echo request 309.026667 192.168.0.11 -> 172.16.0.1: icmp: echo reply 309.026695 192.168.0.11 -> 172.16.0.1: icmp: echo reply 309.026749 me.me.me.me -> yu.yu.yu.yu: ip-proto-50 116 The first thing I notice about your tunnel is that for a tunnel that doesn' t pass traffic there' s way too much activity which seems to be the Cisco harassing the Fortigate. Once my tunnels are up they generate no UDP:500 traffic until I start pinging. Then I tried to import your config parts into my router so I could see them in the GUI. I noticed that I had originally created my route VPN in the dmz and though wrong it did work. While importing yours and correcting mine to wan1 my config got so messed up that I couldn' t delete my own phase 1 interface that had no phase 2 interface, policies, or static routes which means the fgt_system.conf we see is only a shadow of a real configuration inside that can get fubar. I factoryreset and restored everything quickly through the CLI but did the route VPN by hand with no mistakes this time from the GUI. It pinged without restarting. With a fully working route VPN pings fail from the Fortigate CLI console even though it is allowed in the policy. Pings from the computer work fine. Restart to work, fubar config, and unable to ping from the router. That' s 3 problems that never occurred with policy VPN. I sense that route VPN are not ready for prime time in v3.00. Have you tried a policy VPN? Configuration is a lot less buggy and easier to get working and once you know the Cisco works you can spend all day making your route VPN work.

Anonymous_UserAuthor

Contributor

first thank you severach for the work i did not tried the policy based vpn route until now but i know that there is another interface based vpn tunnel from another customer to the same cisco pix and this tunnel works and a second thing is that i never have had so much trouble with a fortigate VPN tunnel before. we run more than 50 vpn interface tunnels with different ftg-models to many different firewalls on the remote side so i cannot say that the v3.00 is realy buggy i never experienced such problems before. i will try the policy based VPN and let you know if it works thx

Sign up

Login with SSO

Login to the community

Login with SSO

Scanning file for viruses.

This file cannot be downloaded