Hey dude. Thanks for replying. The reason we're choosing OpenVPN is because we can configure the server and clients to communicate to the server at 443/TCP which pretty much guarantees that road warriors and NAT'd office employees could all reach through any firewall. (Ok, that's a broad statement, but any firewall that blocks connecting to 443/TCP outbound is really not gonna be in scope as far as I'm concerned;) )
But so, while we gain that feature, what did you find difficult about administering an OpenVPN instance? -- James McGoodwin From: Ryan Slack <r...@evine.ca<mailto:r...@evine.ca>> Date: Friday, November 21, 2014 at 10:52 AM To: James McGoodwin <jmcgood...@kobo.com<mailto:jmcgood...@kobo.com>> Subject: Re: Concurrent L2TP/IPSEC connections for Windows Clients behind a shared NAT On Nov 21, 2014 8:10 AM, "James McGoodwin" <jmcgood...@kobo.com<mailto:jmcgood...@kobo.com>> wrote: > > Thanks for your feedback and confirmation Yasuoka. > > I'm glad you're able to reproduce the issue, it's been a difficult one to > try > to explain to google;) Took me longer than I'd care to admit to finally > pin > down the specifics so I could even pose this question to the group. > > I think for the time being we may push our windows clients over to an > Openvpn solution. > I went the same path in supporting windows road warriors, isakmpd to openvpn, but have since found that supporting the windows native ike2 VPN via iked to be less work/issues. ymmv > Again, thanks very much for your feedback and hopefully this will help > others identify the problem in their implementations faster in the > Future. > > ((Isakmpd/npppd still works smashingly for a single windows client, so > from a work-from-home or road-warrior point of view it's perfect. In a > shared office environment however, Windows clients contend for that > single available port. Ridiculous. )) > > James McGoodwin > > > > > On 11/18/14, 7:45 PM, "YASUOKA Masahiko" <yasu...@yasuoka.net<mailto:yasu...@yasuoka.net>> wrote: > > >On Sat, 15 Nov 2014 00:48:44 +0000 > >James McGoodwin <jmcgood...@kobo.com<mailto:jmcgood...@kobo.com>> wrote: > >> However Windows clients are limited to only one connection at a > >> time. Subsequent connections cause the current session to die and > >> be replaced by the new one. > >(snip) > >> In short, many security associations (for each windows client) but only > >>one > >> actual flow. > >> > >> Isakmpd doesn?t have a way to distinguish between the connections as it > >> renegotiates their keys. > > > >I could repeat the problem. When rekeying, only one of the > >connections can keep the IPsec session and others are dropped. It > >seems isakmpd NAT-T has an issue. > > > >I also would like to fix it. But I need to learn the isakmpd code. > >It may take time. > > > >--yasuoka
