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

IPSec VPN broken in this version?

SalishSwede
I believe I've followed the Roadwarrior manual to the letter to set up L2TP-IPsec VPN, but the behavior of ASL 5.202 suggests that things have changed and following the manual doesn't seem to suffice.

Specifically, the roadwarrior manual statest that the only Packet Filter rules one needs is for the L2TP-pool.

After setting up ASL and attempting the connection, the packet filter shows that UPD 1701 is being blocked.

Adding a rule explicitly allowing this traffic has no effect.  It's still blocked. 

 My rule is 
          Source_Addr:      Any   
                   Service:      1701 [a custom rule w/ port 1701 as 
                                      destination port and  any as source port).  
     Destination Addr:     Any.  

All of this traffic is still blocked and no VPN connections with L2TP can be made.

Has anyone else seen this behavior?


This thread was automatically locked due to age.
Parents
  • 0
    Do you use your ASL in bridged mode? Do you use the Astaro Secure Client (ASC)?

    L2TP is tunnled in IPsec. So port 1701 is inside IPsec. So it should be enought to have packetfilters for port 500 4500 and ESP in place. This is done by ASL automatically.

    If your client tries to connet on Port 1701 directly, the client is configured in the wrong way. ASL support only IPsec OVER L2tp. It does not support raw l2tp.

    Xeno
Reply
  • 0
    Do you use your ASL in bridged mode? Do you use the Astaro Secure Client (ASC)?

    L2TP is tunnled in IPsec. So port 1701 is inside IPsec. So it should be enought to have packetfilters for port 500 4500 and ESP in place. This is done by ASL automatically.

    If your client tries to connet on Port 1701 directly, the client is configured in the wrong way. ASL support only IPsec OVER L2tp. It does not support raw l2tp.

    Xeno
Children
  • 0 in reply to Xeno
    I'm using the standard Win client in L2TP mode: pretty basic.
    Perhaps I 'misspoke' in my earlier post.

    I've set up things just as the Roadwarrior Manual suggests.

    I'm hoping I'm being clear enough on how this is set up.

    Basic test setup:
    WinXP client
    Simple L2TP mode of Win VPN

    Please let me know if I'm still not being clear.

    Cheers
  • 0 in reply to SalishSwede
    Please note...

    my responses here are being edited and/or deleted.

    I will be evaluating whether such business practices are consistent with my ethical standards
  • 0 in reply to SalishSwede
    [seeing if this post will be deleted too]

    In an earlier post...

    "L2TP is tunnled in IPsec. So port 1701 is inside IPsec. So it should be enought to have packetfilters for port 500 4500 and ESP in place. This is done by ASL automatically."

    Since I'm using the basic Microsoft client [winXP sp2] the client is attempting a tunnel as you describe.
    Since ASL is reporting drops on port 1701, clearly this suggests that ASL's VPN is broken.

    This 'automatic' functionality means there's no way for an administrator to correct the problem

    Cheers
  • 0 in reply to SalishSwede
    OK, found the problem. Indeed it's the packetfilter. There is one needed for the L2TP packets inside the tunnel. A packetfilter which matches on ipsec0. There is a packetfilter for incomming L2TP packets. But there is one missing for outgoing packets. Seems the statfull inspection does not work for L2TP.

    Xeno
  • 0 in reply to Xeno
    Can you please discribe in detail what needs to be done to get L2TP with windows clients working again?  I guess its the same issue I have.
  • 0 in reply to Astrofax
    Workaround: Add a packetfilter manually.

    Source: External Interface (Address)
    Destination: Any
    Service: Port 1701 tcp/udp
    Action: Allow

    Any feedback is welcome.

    Xeno
  • 0 in reply to Xeno
    This packet filter does nothing.
    Whatever is blocking this port, it's not done at the packet filter level.  Some other process is blocking this... or perhaps the packet filter is broken and not responding to this change.
  • 0 in reply to SalishSwede
    Should work with newest beta 5.816.

    Xeno
Cookie Information Banner