Debugging does not show rcv packets on ipsec tunnel

[John_Loop]

I have other ipsec tunnels on the same physical interface on FG600C. When I " diag sniffer packet tunnel none 1" I can see rcv/tmt packets fine on all tunnels except this one. I only see outgoing packets. I have a linux client where I can successfully " telnet add 80" at other end of tunnel, and it CONNECTs! WHen I run " tcpdump -i ppp0" I also see the return SYN/ACK packet. We are just bringing the services at the other end of the tunnel up, and this is all we have till next week.. VERY frustrating that I can' t believe my diag CLI? Any clue what is going on? The packet capture on the tunnel gives same result. tunnel is up and fine by all accounts in the GUI. packet count in status monitor shows tmt packets, not rcv.

[emnoc]

Asymmetrical routing would be my guess and traffic is not entering the tunnel. Did you do a traceroute? and both ways? What does your routing show?

[John_Loop]

Thanks, I have done a traceroute to a point at the end of the tunnel. Nothing, but 3 TTL packets come back that are OUTSIDE of the network defined for the tunnel. I won' t route them and the client doesn' t see them of course. So this does sound suspicious. But maybe these are [is] intervening points whose IP would not necessarily be of interest to the tunnel? But what is the possible cause when the client DOES see the SYN/ACK to a SYN, using tcpdump on the client, and the Fortigate does NOT see them? That would suggest that the routing is all in place. That boggles my mind. We will have additional test points tomorrow, so hope to update. Just hope my Fortigate is part of the problem. Thanks again for reply. John

[ede_pfau]

hi, I would assume that IPsec traffic is routed over the NP ASIC once the session is established. NP traffic is not ' seen' by the sniffer. There is an option to suppress ASIC offload for IPsec traffic (I don' t have it here right now - please have a look at the CLI reference for your OS version).

[John_Loop]

When the VPN SSL clients are on a corporate network, everybody has to go thru a proxy, and indeed, the SYNs to any port 80 on a device at far end of the tunnel are SYN/ACKed by the proxy while he continues the SYN downstream. And the proxy is encountered before the corporate network is transited, so believe that explains the behavior in that case. What is not quite so clear is the behavior was experienced at home, where there was no proxy, no corporate to worry about. This may be a proxy at the other end of the tunnel! So we are not quite clear what is going on there yet.....