Ipsec Tunnels Issue (no traffic inbound)

[Chems]

Hi guys,

I have a 310B cluster connected with a dozen of fortigates 60/80c through IPSEC tunnels.

A lot of tunnels are UP and are traffic OK.

But for an unknown reason, some other tunnels remains UP, traffic is ok only by one side, the other I have 0kb in Inbound 60/80 interface. 

310 > 60/80 = KO

60 > 310 = OK

The configurations didn't change, but traffic some times doesn't work anymore.

Someone any idea ?

Thanks all !

[ashukla_FTNT]

Have you verified that traffic is not working or only relying on counters?

Is there private ip on one side of vpn (on wan interface)?

Have you done flow debugs or sniffer?

[Christopher_McMullan]

ashukla wrote:

Have you verified that traffic is not working or only relying on counters?

Is there private ip on one side of vpn (on wan interface)?

Have you done flow debugs or sniffer?

Is the FortiGate behind another NAT device? It's not impossible to have a tunnel endpoint with a private address, but the details need to be configured right. The first packet capture you provided always had a private source.

[patrick_z]

Hi,

did you check if you tick "Allow traffic to be initiated from the remote site" at the policy on both ends?

What does a simple trace show?

Not enough information to advice something .... sorry

Cheers, Patrick

[Chems]

the matter is that on one node, I have 0 traffic in INBOUND.

on the other FG, IN and OUTBOUND traffic are ok.

No blocked traffic in log an debug

FG60C # diagnose sniffer packet Paris-Italy
interfaces=[Paris-Italy]
filters=[none]
pcap_lookupnet: Paris-Italy: no IPv4 address assigned
1.088756 192.168.10.53.50919 -> 10.0.44.8.53: udp 38
1.318772 192.168.10.56.63079 -> 10.82.1.17.53: udp 70
1.318924 192.168.10.56.63079 -> 10.0.44.8.53: udp 70
1.319014 192.168.10.56.63079 -> 10.0.108.12.53: udp 70
1.319103 192.168.10.56.63079 -> 10.1.9.0.47.53: udp 70
1.465191 192.168.10.58.65435 -> 10.1.3.57.14.13000: syn 2011450647
1.729679 192.168.10.58.58965 -> 10.82.1.17.53: udp 42
1.729855 192.168.10.58.58965 -> 10.0.44.8.53: udp 42
1.729948 192.168.10.58.58965 -> 10.0.108.12.53: udp 42
1.730037 192.168.10.58.58965 -> 10.1.9.0.47.53: udp 42
1.915528 192.168.10.53.51464 -> 10.82.1.17.53: udp 43
1.915708 192.168.10.53.51464 -> 10.0.44.8.53: udp 43
....
19 packets received by filter
0 packets dropped by kernel

FG60C #

[ashukla_FTNT]

Chems wrote:

the matter is that on one node, I have 0 traffic in INBOUND.

on the other FG, IN and OUTBOUND traffic are ok.

No blocked traffic in log an debug

FG60C # diagnose sniffer packet Paris-Italy
interfaces=[Paris-Italy]
filters=[none]
pcap_lookupnet: Paris-Italy: no IPv4 address assigned
1.088756 192.168.10.53.50919 -> 10.0.44.8.53: udp 38
1.318772 192.168.10.56.63079 -> 10.82.1.17.53: udp 70
1.318924 192.168.10.56.63079 -> 10.0.44.8.53: udp 70
1.319014 192.168.10.56.63079 -> 10.0.108.12.53: udp 70
1.319103 192.168.10.56.63079 -> 10.1.9.0.47.53: udp 70
1.465191 192.168.10.58.65435 -> 10.1.3.57.14.13000: syn 2011450647
1.729679 192.168.10.58.58965 -> 10.82.1.17.53: udp 42
1.729855 192.168.10.58.58965 -> 10.0.44.8.53: udp 42
1.729948 192.168.10.58.58965 -> 10.0.108.12.53: udp 42
1.730037 192.168.10.58.58965 -> 10.1.9.0.47.53: udp 42
1.915528 192.168.10.53.51464 -> 10.82.1.17.53: udp 43
1.915708 192.168.10.53.51464 -> 10.0.44.8.53: udp 43
....
19 packets received by filter
0 packets dropped by kernel

FG60C #

You say no traffic and provide an example where the traffic is coming :)

Could you please elaborate you problem with data in detail.

[Chems]

its normal, as I explained and you can see above, the traffic is only outgoing, no incoming data from the other gateway.

on the 310b GW:

internal : incoming/outcoming packets OK

ipsec interface :  incoming/outcoming packets OK

on the other GW :

ipsec interface : no incoming packets,  only outgoing

internale :  no incoming packets, only outgoing

[rwpatterson]

Check the 'other' side and verify that traffic is indeed going through the tunnels and not the default gateway. Check the routing.

[emnoc]

The diag debug flow command is your best friend. Also if these are  route-based vpns do you have the proper routing.

I would do what Bog suggested plus validate you have  SPIs in/oubound that matches the out/in at the hub.

[Chems]

emnoc wrote:

The diag debug flow command is your best friend. Also if these are  route-based vpns do you have the proper routing.

I would do what Bog suggested plus validate you have  SPIs in/oubound that matches the out/in at the hub.

Hi,

The matter is still on ...

The SPIs exactly match on both sides.

Packets are well leaving the vpn-interface of the 1st vpn gateway .. but never arrive on the vpn-interface of the 2nd vpn gw.

This is like something is dropping inside the tunnel Oo ..

Nothing comes up with diag debug (cause the tunnel is right up)