Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 3 replies
  • Subscribers 6 subscribers
  • Views 1257 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

Remote Access L2TP over IPSEC: Certain User Accounts Unable to Obtain Internal IP via DHCP

Houndstooth

I have a very strange issue happening on our UTM. The issue is only affecting certain user accounts that have been setup for Remote Access through L2TP over VPN. For some reason, these accounts are unable to obtain an internal IP via the DHCP server that is setup on our domain. Other Remote Access users with the exact same account configuration can obtain a valid IP address from the same DHCP server no problem.

Here is a redacted log from one of the affected accounts:


Peer ID is ID_IPV4_ADDR: XXX.XXX.XXX.XXX
2021:03:26-10:04:37 pluto[6145]: "L_for bizcompass"[184] XXX.XXX.XXX.XXX:4500 #6227: deleting connection "L_for bizcompass"[183] instance with peer XXX.XXX.XXX.XXX{isakmp=#0/ipsec=#0}
2021:03:26-10:04:37 pluto[6145]: "L_for bizcompass"[184] XXX.XXX.XXX.XXX:4500 #6227: Dead Peer Detection (RFC 3706) enabled
2021:03:26-10:04:37 pluto[6145]: "L_for bizcompass"[184] XXX.XXX.XXX.XXX:4500 #6227: sent MR3, ISAKMP SA established
2021:03:26-10:04:38 pluto[6145]: "L_for bizcompass"[89] XXX.XXX.XXX.XXX:4500 #6228: NAT-Traversal: received 2 NAT-OA. using first, ignoring others
2021:03:26-10:04:38 pluto[6145]: "L_for bizcompass"[89] XXX.XXX.XXX.XXX:4500 #6228: responding to Quick Mode
2021:03:26-10:04:38 pluto[6145]: "L_for bizcompass"[89] XXX.XXX.XXX.XXX:4500 #6228: IPsec SA established {ESP=>0x014c9a0c <0xcb1e66e0 NATOA=192.168.4.43 DPD}
2021:03:26-10:04:38 pppd-l2tp[9179]: Plugin aua.so loaded.
2021:03:26-10:04:38 pppd-l2tp[9179]: AUA plugin initialized.
2021:03:26-10:04:38 pppd-l2tp[9179]: Plugin dhcpc.so loaded.
2021:03:26-10:04:38 pppd-l2tp[9179]: DHCPC: plugin initialized
2021:03:26-10:04:38 pppd-l2tp[9179]: Plugin pppol2tp.so loaded.
2021:03:26-10:04:38 pppd-l2tp[9179]: pppd 2.4.7 started by (unknown), uid 0
2021:03:26-10:04:38 pppd-l2tp[9179]: Using interface ppp1
2021:03:26-10:04:38 pppd-l2tp[9179]: Connect: ppp1 <-->
2021:03:26-10:04:38 pppd-l2tp[9179]: Overriding mtu 1500 to 1380
2021:03:26-10:04:38 pppd-l2tp[9179]: Overriding mru 1500 to mtu value 1380
2021:03:26-10:04:38 pppd-l2tp[9179]: Overriding mtu 1500 to 1380
2021:03:26-10:04:40 pppd-l2tp[9179]: DHCPC: Using relay address of 'XXX.XXX.XXX.XXX'
2021:03:26-10:04:40 pppd-l2tp[9179]: DHCPC: Unicasting to server 'XXX.XXX.XXX.XXX' only
2021:03:26-10:04:40 pppd-l2tp[9179]: DHCPC: Sending discover...
2021:03:26-10:04:42 pppd-l2tp[9179]: DHCPC: Sending discover...
2021:03:26-10:04:44 pppd-l2tp[9179]: DHCPC: Sending discover...
2021:03:26-10:04:54 pppd-l2tp[9179]: DHCPC: No lease, failing.
2021:03:26-10:04:54 pppd-l2tp[9179]: DHCPC: Failed to obtain an IP address. Terminating connection.
2021:03:26-10:04:54 pppd-l2tp[9179]: Exit.

I looked at the issue with a Sophos engineer a few weeks ago. He thought it was a one off. But now the issue is happening on another user's account.

Please let me know if I can provide any additional information that might be useful in troubleshooting this issue.

Thanks in advance for any advice you can offer.



This thread was automatically locked due to age.
  • 0

    It seems as though the issue is affecting accounts that share the same username with accounts created on the windows domain hosting the DHCP server. For example, Jsmith in AD users and Groups and Jsmith in Sophos users. When I delete Jsmith from AD, JSmith starts working on the UTM's Remote Access VPN. But there are other accounts that are in both places that are not experiencing this issue. Maybe this is a red-herring....but I wanted to pass it along.

  • 0 in reply to Houndstooth

    Best practice with UTM is to avoid creating JSmith locally in the UTM if JSmith is an account in AD.  Better to sync the JSmith account to the UTM and create a JSmithAdmin account on the UTM if necessary.

    My usual recommendation is to have the password to the "admin" account be known only to one person and for admin to be used to login to WebAdmin only when your AD server is down.  Otherwise each administrator should login with personal credentials.

    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

    This is great advice. I might end up going with an ad-hoc solution here due to the fact that I've inherited a UTM with users that have been created with all different types of naming conventions over the years. It might just make more sense to come up with a distinct convention for UTM users moving forward and recreate new accounts for those users experiencing this issue.

    The admin account best practice is noted and will be taken into consideration during this retooling.

    Thank you again!

Unfiltered HTML