Skip to main content
Mikelar
Mikelar
New Member
February 13, 2015
Question

L2TP: invalid tunnel for incoming packet

  • February 13, 2015
  • 4 replies
  • 18337 views

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.

 

    4 replies

    emnoc
    emnoc
    New Member
    February 14, 2015

    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.

     

     

     

    ashukla_FTNT
    Staff
    ashukla_FTNT
    Staff
    February 14, 2015

    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
    emnoc
    New Member
    February 14, 2015

    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

    Mikelar
    MikelarAuthor
    New Member
    February 16, 2015

    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
    MikelarAuthor
    New Member
    February 16, 2015

     

    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

     

    emnoc
    emnoc
    New Member
    February 16, 2015

    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.

     

     

     

    Mikelar
    MikelarAuthor
    New Member
    February 16, 2015

    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
    MikelarAuthor
    New Member
    February 18, 2015

    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.

    Terms & ConditionsAccessibility statement