IPSEC VPN tunnel up but no Data from the other side

[#1]

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]

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.

[#3]

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]

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

[#5]

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]

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.

[#7]

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]

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 :)

[#9]

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]

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.