Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 4 replies
  • Subscribers 3 subscribers
  • Views 1792 views
  • Users 0 members are here
Options
Suggested
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

Constant L2TP over IPSEC issues with iOS ...

Escape75

I have a pretty basic L2TP over IPSEC VPN server running on my UTM and it constantly requires re-adjustment to work ...

I can always connect to it from a Windows 10 computer, but connecting from an iOS device only works when the iOS device is on the same LAN as the UTM.
I have other L2TP over IPSEC servers (made by Ubiquty, etc.) that never have any issues when connection from iOS devices ...

(I believe this has started to happen after iOS 14.5 but I might be wrong, as I might've just tested from my LAN instead of going through WAN)

I can't think of anything else to try, I've played with the policy settings quite a bit ...



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

    Hi ,

    Thanks for reaching out to the Community! 

    Would it be possible for you to replicate the issue and collect the ipsec and aua logs from your UTM? 

    I'd also suggest you take a packet capture on port 1701 or the source public IP address to check if traffic from the remote device arrives on the firewall or blocked before it arrives at the firewall. 

    Thanks,

Reply
  • FormerMember
    0 FormerMember

    Hi ,

    Thanks for reaching out to the Community! 

    Would it be possible for you to replicate the issue and collect the ipsec and aua logs from your UTM? 

    I'd also suggest you take a packet capture on port 1701 or the source public IP address to check if traffic from the remote device arrives on the firewall or blocked before it arrives at the firewall. 

    Thanks,

Children
  • 0 in reply to FormerMember

    From my IOS device that isn't able to connect to my UTM, I can connect to another L2TP device just fine ...
    Previously I've had an Android device and I was able to connect to my UTM device just fine, however there should be a way to use iOS I would think ...

    I can also connect from an outside Windows 10 system to my UTM device, as well as connect from my IOS device to UTM when it's inside the UTM's LAN.

    There is nothing showing up in UAU Logs, and here's the IPSEC Logs:

    2021:04:30-10:32:06 escape75 pluto[5753]: packet from 72.113.234.39:13106: received Vendor ID payload [RFC 3947]
    2021:04:30-10:32:06 escape75 pluto[5753]: packet from 72.113.234.39:13106: ignoring Vendor ID payload [4df37928e9fc4fd1b3262170d515c662]
    2021:04:30-10:32:06 escape75 pluto[5753]: packet from 72.113.234.39:13106: ignoring Vendor ID payload [8f8d83826d246b6fc7a8a6a428c11de8]
    2021:04:30-10:32:06 escape75 pluto[5753]: packet from 72.113.234.39:13106: ignoring Vendor ID payload [439b59f8ba676c4c7737ae22eab8f582]
    2021:04:30-10:32:06 escape75 pluto[5753]: packet from 72.113.234.39:13106: ignoring Vendor ID payload [4d1e0e136deafa34c4f3ea9f02ec7285]
    2021:04:30-10:32:06 escape75 pluto[5753]: packet from 72.113.234.39:13106: ignoring Vendor ID payload [80d0bb3def54565ee84645d4c85ce3ee]
    2021:04:30-10:32:06 escape75 pluto[5753]: packet from 72.113.234.39:13106: ignoring Vendor ID payload [9909b64eed937c6573de52ace952fa6b]
    2021:04:30-10:32:06 escape75 pluto[5753]: packet from 72.113.234.39:13106: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-03]
    2021:04:30-10:32:06 escape75 pluto[5753]: packet from 72.113.234.39:13106: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02]
    2021:04:30-10:32:06 escape75 pluto[5753]: packet from 72.113.234.39:13106: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n]
    2021:04:30-10:32:06 escape75 pluto[5753]: packet from 72.113.234.39:13106: ignoring Vendor ID payload [FRAGMENTATION 80000000]
    2021:04:30-10:32:06 escape75 pluto[5753]: packet from 72.113.234.39:13106: received Vendor ID payload [Dead Peer Detection]
    2021:04:30-10:32:06 escape75 pluto[5753]: "L_for escape75"[8] 72.113.234.39:13106 #139: responding to Main Mode from unknown peer 72.113.234.39:13106
    2021:04:30-10:32:06 escape75 pluto[5753]: "L_for escape75"[8] 72.113.234.39:13106 #139: NAT-Traversal: Result using RFC 3947: both are NATed
    2021:04:30-10:32:06 escape75 pluto[5753]: | NAT-T: new mapping 72.113.234.39:13106/13077)
    2021:04:30-10:32:06 escape75 pluto[5753]: "L_for escape75"[8] 72.113.234.39:13077 #139: ignoring informational payload, type IPSEC_INITIAL_CONTACT
    2021:04:30-10:32:06 escape75 pluto[5753]: "L_for escape75"[8] 72.113.234.39:13077 #139: Peer ID is ID_IPV4_ADDR: '0.0.0.0'
    2021:04:30-10:32:06 escape75 pluto[5753]: "L_for escape75"[9] 72.113.234.39:13077 #139: deleting connection "L_for escape75"[8] instance with peer 72.113.234.39 {isakmp=#0/ipsec=#0}
    2021:04:30-10:32:06 escape75 pluto[5753]: "L_for escape75"[9] 72.113.234.39:13077 #139: Dead Peer Detection (RFC 3706) enabled
    2021:04:30-10:32:06 escape75 pluto[5753]: "L_for escape75"[9] 72.113.234.39:13077 #139: sent MR3, ISAKMP SA established
    2021:04:30-10:32:06 escape75 pluto[5753]: "L_for escape75"[4] 72.113.234.39:13077 #140: NAT-Traversal: received 2 NAT-OA. using first, ignoring others
    2021:04:30-10:32:06 escape75 pluto[5753]: "L_for escape75"[4] 72.113.234.39:13077 #140: responding to Quick Mode
    2021:04:30-10:32:07 escape75 pluto[5753]: "L_for escape75"[9] 72.113.234.39:13077 #139: ignoring informational payload, type INVALID_HASH_INFORMATION
    2021:04:30-10:32:07 escape75 pluto[5753]: "L_for escape75"[9] 72.113.234.39:13077 #139: received Delete SA payload: deleting ISAKMP State #139
    2021:04:30-10:32:07 escape75 pluto[5753]: "L_for escape75"[9] 72.113.234.39:13077 #139: deleting connection "L_for escape75"[4] instance with peer 72.113.234.39 {isakmp=#0/ipsec=#0}
    2021:04:30-10:32:07 escape75 pluto[5753]: "L_for escape75"[9] 72.113.234.39:13077: deleting connection "L_for escape75"[9] instance with peer 72.113.234.39 {isakmp=#0/ipsec=#0}
    2021:04:30-10:32:07 escape75 pluto[5753]: ERROR: asynchronous network error report on eth0 for message to 72.113.234.39 port 13077, complainant 72.113.234.39: Connection refused [errno 111, origin ICMP type 3 code 3 (not authenticated)]

  • 0 in reply to Escape75

    Hi,

    I have the following note that I copied from an Apple BB over a year ago:

    This will need to be resolved by the server administrator. ​We have upgraded the proposed ciphers in L2TP IPsec VPN to also propose SHA-256 for the Child SA in IPsec. The issue seems to be that the server is accepting SHA-256 cipher for the child but maybe dropping the ESP encrypted packets with SHA-256 HMAC. This maybe because the server is assuming a SHA-256 HMAC with 96 bits instead of the standard 128 bits. Switching the SHA-256 HMAC output from 96 to 128 bits should fix this issue.Thank you for your feedback

    It appears to me that you have corrected the Policy to conform to the note from Apple.  I have also made the change to the L2TP Policy and I confirm similar behavior to what you're now seeing.  I get a message on my iPhone: "The L2TP-VPN server did not respond."  However, I see something completely different in the IPsec Live Log after ISAKMP SA established:

    .16:60504 #20: sent MR3, ISAKMP SA established
    2021:05:01-15:42:23 secure pluto[29718]: "L_for SuperAdmins"[2] 166.xxx.yyy.16:60504 #20: cannot respond to IPsec SA request because no connection is known for 54.xxx.yyy.114/32===172.2x.0.20:4500[172.2x.0.20]:17/1701...166.xxx.yyy.16:60504[10.xxx.yyy.150]:17/%any==={10.xxx.yyy.150/32}
    2021:05:01-15:42:23 secure pluto[29718]: "L_for SuperAdmins"[2] 166.xxx.yyy.16:60504 #20: sending encrypted notification INVALID_ID_INFORMATION to 166.xxx.yyy.16:60504
    2021:05:01-15:42:26 secure pluto[29718]: "L_for SuperAdmins"[2] 166.xxx.yyy.16:60504 #20: Quick Mode I1 message is unacceptable because it uses a previously used Message ID 0x5f9a62c1 (perhaps this is a duplicated packet)
    2021:05:01-15:42:26 secure pluto[29718]: "L_for SuperAdmins"[2] 166.xxx.yyy.16:60504 #20: sending encrypted notification INVALID_MESSAGE_ID to 166.xxx.yyy.16:60504

    I've not had first-hand experience with this before because none of my clients have this issue as we use the excellent OpenVPN app from the Apple Store with the UTM's SSL VPN Remote Access.

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0 in reply to BAlfson

    It is interesting that your log is different, I'm on UTM 9.705-3 ...

    Thanks for confirming that the issue is happening for you as well,- I think it should be solved by the developers.

    I do have experience with Ubiquity edge routers and even without software updates they have been iOS compatible
    as far as L2TP goes since IOS 10 (as PPTP was dropped), and they are still working with the most recent iOS 14.5.

    It is quite unfortunate that UTM being such a great platform has a relatively "simple" issue like that, and of course
    switching to OpenVPN although a good solution doesn't work well for clients that want an "out of box" experience.

    I've seen many forum entries here about users complaining about iOS L2TP incompatibilities ...
    Maybe none of the developers have an iPhone so they cannot test this? Slight smile

    Update: I've updated to 9.706-8 and the issue remains, connecting from inside LAN works (to WAN interface), from outside it doesn't (to WAN interface).

Unfiltered HTML