Support Forum
The Forums are a place to find answers on a range of Fortinet products from peers and product experts.
Mikelar
New Contributor

L2TP: invalid tunnel for incoming packet

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.

 

12 REPLIES 12
emnoc
Esteemed Contributor III

What does a diag debug flow show and how about your  diag vpn l2tp status ?

 

Also is your SIP and EIP range big enough for the number of tunnels your  supporting.

 

 

 

PCNSE 

NSE 

StrongSwan  

PCNSE NSE StrongSwan
ashukla_FTNT
Staff
Staff

it seems firewall side vpn went down but client is not aware and still sending traffic on old tunnel.

It may be because  dpd is only enabled on firewall side but not on client side.

In ike debug do you see R-U-There info message coming from client side?

emnoc
Esteemed Contributor III

FWIW; the diag vpn ike gateway cmd will show you  dpd rcv/txv is enabled

 

e.g

 

 diag vpn ike gate list name FGT2ciscoXE | grep DPD   DPD sent/recv: 00023c31/0eef19f1

PCNSE 

NSE 

StrongSwan  

PCNSE NSE StrongSwan
Mikelar
New Contributor

Thanks for the responses, very much appreciated. 

 

SIP & EIP has a range of about 50 addresses, which is more than enough. There's usually no more than 10 clients connected at any time.

 

I've attached log from the following outputs, mostly showing one of the affected clients disconnecting/reconnecting. The client is also continuously pinging an internal IP (replaced as "INTERNAL_PING_HOST_IP") throughout all testing.

 

Test details:

- client assigned IP = 10.136.16.54

- client L2TP tunnel = L2TP_4

- Approx. 5-6 other L2TP (live) users are connected during testing

- External/Internal IPs & PSK information has been removed

 

diag app l2tp status

diag vpn ike gateway

diag debug app ike -1

diag debug flow (filtered to 10.136.16.54; l2tp clients assigned IP)

 

A few further notes about the current config.

- Initially DPD was disabled, but was enabled as a possible fix

- NAT on the IPSec Policy has also been disabled & re-enabled as a possible fix.

Mikelar

 

INTFW0 # diag vpn ike gateway

vd: root/0 name: L2TP_4 version: 1 interface: wan1 26 addr: FW_WAN1_EXT_IP:4500 -> L2TP_CLIENT_WAN_IP:4500 created: 1437s ago IKE SA: created 1/1 established 1/1 time 180/180/180 ms IPsec SA: created 1/1 established 1/1 time 90/90/90 ms

id/spi: 835 ... direction: responder status: established 1437-1437s ago = 180ms proposal: 3des-sha1 key: ... lifetime/rekey: 28800/27092 DPD sent/recv: 00000000/00000000

 

I notice from the above the affected client is neither sending nor receiving DPD messages. I also can't see the 'R U THERE' messages as expected, though I'm sure I've seen them in previous logs.

 

L2TP config below:

 

INTFW0 # config vpn l2tp

INTFW0 (l2tp) # show config vpn l2tp set eip 10.136.16.100 set sip 10.136.16.50 set status enable set usrgrp "L2TP_Group" end

 

Mikelar

Diag Debug Flow filter 10.136.16.54

Diag debug flow trace start 1000

Mikelar

Additional flow log showing successful ping during L2TP dialup connection. About 3-5 pings will reply during the few seconds after the tunnel is established, then will constantly time out.

Mikelar

INTFW0 # diag vpn l2tp status

INTFW0 # 2015-02-16 15:25:41 --- l2tp status ------- 2015-02-16 15:25:41 Scheduler entries: 2015-02-16 15:25:41 1: HELLO to 3 2015-02-16 15:25:41 2: HELLO to 1 2015-02-16 15:25:41 3: HELLO to 2 2015-02-16 15:25:41 4: Monitor ctrl xmit for pkt 0x3162ee0 2015-02-16 15:25:41 5: Monitor ctrl xmit for pkt 0x3137e90 2015-02-16 15:25:41 6: HELLO to 9 2015-02-16 15:25:41 7: Monitor ctrl xmit for pkt 0x31202a0 2015-02-16 15:25:41 Total Events scheduled: 7 2015-02-16 15:25:41 ----------------------- 2015-02-16 15:25:41 num tunnels open: 141 2015-02-16 15:25:41 Total vdom: 1 2015-02-16 15:25:41 -----------------------

2015-02-16 15:38:07 Tunnel ID = 1285 (local id), 11 (remote id) to L2TP_CLIENT_WAN_IP:1701 control_seq_num = 2, control_rec_seq_num = 4, last recv pkt = 2 2015-02-16 15:38:07 Call ID = 1286 (local id), 1 (remote id), serno = 0, assigned ip = 10.136.16.54 data_seq_num = 222, tx = 39998 bytes (222), rx= 43520 bytes (286) 2015-02-16 15:36:07 --- Configurations ---- 2015-02-16 15:36:07 --VD 0: Startip = 10.136.16.50, Endip = 10.136.16.100 2015-02-16 15:36:07 -------------------------

 

Should there be that many tunnels open at any one time?

Does this output show that the firewall is not closing & deleting the tunnels after disconnection?

If this is the case, what section of the config should I be looking at to ensure tunnels are closed correctly?

 

From the IKE outputs, tunnels appear to be closed & destroyed correctly.

 

diag vpn ike status connection: 9/440 IKE SA: created 9/510 established 9/440 times 10/326/10300 ms IPsec SA: created 6/705 established 6/704 times 0/89/3110 ms

 

 

In addition to this, in the diag vpn L2TP status output I'm seeing lots of multiple tunnels for the same WAN IP. This leads me to believe that each time a client connects, a new L2TP tunnel is being established, but the old ones remain. Is this normal behaviour for L2TP?

 

emnoc
Esteemed Contributor III

Good diagnostic;

 

Was confused tho on the firewallpolicy debug but I don't think this is a policy issue. On the DPD it's probably  not being  negoiated between  the peers. You can use wireshark and isakmp filter to determine if the window clients submits vendorID for RFC 3706 DPD.

 

I would try a different host  and l2tp client and see if the problem follows. Or start looking at a supportcase  with TAC.

 

 

 

PCNSE 

NSE 

StrongSwan  

PCNSE NSE StrongSwan
Labels
Top Kudoed Authors