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

[7.502] L2TP over IPsec broken?

BAlfson
I installed 7.502 on our production box last Friday.  Over the weekend, I noticed that the L2TP/IPsec connection seemed to establish from my laptop, but I couldn't access anything on the internal network by name or IP - not even the internal IP of the Astaro!  I assumed that things just needed to be rebooted.  Curiously, Outlook Web Access worked perfectly when not connected to the VPN.

I just tried to use my iPhone.  I seemed to connect with both the Cisco client and L2TP.  Under L2TP, I got nothing, just as I had over the weekend with the laptop.  When I connected with the iPhone Cisco client, I could see my Exchange server and access it via its internal IP.  Double-checking the L2TP client was again unfruitful.

Anyone else?

Cheers - Bob


This thread was automatically locked due to age.
  • 0
    I don't use L2TP, but I can confirm plain IPSEC and SSL VPN connections work fine.
  • 0
    I just reconfirmed that L2TP does not function.  I then installed the new SSL client via the User Portal, and, as Bruce says, it works flawlessly.

    Cheers - Bob
  • 0
    I take back the "flawlessly" comment about the SSL VPN.  I can log into WebAdmin via the 'Internal (Address)', but the connection is not robust enough for Outlook to start.  In fact, the Vista 'Network and Sharing Center' continues to show "Identifying" and the SSL VPN Status indicates that it keeps losing the connection.  Bruce, are you sure you're having no problems?

    Cheers - Bob

    Client SSL log: 
    Tue Dec 08 08:06:40 2009 read TCPv4_CLIENT: Connection timed out (WSAETIMEDOUT) (code=10060)

    Tue Dec 08 08:06:40 2009 Connection reset, restarting [-1]

    Tue Dec 08 08:06:40 2009 TCP/UDP: Closing socket

    Tue Dec 08 08:06:40 2009 SIGUSR1[soft,connection-reset] received, process restarting

    Tue Dec 08 08:06:40 2009 Restart pause, 5 second(s)

    Tue Dec 08 08:06:45 2009 WARNING: Make sure you understand the semantics of --tls-remote before using it (see the man page).

    Tue Dec 08 08:06:45 2009 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables

    Tue Dec 08 08:06:45 2009 Re-using SSL/TLS context

    Tue Dec 08 08:06:45 2009 LZO compression initialized

    Tue Dec 08 08:06:45 2009 Control Channel MTU parms [ L:1556 D:140 EF:40 EB:0 ET:0 EL:0 ]

    Tue Dec 08 08:06:53 2009 Data Channel MTU parms [ L:1556 D:1450 EF:56 EB:135 ET:0 EL:0 AF:3/1 ]

    Tue Dec 08 08:06:53 2009 Local Options hash (VER=V4): '619088b2'

    Tue Dec 08 08:06:53 2009 Expected Remote Options hash (VER=V4): 'a4f12474'

    Tue Dec 08 08:06:53 2009 Attempting to establish TCP connection with 68.***.yyy.zzz:443

    Tue Dec 08 08:07:14 2009 TCP: connect to 68.***.yyy.zzz:443 failed, will try again in 5 seconds: Connection timed out (WSAETIMEDOUT)

    Tue Dec 08 08:07:40 2009 TCP: connect to 68.***.yyy.zzz:443 failed, will try again in 5 seconds: Connection timed out (WSAETIMEDOUT)

    Tue Dec 08 08:07:45 2009 TCP connection established with 68.***.yyy.zzz:443

    Tue Dec 08 08:07:45 2009 Socket Buffers: R=[8192->8192] S=[8192->8192]

    Tue Dec 08 08:07:45 2009 TCPv4_CLIENT link local: [undef]

    Tue Dec 08 08:07:45 2009 TCPv4_CLIENT link remote: 68.***.yyy.zzz:443

    Tue Dec 08 08:07:45 2009 TLS: Initial packet from 68.***.yyy.zzz:443, sid=1214629f 71ef9c60

    Tue Dec 08 08:07:45 2009 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this

    Tue Dec 08 08:07:46 2009 VERIFY OK: depth=1, /C=us/L=Oklahoma_City/O=MediaSoft__Inc./emailAddress=BAlfson@MediaSoftUSA.com

    Tue Dec 08 08:07:46 2009 VERIFY X509NAME OK: /C=us/ST=Oklahoma/L=Oklahoma_City/O=MediaSoft__Inc./OU=Office/CN=Post/emailAddress=Astaro@MediaSoftUSA.com

    Tue Dec 08 08:07:46 2009 VERIFY OK: depth=0, /C=us/ST=Oklahoma/L=Oklahoma_City/O=MediaSoft__Inc./OU=Office/CN=Post/emailAddress=Astaro@MediaSoftUSA.com

    Tue Dec 08 08:07:47 2009 Data Channel Encrypt: Cipher 'AES-128-CBC' initialized with 128 bit key

    Tue Dec 08 08:07:47 2009 Data Channel Encrypt: Using 128 bit message hash 'MD5' for HMAC authentication

    Tue Dec 08 08:07:47 2009 Data Channel Decrypt: Cipher 'AES-128-CBC' initialized with 128 bit key

    Tue Dec 08 08:07:47 2009 Data Channel Decrypt: Using 128 bit message hash 'MD5' for HMAC authentication

    Tue Dec 08 08:07:47 2009 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 2048 bit RSA

    Tue Dec 08 08:07:47 2009 [Post] Peer Connection Initiated with 68.***.yyy.zzz:443

    Tue Dec 08 08:07:49 2009 SENT CONTROL [Post]: 'PUSH_REQUEST' (status=1)

    Tue Dec 08 08:07:49 2009 PUSH: Received control message: 'PUSH_REPLY,ifconfig 10.aaa.bbb.14 10.aaa.bbb.13,ping-restart 120,ping 10,topology net30,route 10.aaa.bbb.1,dhcp-option DOMAIN post.mediasoftusa.com,dhcp-option WINS 10.1.1.7,dhcp-option DNS 10.1.1.7,route 10.1.1.0 255.255.255.0'

    Tue Dec 08 08:07:49 2009 OPTIONS IMPORT: timers and/or timeouts modified

    Tue Dec 08 08:07:49 2009 OPTIONS IMPORT: --ifconfig/up options modified

    Tue Dec 08 08:07:49 2009 OPTIONS IMPORT: route options modified

    Tue Dec 08 08:07:49 2009 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified

    Tue Dec 08 08:07:49 2009 Preserving previous TUN/TAP instance: Local Area Connection 4

    Tue Dec 08 08:07:49 2009 NOTE: Pulled options changed on restart, will need to close and reopen TUN/TAP device.

    Tue Dec 08 08:07:49 2009 C:\WINDOWS\system32\route.exe DELETE 10.1.1.0 MASK 255.255.255.0 10.aaa.bbb.5

    Tue Dec 08 08:07:49 2009 Route deletion via IPAPI succeeded [adaptive]

    Tue Dec 08 08:07:49 2009 C:\WINDOWS\system32\route.exe DELETE 10.aaa.bbb.1 MASK 255.255.255.255 10.aaa.bbb.5

    Tue Dec 08 08:07:49 2009 Route deletion via IPAPI succeeded [adaptive]

    Tue Dec 08 08:07:49 2009 Closing TUN/TAP interface

    Tue Dec 08 08:07:50 2009 ROUTE default_gateway=192.168.15.1

    Tue Dec 08 08:07:50 2009 TAP-WIN32 device [Local Area Connection 4] opened: \.\Global\{B4EDC539-84DF-4CA3-A07F-799A468F8962}.tap

    Tue Dec 08 08:07:50 2009 TAP-Win32 Driver Version 9.6 

    Tue Dec 08 08:07:50 2009 TAP-Win32 MTU=1500

    Tue Dec 08 08:07:50 2009 Notified TAP-Win32 driver to set a DHCP IP/netmask of 10.aaa.bbb.14/255.255.255.252 on interface {B4EDC539-84DF-4CA3-A07F-799A468F8962} [DHCP-serv: 10.aaa.bbb.13, lease-time: 31536000]

    Tue Dec 08 08:07:50 2009 Successful ARP Flush on interface [40] {B4EDC539-84DF-4CA3-A07F-799A468F8962}

    Tue Dec 08 08:07:55 2009 TEST ROUTES: 0/0 succeeded len=2 ret=0 a=0 u/d=down

    Tue Dec 08 08:07:55 2009 Route: Waiting for TUN/TAP interface to come up...

    Tue Dec 08 08:08:00 2009 TEST ROUTES: 0/0 succeeded len=2 ret=0 a=0 u/d=down

    Tue Dec 08 08:08:00 2009 Route: Waiting for TUN/TAP interface to come up...

    Tue Dec 08 08:08:01 2009 TEST ROUTES: 0/0 succeeded len=2 ret=0 a=0 u/d=down

    Tue Dec 08 08:08:01 2009 Route: Waiting for TUN/TAP interface to come up...

    Tue Dec 08 08:08:03 2009 TEST ROUTES: 0/0 succeeded len=2 ret=0 a=0 u/d=down

    Tue Dec 08 08:08:03 2009 Route: Waiting for TUN/TAP interface to come up...

    Tue Dec 08 08:08:04 2009 TEST ROUTES: 2/2 succeeded len=2 ret=1 a=0 u/d=up

    Tue Dec 08 08:08:04 2009 C:\WINDOWS\system32\route.exe ADD 10.aaa.bbb.1 MASK 255.255.255.255 10.aaa.bbb.13

    Tue Dec 08 08:08:04 2009 ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=30 and dwForwardType=4

    Tue Dec 08 08:08:04 2009 Route addition via IPAPI succeeded [adaptive]

    Tue Dec 08 08:08:04 2009 C:\WINDOWS\system32\route.exe ADD 10.1.1.0 MASK 255.255.255.0 10.aaa.bbb.13

    Tue Dec 08 08:08:04 2009 ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=30 and dwForwardType=4

    Tue Dec 08 08:08:04 2009 Route addition via IPAPI succeeded [adaptive]

    Tue Dec 08 08:08:04 2009 Initialization Sequence Completed

    Tue Dec 08 08:08:19 2009 read TCPv4_CLIENT: Connection timed out (WSAETIMEDOUT) (code=10060)

    Tue Dec 08 08:08:19 2009 Connection reset, restarting [-1]

    Tue Dec 08 08:08:19 2009 TCP/UDP: Closing socket

    Tue Dec 08 08:08:19 2009 SIGUSR1[soft,connection-reset] received, process restarting

    Tue Dec 08 08:08:19 2009 Restart pause, 5 second(s)
  • 0
    OK - Mystery solved!  (and I have egg on my face)

    Two or three years ago, I was playing with the different ways to pass out IPs to L2TP connections.  I tried letting the Astaro get an IP from DHCP running on our domain controller.  That shouldn't have worked, but it did, and I never changed it.

    As Jason Simon of US Support explained:
     In my tcpdump on the ASG, I saw:

    19:08:56.584307 arp who-has 10.***.yyy.71 tell 10.***.yyy.7
    19:08:57.192083 IP (tos 0x0, ttl 128, id 4882, offset 0, flags [none], proto ICMP
    (1), length 60) 10.***.yyy.71 > 10.***.yyy.7: ICMP echo request, id 1, seq 3962, length 40
    19:08:57.192314 IP (tos 0x0, ttl 127, id 4882, offset 0, flags [none], proto ICMP
    (1), length 60) 10.***.yyy.71 > 10.***.yyy.7: ICMP echo request, id 1, seq 3962, length 40


    The first packet you see above is understandable, because 10.***.yyy.7 believes 10.***.yyy.71 sitting "on the wire" on the LAN.  So it is going to ARP requests for the MAC address of 10.***.yyy.71.  ARP broadcasts will not forward over l2tp connection.  Because the ARP reply was never sent for 10.***.yyy.71, the host 10.***.yyy.71 will NOT send ICMP response.  Hence, the L2TP connection needs to be a separate subnet than the LAN so that traffic from the LAN is routed through the ASG via the default gateway of the LAN. Once the ASG receive the packet, it will forward it to the l2tp client via the vpn tunel.

    I had read that it shouldn’t work, but hadn’t understood about the ARP requests.  Apparently, something that was broken for years was fixed in V7.502.  Either that, or a patch to something in Win Server 2003 was applied at the time of the upgrade to Astaro 7.502.  It’s a mystery I’m glad to leave unsolved.

    Cheers – Bob
    PS As others have experienced the identical problem with PPTP Remote Access, it's now clear that the issue is related to a change in 7.502.
  • 0
    Mystery or not, I think I have the same problem: VPN connection Yes, remote desktop No.
    Is there a problem or not?
  • 0 in reply to Peter Fontaine
    We're seeing the same thing after 7.502.  SSL VPNs work just fine, but L2TP and PPTP connections connect but can't access anything.
  • 0
    Like I said, the setup I created two or three years ago should not have worked, and now it doesn't.  The problem was that I was assigning IP addresses inside 'Internal (Network)'.

    On the L2TP 'Global' tab, pick 'Assign IP addresses by' "IP address pool" and select 'Pool network' "VPN Pool (L2TP)".  That should have been pre-defined as 10.242.3.0/24 and should not overlap with 'Internal (Network)'.

    In SSL, you have the option to select 'Automatic packet filter rules', so you aren't being blocked from access.  With L2TP and PPTP, the PF rules need to be added explicitly.  You could start with 'VPN Pool (L2TP) -> Any -> Any : Allow' to proof the setup, then create more-restrictive rules to suit your security requirements.

    Cheers - Bob
  • 0 in reply to BAlfson
    I've checked.  There aren't any overlaps in our pool definitions, and we haven't changed any firewall rules from before the update.  Not even explicitly allowing all traffic from the PPTP/L2TP VPN pools lets us through.

    I've got a ticket open and they've already escalated it up from the first line platinum support folks.
  • 0
    hi please keep us updated on this. I have a similar issue with PPTP even with the VPN-PPTP-Pool, cant seem to get from internal network to anything on 10.242.1, i've added explicit 10.242.1.* -> Any -> Any and Any -> Any -> 10.242.1.*
    Packets from 10.242.1.* seem to get to internal network. as far as the FW is concerned.