Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 10 replies
  • Subscribers 1 subscriber
  • Views 3160 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.
Parents
  • 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.
Reply
  • 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.
Children
No Data