This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

L2TP over IPSec Stopped working for one remote user

Hi,

the VPN connection of one of my users stopped working from her house. To the best of her knowledge, no changes were made to her home's gateway. She brought her computer into the office and I was able to connect from the guest network. But to be sure, I deleted and recreated the client connection and had her try again from home. No go. I can only assume that something did change on her home firewall, but I have no idea what.

UTM SG230
L2TP over IPSec
MacOS 10.14 using built-in VPN client

I use the same ISP from my own house, and am able to connect. I checked the logs from a successful (from my house) and unsuccessful (from her's) connection. Logs looks similar until the "duplicate packet" events.

(actual home IPs and usernames redacted with ***)

successful:

2021:02:15-21:12:32 kingarch pluto[6373]: "L_REF_IpsL2t1_1"[522] ***.***.***.***:4500 #2170: deleting connection "L_REF_IpsL2t1_1"[521] instance with peer ***.***.***.*** {isakmp=#0/ipsec=#0}
2021:02:15-21:12:32 kingarch pluto[6373]: "L_REF_IpsL2t1_1"[522] ***.***.***.***:4500 #2170: Dead Peer Detection (RFC 3706) enabled
2021:02:15-21:12:32 kingarch pluto[6373]: "L_REF_IpsL2t1_1"[522] ***.***.***.***:4500 #2170: sent MR3, ISAKMP SA established
2021:02:15-21:12:32 kingarch pluto[6373]: "L_REF_IpsL2t1_0"[248] ***.***.***.***:4500 #2171: NAT-Traversal: received 2 NAT-OA. using first, ignoring others
2021:02:15-21:12:32 kingarch pluto[6373]: "L_REF_IpsL2t1_0"[248] ***.***.***.***:4500 #2171: responding to Quick Mode
2021:02:15-21:12:32 kingarch pluto[6373]: "L_REF_IpsL2t1_0"[248] ***.***.***.***:4500 #2171: IPsec SA established {ESP=>0x0787fb97 <0x6f6c81e3 NATOA=192.168.113.16 DPD}
2021:02:15-21:12:33 kingarch pppd-l2tp[17966]: id="2201" severity="info" sys="SecureNet" sub="vpn" event="Connection started" username="*******" variant="l2tp" srcip="***.***.***.***" virtual_ip="10.242.3.7"

Unsuccessful:

2021:02:18-12:35:34 kingarch pluto[6373]: "L_REF_IpsL2t1_1"[704] ***.***.***.***:4500 #2956: deleting connection "L_REF_IpsL2t1_1"[703] instance with peer ***.***.***.*** {isakmp=#0/ipsec=#0}
2021:02:18-12:35:34 kingarch pluto[6373]: "L_REF_IpsL2t1_1"[704] ***.***.***.***:4500 #2956: Dead Peer Detection (RFC 3706) enabled
2021:02:18-12:35:34 kingarch pluto[6373]: "L_REF_IpsL2t1_1"[704] ***.***.***.***:4500 #2956: sent MR3, ISAKMP SA established
2021:02:18-12:35:37 kingarch pluto[6373]: "L_REF_IpsL2t1_1"[704] ***.***.***.***:4500 #2956: retransmitting in response to duplicate packet; already STATE_MAIN_R3
2021:02:18-12:35:40 kingarch pluto[6373]: "L_REF_IpsL2t1_1"[704] ***.***.***.***:4500 #2956: retransmitting in response to duplicate packet; already STATE_MAIN_R3
2021:02:18-12:35:43 kingarch pluto[6373]: "L_REF_IpsL2t1_1"[704] ***.***.***.***:4500 #2956: discarding duplicate packet -- exhausted retransmission; already STATE_MAIN_R3
2021:02:18-12:35:56 kingarch pluto[6373]: "L_REF_IpsL2t1_1"[704] ***.***.***.***:4500 #2956: discarding duplicate packet -- exhausted retransmission; already STATE_MAIN_R3
2021:02:18-12:38:01 kingarch pluto[6373]: packet from ***.***.***.***:500: received Vendor ID payload [RFC 3947]

it then seems  to try to connect again before getting to...

2021:02:18-12:38:02 kingarch pluto[6373]: "L_REF_IpsL2t1_1"[704] ***.***.***.***:4500 #2957: Dead Peer Detection (RFC 3706) enabled
2021:02:18-12:38:02 kingarch pluto[6373]: "L_REF_IpsL2t1_1"[704] ***.***.***.***:4500 #2957: sent MR3, ISAKMP SA established
2021:02:18-12:38:05 kingarch pluto[6373]: "L_REF_IpsL2t1_1"[704] ***.***.***.***:4500 #2957: retransmitting in response to duplicate packet; already STATE_MAIN_R3
2021:02:18-12:38:06 kingarch pluto[6373]: "L_REF_IpsL2t1_1"[704] ***.***.***.***:4500 #2956: DPD: Phase1 state #2956 has been superseded by #2957 - timeout ignored
2021:02:18-12:38:08 kingarch pluto[6373]: "L_REF_IpsL2t1_1"[704] ***.***.***.***:4500 #2957: retransmitting in response to duplicate packet; already STATE_MAIN_R3
2021:02:18-12:38:11 kingarch pluto[6373]: "L_REF_IpsL2t1_1"[704] ***.***.***.***:4500 #2957: discarding duplicate packet -- exhausted retransmission; already STATE_MAIN_R3
2021:02:18-12:38:24 kingarch pluto[6373]: "L_REF_IpsL2t1_1"[704] ***.***.***.***:4500 #2957: discarding duplicate packet -- exhausted retransmission; already STATE_MAIN_R3
2021:02:18-12:40:26 kingarch pluto[6373]: "L_REF_IpsL2t1_1"[704] ***.***.***.***:4500 #2957: DPD: No response from peer - declaring peer dead
2021:02:18-12:40:26 kingarch pluto[6373]: "L_REF_IpsL2t1_1"[704] ***.***.***.***:4500 #2957: DPD: Terminating all SAs using this connection
2021:02:18-12:40:26 kingarch pluto[6373]: "L_REF_IpsL2t1_1"[704] ***.***.***.***:4500 #2957: deleting connection "L_REF_IpsL2t1_1"[704] instance with peer ***.***.***.*** {isakmp=#2957/ipsec=#0}

I searched for these duplicate packet entries but cannot find any concrete answer to what they mean, if they're relevant, what to do about it, and why it just started happening (and only with one user).

Thanks,

Jeff



This thread was automatically locked due to age.
  • FormerMember
    0 FormerMember

    Hi ,

    Thank you for reaching out to the Community! 

    The STATE_MAIN_R2 or STATE_MAIN_R3 messages(From the UTM) aren’t getting to the workstation and could be blocked by the firewall at the user's location. The duplicate packets could be the response to the client's message STATE_MAIN_I2 or STATE_MAIN_I3. If the workstation is located behind a NAT router, check if UDP 4500 is allowed or not. 

    You could also turn on debug for L2TP on UTM to collect the verbose logs.

    Thanks,

  • I turned on debug and retried but got no other entries or information (?).

    On the client's gateway (Verizon Fios G3100), neither ports 500 nor 4500 appear in the logs, either allowed or dropped.

    I can ping the client's WAN address from our office, and the first phase of the connection is happening (it looks like).

  • And today it is working fine. I change nothing on the client side, and the only thing I change on the UTM had nothing to do with VPNs or her IP address (I made a couple tweaks to my SIP settings). Only thing I can think of is maybe Verizon pushed out another update last night to fix what they broke. Thanks,

    Jeff