Guest User!

You are not Sophos Staff.

Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 5 replies
  • Subscribers 1 subscriber
  • Views 1984 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

[UTM 9.0000-8] Random timeouts when connecting via L2TP/IPSec?

Astaro Commando
Ever since I loaded UTM9, I've been having sporatic issues with connecting to my UTM9 server via VPN. Sometimes it connects fine, sometimes I will get a timed out error.

A current "patch" is for me to VPN into another location I have access to and then VPN to my UTM9 server. Works fine. Because of this, it looks like it is a source IP address/Location issue. The UTM9 server is simply rejecting connections from certain places. I do have country blocking enabled - but not for the USA.

Any ideas?

Will post the LiveLog output in a bit


This thread was automatically locked due to age.
  • 0 
    2012:08:04-21:36:30 [UTM9 Server Name] pluto[6442]: packet from [Connecting VPN Client IP Address]:3568: received Vendor ID payload [MS NT5 ISAKMPOAKLEY 00000008]
    2012:08:04-21:36:30 [UTM9 Server Name] pluto[6442]: packet from [Connecting VPN Client IP Address]:3568: received Vendor ID payload [RFC 3947]
    2012:08:04-21:36:30 [UTM9 Server Name] pluto[6442]: packet from [Connecting VPN Client IP Address]:3568: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n]
    2012:08:04-21:36:30 [UTM9 Server Name] pluto[6442]: packet from [Connecting VPN Client IP Address]:3568: ignoring Vendor ID payload [FRAGMENTATION]
    2012:08:04-21:36:30 [UTM9 Server Name] pluto[6442]: packet from [Connecting VPN Client IP Address]:3568: ignoring Vendor ID payload [MS-Negotiation Discovery Capable]
    2012:08:04-21:36:30 [UTM9 Server Name] pluto[6442]: packet from [Connecting VPN Client IP Address]:3568: ignoring Vendor ID payload [Vid-Initial-Contact]
    2012:08:04-21:36:30 [UTM9 Server Name] pluto[6442]: packet from [Connecting VPN Client IP Address]:3568: ignoring Vendor ID payload [IKE CGA version 1]
    2012:08:04-21:36:30 [UTM9 Server Name] pluto[6442]: "S_for [Connecting VPN Client User Name]"[84] [Connecting VPN Client IP Address]:3568 #95: responding to Main Mode from unknown peer [Connecting VPN Client IP Address]:3568
    2012:08:04-21:36:30 [UTM9 Server Name] pluto[6442]: "S_for [Connecting VPN Client User Name]"[84] [Connecting VPN Client IP Address]:3568 #95: ECP_384 is not supported. Attribute OAKLEY_GROUP_DESCRIPTION
    2012:08:04-21:36:30 [UTM9 Server Name] pluto[6442]: "S_for [Connecting VPN Client User Name]"[84] [Connecting VPN Client IP Address]:3568 #95: ECP_256 is not supported. Attribute OAKLEY_GROUP_DESCRIPTION
    2012:08:04-21:36:30 [UTM9 Server Name] pluto[6442]: "S_for [Connecting VPN Client User Name]"[84] [Connecting VPN Client IP Address]:3568 #95: NAT-Traversal: Result using RFC 3947: peer is NATed
    2012:08:04-21:36:30 [UTM9 Server Name] pluto[6442]: "S_for [Connecting VPN Client User Name]"[84] [Connecting VPN Client IP Address]:3568 #95: Peer ID is ID_IPV4_ADDR: '192.168.1.5'
    2012:08:04-21:36:30 [UTM9 Server Name] pluto[6442]: "S_for [Connecting VPN Client User Name]"[85] [Connecting VPN Client IP Address]:3568 #95: deleting connection "S_for [Connecting VPN Client User Name]"[84] instance with peer [Connecting VPN Client IP Address] {isakmp=#0/ipsec=#0}
    2012:08:04-21:36:30 [UTM9 Server Name] pluto[6442]: | NAT-T: new mapping [Connecting VPN Client IP Address]:3568/3570)
    2012:08:04-21:36:30 [UTM9 Server Name] pluto[6442]: "S_for [Connecting VPN Client User Name]"[85] [Connecting VPN Client IP Address]:3570 #95: sent MR3, ISAKMP SA established
    2012:08:04-21:36:31 [UTM9 Server Name] pluto[6442]: "S_for [Connecting VPN Client User Name]"[85] [Connecting VPN Client IP Address]:3570 #96: NAT-Traversal: received 2 NAT-OA. using first, ignoring others
    2012:08:04-21:36:31 [UTM9 Server Name] pluto[6442]: "S_for [Connecting VPN Client User Name]"[85] [Connecting VPN Client IP Address]:3570 #96: responding to Quick Mode
    2012:08:04-21:36:31 [UTM9 Server Name] openl2tpd[25035]: FUNC: tunl 17922: allocated context using profile 'default', created by network request
    2012:08:04-21:36:31 [UTM9 Server Name] openl2tpd[25035]: PROTO: tunl 17922: SCCRQ received from peer 11
    2012:08:04-21:36:31 [UTM9 Server Name] openl2tpd[25035]: FSM: CCE(17922) event SCCRQ_ACCEPT in state IDLE
    2012:08:04-21:36:31 [UTM9 Server Name] openl2tpd[25035]: PROTO: tunl 17922: adjust tx_window_size: peer=8, ours=10
    2012:08:04-21:36:31 [UTM9 Server Name] openl2tpd[25035]: PROTO: tunl 17922: sending SCCRP to peer 11
    2012:08:04-21:36:31 [UTM9 Server Name] openl2tpd[25035]: FSM: CCE(17922) state change: IDLE --> WAITCTLCONN
    2012:08:04-21:36:31 [UTM9 Server Name] pluto[6442]: "S_for [Connecting VPN Client User Name]"[85] [Connecting VPN Client IP Address]:3570 #96: IPsec SA established {ESP=>0x92744b5d  CLOSING
    2012:08:04-21:36:41 [UTM9 Server Name] openl2tpd[25035]: FSM: CCE(17922) event XPRT_DOWN in state CLOSING
    2012:08:04-21:36:52 [UTM9 Server Name] pluto[6442]: ERROR: asynchronous network error report on eth1 for message to [Connecting VPN Client IP Address] port 10355, complainant [Connecting VPN Client IP Address]: Connection refused [errno 111, origin ICMP type 3 code 3 (not authenticated)]
    2012:08:04-21:37:06 [UTM9 Server Name] pluto[6442]: "S_for [Connecting VPN Client User Name]"[85] [Connecting VPN Client IP Address]:3570 #95: received Delete SA(0x92744b5d) payload: deleting IPSEC State #96
    2012:08:04-21:37:06 [UTM9 Server Name] pluto[6442]: "S_for [Connecting VPN Client User Name]"[85] [Connecting VPN Client IP Address]:3570 #95: received Delete SA payload: deleting ISAKMP State #95
    2012:08:04-21:37:06 [UTM9 Server Name] pluto[6442]: "S_for [Connecting VPN Client User Name]"[85] [Connecting VPN Client IP Address]:3570: deleting connection "S_for [Connecting VPN Client User Name]"[85] instance with peer [Connecting VPN Client IP Address] {isakmp=#0/ipsec=#0}
    2012:08:04-21:37:21 [UTM9 Server Name] pluto[6442]: "S_for [Connecting VPN Client User Name]"[83] [Connecting VPN Client IP Address]:10355 #93: DPD: No response from peer - declaring peer dead
    2012:08:04-21:37:21 [UTM9 Server Name] pluto[6442]: "S_for [Connecting VPN Client User Name]"[83] [Connecting VPN Client IP Address]:10355 #93: DPD: Terminating all SAs using this connection
    2012:08:04-21:37:21 [UTM9 Server Name] pluto[6442]: "S_for [Connecting VPN Client User Name]"[83] [Connecting VPN Client IP Address]:10355 #93: deleting connection "S_for [Connecting VPN Client User Name]"[83] instance with peer [Connecting VPN Client IP Address] {isakmp=#93/ipsec=#94}
    2012:08:04-21:37:21 [UTM9 Server Name] pluto[6442]: "S_for [Connecting VPN Client User Name]" #94: deleting state (STATE_QUICK_R2)
    2012:08:04-21:37:21 [UTM9 Server Name] pluto[6442]: "S_for [Connecting VPN Client User Name]" #93: deleting state (STATE_MAIN_R3)
    2012:08:04-21:37:22 [UTM9 Server Name] pluto[6442]: ERROR: asynchronous network error report on eth1 for message to [Connecting VPN Client IP Address] port 10355, complainant [Connecting VPN Client IP Address]: Connection refused [errno 111, origin ICMP type 3 code 3 (not authenticated)]
    2012:08:04-21:37:22 [UTM9 Server Name] pluto[6442]: ERROR: asynchronous network error report on eth1 for message to [Connecting VPN Client IP Address] port 10355, complainant [Connecting VPN Client IP Address]: Connection refused [errno 111, origin ICMP type 3 code 3 (not authenticated)]
    2012:08:04-21:37:40 [UTM9 Server Name] openl2tpd[25035]: FUNC: tunl 17922 deleted
    2012:08:04-21:37:40 [UTM9 Server Name] openl2tpd[25035]: FUNC: tunl 17922: deleting context


    Here is the VPN LiveLog output as I try to establish connection from one of the offending IP addresses. I've have replaced some info for obvious reasons. Should be pretty easy to spot what I replaced
  • 0
    It's hard to know where to start...
    [LIST=1]
    • What OS and L2TP/IPsec client are you using?
    • Are you using certificates instead of a Preshared key?
    • If you use the same laptop from a different location, do you have the same problem?
    • When you say that you VPN into another location, what VPN server is there?
    • Do you mean that you VPN in, RDP to a PC there and then VPN from that PC?
    • What OS and client are on that PC?
    • Are you having "random timeouts" where you connect and then are kicked off?
    [/LIST]
    A couple things to check.  Are DPD and NAT-T enabled on the 'Advanced' tab of IPsec?  Does the IP subnet of the LAN of the client overlap at all with any subnet otherwise known to the Astaro?

    Cheers - Bob
  • 0 in reply to BAlfson
    It's hard to know where to start...
    [LIST=1]
    • What OS and L2TP/IPsec client are you using?
    • Are you using certificates instead of a Preshared key?
    • If you use the same laptop from a different location, do you have the same problem?
    • When you say that you VPN into another location, what VPN server is there?
    • Do you mean that you VPN in, RDP to a PC there and then VPN from that PC?
    • What OS and client are on that PC?
    • Are you having "random timeouts" where you connect and then are kicked off?
    [/LIST]
    A couple things to check.  Are DPD and NAT-T enabled on the 'Advanced' tab of IPsec?  Does the IP subnet of the LAN of the client overlap at all with any subnet otherwise known to the Astaro?

    Cheers - Bob


    1. I have seen it happen on both Windows 7 and Android. Stock clients
    2. PSK
    3. Depends on location/public IP address of connecting client. If another laptop on an offending network has the same WAN IP address, it has the same problem
    4.I am VPNing to a server I have out in San Francisco. When I VPN, my internet is routed through the VPN's gateway rather than the gateway on the local network. That's why it's a useful workaround. 
    5. Establish VPN connection to server in SF and then establish VPN connection to UTM9 Server
    6.n/a (?)
    7.Negative

    Subnets are technically overlapping. (I think) Current subnet mask is 255.255.255.0 When an L2TP client establishes a connection, the UTM9 assigns an IP of 192.168.1.2 and so on. To avoid conflicts, I have the DHCP server handing out IP's starting at 192.168.1.20.

    I understand that this is the incorrect way to do this but this is my home network and this was a quick fix that I never got around to fixing properly. To rectify the issue, I plan on migrating to a Class A network IP structure and modifying my subnet mask so that 10.10.x.x are all addresses that are supported. That way, I can put the L2TP clients on 10.10.2.x and my local clients on 10.10.1.x With this new configuration, the L2TP clients can actually communicate with everything on my local network. (My original problem was that L2TP clients could not communicate with local clients with the stock Astaro configuration, I see my error now)

    Now that I think of it, the problem in the OP might be related to the fact that a client VPN that has this problem is usually on a network that has a 192.168.1.x address. By routing my traffic though my SF VPN server, the IP address is 10.246.x.x
  • 0
    Now that I think of it, the problem in the OP might be related to the fact that a client VPN that has this problem is usually on a network that has a 192.168.1.x address. By routing my traffic though my SF VPN server, the IP address is 10.246.x.x

    I think you got it.  In general, the "stock" VPN Pools should be used for the various Remote Access methods.

    In specific, don't have the same DHCP server in use for VPN users as for internal users.  When internal devices try to respond to IPs in their local subnet, they broadcast an ARP request to see which local MAC address they should talk to - the remote client isn't in the internal Ethernet network, so there's no response to the ARP request and the device gives up.  If the IP is not in the local subnet, the device knows to send its message to the MAC address of its default gateway.

    If you were having problems reaching internal devices, there's another potential "gotcha" in Network/Host definitions.  Check to be sure that none are bound to a specific interface and that each one has been left at 'Interface: >'.

    Cheers - Bob
  • 0
    I no longer think this is a subnetting/IP issue. I changed the IP pool for the L2TP clients 10.246.3.x and it does route traffic to my internal 192.168.1.x network correctly when I get a connection.

    Now, I'd connect, but when I disconnect and try to reconnect about 15 seconds later, I get the timed out error.

    Looked at the Live Logs, the UTM9 server takes at least 60-90 seconds to terminate a client connection once I hit disconnect on my device. The problem was that I'd try to reconnect almost immdietely (for testing purposes) and it would all fall apart. Only way to fix it would be to burp the VPN server (disable the L2TP VPN under Remote Access and re-enable)

    If I waited until I saw the "Connection Terminated" in my live log and THEN tried to reconnect, everything would work smoothly and properly.

    Is this normal? Or is this a bug? I don't recall the server being this "sensitive" back in ASG v8, even after quick disconnects and reconnects.

    edit: False alarm. Looks like it is an android issue. Tried connecting/disconnecting using the built in MS Client and everything worked perfect. It looks like Android waits a good 30-60 seconds before sending the actual "Disconnect" command AFTER you press "Disconnect." Thanks for your help BAlfson