IPSec VPN:dialin works for 1 ping only (SOLVED)

[ede_pfau]

Hello fellows, I' ve set up a dial-in IPSec VPN from my FG-50B to a remote FG-80C which has a fixed IP. I use aggressive mode with PSK. Both sides use interface mode. 192.168.234.1 | tunnel | (ext. 217.92.xxx.yyy, int: 192.168.10.0/24) The tunnel comes up OK. Now when I ping from local FG to remote FG only the very first ping packet will return (with a reasonable return time), all subsequent packets are discarded. This will only happen when the tunnel has not been up before. While the tunnel is up, no packets at all will pass. I cannot see anything strange while debugging (' diag deb app ike' , ' diag deb flow' ). The return route gets inserted OK as far as I can tell from the flow output. Even setting a static route on the remote FG (so that the dial-in network becomes known) does not help. It looks like in the moment the route get established the very first packet slips through; while the route exists, nothing else will pass. Does anybody have a clue what I am missing here? Ede

[abelio]

Now when I ping from local FG to remote FG only the very first ping packet will return (with a reasonable return time), all subsequent packets are discarded. This will only happen when the tunnel has not been up before. While the tunnel is up, no packets at all will pass.

it seems that there' s a strange alive route rounding there. If you keep the tunnel down, could you reach 192.168.10.x' s IPs some way? That' s could match your above description. What about ' get router info routing-table all' CLI command output? (with and/or tunnel dropped) Can you see something strange there?

[ede_pfau]

hello Abel, nice to hear from you. This is a difficult one. Here is the routing table before and after the tunnel-up: before tunnel-up: gate # get router info routing-table all S* 0.0.0.0/0 [1/0] via 217.0.118.44, ppp0 C 91.17.164.191/32 is directly connected, ppp0 S xxx.yyy.48.0/21 [2/0] is directly connected, MPImF, [0/50] S 192.168.10.0/24 [2/0] is directly connected, K-B, [0/50] S 192.168.40.0/24 [2/0] is directly connected, MVMA S 192.168.123.0/24 [2/0] is directly connected, af_berlin, [0/50] C 192.168.234.0/24 is directly connected, internal C 217.0.118.44/32 is directly connected, ppp0 tunnel up: gate # exe ping 192.168.10.5 PING 192.168.10.5 (192.168.10.5): 56 data bytes 64 bytes from 192.168.10.5: icmp_seq=1 ttl=255 time=74.8 ms Timeout ... Timeout ... Timeout ... Timeout ... --- 192.168.10.5 ping statistics --- 5 packets transmitted, 1 packets received, 80% packet loss round-trip min/avg/max = 74.8/74.8/74.8 ms after tunnel_up: gate # get router info routing-table all S* 0.0.0.0/0 [1/0] via 217.0.118.44, ppp0 C 91.17.164.191/32 is directly connected, ppp0 S xxx.yyy.48.0/21 [2/0] is directly connected, MPImF, [0/50] S 192.168.10.0/24 [2/0] is directly connected, K-B, [0/50] S 192.168.40.0/24 [2/0] is directly connected, MVMA S 192.168.123.0/24 [2/0] is directly connected, af_berlin, [0/50] C 192.168.234.0/24 is directly connected, internal C 217.0.118.44/32 is directly connected, ppp0 gate # diag ip route list (partially) tab=254 vf=0 scope=253 type=1 proto=2 prio=0 0.0.0.0/0.0.0.0/0->192.168.234.0/24 pref=192.168.234.1 gwy=0.0.0.0 dev=3(internal) tab=254 vf=0 scope=0 type=1 proto=11 prio=0 0.0.0.0/0.0.0.0/0->192.168.10.0/24 pref=0.0.0.0 gwy=0.0.0.0 dev=15(K-B) So, mainly I don' ' t see any difference. In interface mode, VPN gateways show up as ' directly connected' so I don' t need a static route here. Only if I wanted sessions originating at the remote end. Consequently I have not configured a static route back to 192.168.234.0/24 at the remote end. Would you? As to the idea about multiple paths: I don' t see any way to accomplish this as the remote LAN is a private LAN not mentioned elsewhere in the local firewall. There is a PPTP dialup VPN in addition which is not used at the moment...would my Windows box be influenced by this? Ede

[ede_pfau]

OK, progress of some sort: if I setup a FortiClient profile on my notebook and connect from home I get in! To connect, I have to give my notebook an IP from the remote LAN, e.g. 192.168.10.190. And now I can see a direct route back (on the remote FG): K-B # get router info routing-table all S* 0.0.0.0/0 [5/0] via 217.5.98.25, ppp0 C 192.168.10.0/24 is directly connected, internal S 192.168.10.190/32 [1/0] is directly connected, BEDV_0 C 217.5.98.25/32 is directly connected, ppp0 C 217.92.177.190/32 is directly connected, ppp0 where " BEDV_0" is the VPN tunnel end. How can I translate this into the firewall config?

[rwpatterson]

Run a traceroute from local to remote and watch where the traffic goes. If you have interface mode tunnels, you need to define a static route down the tunnel to the remote end subnet(s). In policy mode, it' s done automatically, but only for the next hop subnet.

[ede_pfau]

OK will check that but have to make a break for 12 hours now. Thanks so far. I' ll be back.

[ede_pfau]

traceroute will die all the way long, local and remote. At the local end, there is a static route pointing the remote LAN to the IPSec interface. I do see the back route in the routing table of the remote FG. How can I verify that the reply packets are routed correctly? I guess I cannot sniff on the VPN interface as it doesn' t have an IP address. Any thoughts?

[rwpatterson]

How far does it get? Does it die at the FGT?

[ede_pfau]

well, traceroute tends to conceal the situation a bit. What I see from packet sniffs and flow traces is that the first ping packet forces the tunnel UP, but gets dropped because the SA is not yet established. The second ping GETS TROUGH and is replied, just as expected. All subsequent pings are discarded somewhere. They will never show up at the remote end (sniff), traceroute shows ' all stars' .

[ede_pfau]

OK, Fortinet support finally has resolved this issue and I' d like to share my experience with others that might run into this trap: there is a new global parameter in v4.0 called " check-protocol-header" : (from CLI Guide) " check-protocol-header {loose | strict} Select the level of checking performed on protocol headers. default: loose" And of course, I set it to " strict" . Well, one effect of re-calculating the header checksum is that it will prohibit IPSec traffic - " cannot be used if Fortigate is used as IPSec VPN endpoint" . Not one word in the docs about this. This issue prevented an implementation for 11 days. Yee-haw.