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

Several L2tP Roadwarriors with one IP - Problem

Joecomo
System ASL 6.003 - With a public IP

Windows XP-SP2 CLients with X.509 Certificate - behind NAT-Router

We have several road warriors behind a common NAT-router (so they share one IP).
Once one road-warrior has established a connection to the ASTARO the others cannot connect (Windows reports error 792 - time to negotiate connection to long).

So Question: Should several roadwarriors be able to connect at once?
If yes - is this a known bug of 6.003?

Thanks for your help

Yours 

Joachim


This thread was automatically locked due to age.
Parents
  • 0
    Hi,

    don't know if theres a workaround. 
    from http://www.jacco2.dds.nl/networking/freeswan-l2tp.html#NAT
    " If you have multiple clients behind the same NAT device, only the first client will be able to connect. This is probably a limitation of the Linux kernel (NAT-OA ignored? Also on 26sec?). There is a workaround by the Finnish company Stinghorn which is based on modifications to the Linux kernel and racoon (KAME). Some more details can be found here. There are some fixes in Openswan 2.4.0dr8 that may or may not fix this issue. Another limitation may be that clients cannot share the same NAT-ed (internal) address (also with 26sec? Not tested yet). This is of course difficult to avoid completely, especially when there is little coordination between remote clients. "

    Chris
Reply
  • 0
    Hi,

    don't know if theres a workaround. 
    from http://www.jacco2.dds.nl/networking/freeswan-l2tp.html#NAT
    " If you have multiple clients behind the same NAT device, only the first client will be able to connect. This is probably a limitation of the Linux kernel (NAT-OA ignored? Also on 26sec?). There is a workaround by the Finnish company Stinghorn which is based on modifications to the Linux kernel and racoon (KAME). Some more details can be found here. There are some fixes in Openswan 2.4.0dr8 that may or may not fix this issue. Another limitation may be that clients cannot share the same NAT-ed (internal) address (also with 26sec? Not tested yet). This is of course difficult to avoid completely, especially when there is little coordination between remote clients. "

    Chris
Children
Cookie Information Banner