L2TP: invalid tunnel for incoming packet

[Mikelar]

I'm hoping for a bit of advice or direction on some L2TP issues I'm facing. I recently implemented a 100D, and with it enabled L2TP. Clients are connecting via Windows dial-up, and authenticating via RADIUS.

Clients can connect & authenticate successfully, but once connected have mixed results. Some clients can access all internal resources successfully, others are unable to connect to anything (ping times out to all destinations). The firewall is also unable to ping the assigned IP for the L2TP host when this issue occurs, but will be able to ping other clients that do not face this issue. Sessions are also randomly dropped, and in some cases attempting to browse will suddenly drop all comms (continuous ping will be successful until browser is launched). 

I've been combing through debugs and packet traces, but I'm still at a loss to explain this behaviour as yet. I'm fairy sure my policy settings are correct, as some clients will be able to access all resources successfully. I'm now thinking it's either a Phase1 or Phase2 issue, specifically around the way the firewall will clear previous VPN sessions.

Phase 1 Config:

config vpn ipsec phase1 edit "L2TP" set type dynamic set interface "wan1" set proposal aes256-md5 3des-sha1 aes192-sha1 set dhgrp 2 set psksecret ENC xxxxxxxxxx set dpd-retryinterval 15 next end

Phase 2 Config:

config vpn ipsec phase2 edit "L2TP_P2" set phase1name "L2TP" set proposal aes256-md5 3des-sha1 aes192-sha1 set pfs disable set keylife-type both set encapsulation transport-mode set keylifeseconds 3600 set keylifekbs 250000 next end

diag debug app l2tp -1:

2015-02-13 17:24:44 handle_network_packet()-199: L2TP: invalid tunnel 1058 for incoming packet (call=1059). 2015-02-13 17:24:44 find_tunnel_call()-183: can't find tunnel 1058

From the above debug output, it appears the target L2TP tunnel is either non-existant or incorrectly assigned (possibly to another vpn client). This looks like it will hold the answer to my issue, but I'm not too sure what exactly is occurring to cause this.

Any advice would be very much appreciated. I'm happy to attempt any further configuration changes or provide any debug outputs that might help. The firewall is currently in production, so I'd very much appreciate any assistance that could be provided.

Cheers.

[Mikelar]

Thanks for your input, as always it is much appreciated.

I was hoping something in the above would stick out and someone could provide a clear answer, but it seems this is more in depth than I originally thought. I've logged a support ticket as suggested, so hopefully I'll see some result from this.

Cheers.

[Mikelar]

I've now put this down to a protocol mis-match with PPP. After further debugging, I think I can see where the issue is occurring.

I've attached a further debug log, with the following options:

diag deb app l2tp -1

diag deb app ppp -1

diag deb app pppoe -1

The attached log shows the below occurring:

1. Test hosts dials & connects successfully

2. Ping internal IP -t, receiving replies successfully

3. Open browser to any page, ping starts timing out, all comms stop (but client remains connected)

Sample output from step 2:

2015-02-18 14:34:25 PPP send: LCP Echo_Request id(1) len(8) [Magic_Number 240ce930] 2015-02-18 14:34:26 PPP recv: LCP Echo_Reply id(1) len(8) [Magic_Number 1a3e4065] 2015-02-18 14:34:30 PPP send: LCP Echo_Request id(2) len(8) [Magic_Number 240ce930] 2015-02-18 14:34:31 PPP recv: LCP Echo_Reply id(2) len(8) [Magic_Number 1a3e4065] 2015-02-18 14:34:35 PPP send: LCP Echo_Request id(3) len(8) [Magic_Number 240ce930] 2015-02-18 14:34:36 PPP recv: LCP Echo_Reply id(3) len(8) [Magic_Number 1a3e4065] 2015-02-18 14:34:40 PPP send: LCP Echo_Request id(4) len(8) [Magic_Number 240ce930] 2015-02-18 14:34:41 PPP recv: LCP Echo_Reply id(4) len(8) [Magic_Number 1a3e4065]

Sample output from step 3:

2015-02-18 14:34:48 PPP send: LCP Protocol_Reject id(45) len(65) 2015-02-18 14:34:48 PPP recv: 6621 2015-02-18 14:34:48 PPP send: LCP Protocol_Reject id(46) len(58) [66 unknown LCP Option type] 2015-02-18 14:34:48 PPP recv: B54B 2015-02-18 14:34:48 PPP send: LCP Protocol_Reject id(47) len(308) [B5 unknown LCP Option type] [41 unknown LCP Option type] 2015-02-18 14:34:49 PPP recv: 4200

I've tried playing with the PPP options on the client side (Enable LCP Extensions, Enable Software Compression, Negotiate multi-link for single-link connections), but I get the same output. I've also disabled IPv6 in the client's dialup VPN settings.

[Mikelar]

Followup for anyone else that may experience the same issue. 

I've logged a TAC ticket and was asked to provide additional logs and some further information. After providing everything requested, a tech remotely connected and ran some debug commands himself. Ultimately he faced the same issues, with almost no traffic from the affected hosts appearing on any of the firewall logs. 

We have since migrated our users to SSL VPN as a permanent workaround, so this is no longer a critical issue for us. I've advised the ticket can be closed or escalated for further testing at their discretion, but ultimately there is was no resolution to this issue.

Thanks all for your assistance and recommendations (including Fortinet Support), much appreciated. Best of luck to anyone else that faces this issue.

EDIT:

Just deleted the L2TP VPN tunnel from the fw config. A few minutes later ~300 log entries for disconnected L2TP clients appeared, about 10 for each IP. This is enough to convince me that the firewall was not correctly terminating PPP sessions for L2TP clients, and that whenever they'd reconnect, traffic would be passed to invalid tunnels.