New Member

Question

Ipsec Tunnels Issue (no traffic inbound)

11 replies
23642 views

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

Staff

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

Staff

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

New Member

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

ChemsAuthor

New Member

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

Staff

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.

ChemsAuthor

New Member

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

New Member

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

emnoc

New Member

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.

ChemsAuthor

New Member

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)

Christopher_McMullan

Staff

Can you sniff for protocol 50 traffic, to see if payloads are making it in both directions (or not)?

diag sniff pack wan1 "proto 50" 4

ChemsAuthor

New Member

From FGT 1

Christopher McMullan_FTNT wrote:
Can you sniff for protocol 50 traffic, to see if payloads are making it in both directions (or not)?

diag sniff pack wan1 "proto 50" 4

FW1 # diagnose sniffer packet wan1 "proto 50" 4
interfaces=[wan1]
filters=[proto 50]
0.645633 wan1 -- 192.168.99.254 -> 125.82.62.18: ip-proto-50 116
0.645716 wan1 -- 192.168.99.254 -> 125.82.62.18: ip-proto-50 116
0.645755 wan1 -- 192.168.99.254 -> 125.82.62.18: ip-proto-50 116
1.295463 wan1 -- 192.168.99.254 -> 125.82.62.18: ip-proto-50 116
1.309867 wan1 -- 192.168.99.254 -> 125.82.62.18: ip-proto-50 116
1.418372 wan1 -- 192.168.99.254 -> 125.82.62.18: ip-proto-50 116
2.308222 wan1 -- 192.168.99.254 -> 125.82.62.18: ip-proto-50 116
2.323156 wan1 -- 192.168.99.254 -> 125.82.62.18: ip-proto-50 116
3.322189 wan1 -- 192.168.99.254 -> 125.82.62.18: ip-proto-50 116
3.337118 wan1 -- 192.168.99.254 -> 125.82.62.18: ip-proto-50 116
3.430819 wan1 -- 192.168.99.254 -> 125.82.62.18: ip-proto-50 116
3.430901 wan1 -- 192.168.99.254 -> 125.82.62.18: ip-proto-50 116
3.430940 wan1 -- 192.168.99.254 -> 125.82.62.18: ip-proto-50 116
 
13 packets received by filter
0 packets dropped by kernel
 
FW1 #

From FGT 2

FW2 (Autre) # diagnose sniffer packet port5 "host 124.47.79.15" 4
interfaces=[port5]
filters=[host 124.47.79.15]
5.495922 port5 -- 124.47.79.15.500 -> 125.82.62.18.500: udp 92
5.496241 port5 -- 125.82.62.18.500 -> 124.47.79.15.500: udp 92
10.505199 port5 -- 124.47.79.15.500 -> 125.82.62.18.500: udp 92
10.505385 port5 -- 125.82.62.18.500 -> 124.47.79.15.500: udp 92
15.517360 port5 -- 124.47.79.15.500 -> 125.82.62.18.500: udp 92
15.517554 port5 -- 125.82.62.18.500 -> 124.47.79.15.500: udp 92
20.524145 port5 -- 124.47.79.15.500 -> 125.82.62.18.500: udp 92
20.524334 port5 -- 125.82.62.18.500 -> 124.47.79.15.500: udp 92
25.533544 port5 -- 124.47.79.15.500 -> 125.82.62.18.500: udp 92
25.533731 port5 -- 125.82.62.18.500 -> 124.47.79.15.500: udp 92
30.543820 port5 -- 124.47.79.15.500 -> 125.82.62.18.500: udp 92
30.544016 port5 -- 125.82.62.18.500 -> 124.47.79.15.500: udp 92

12 packets received by filter
0 packets dropped by kernel

FW2 (Autre) #

Reply packets doesn't appear ... good lead thanks

Sign up

Login with SSO

Login to the community

Login with SSO