<div>Some very able responses, thank you Paul.<br></div><div><br></div><div>Only one comment about port knocking and changing ports:  my main concern is zero-days.  We can't know whether these do or will exist, and to me it's best to layer defenses with these methods.  I can simulate port changing with Shorewall, but I wish that port-knocking were an option.  True, being open-source this feature would be known by some, but if the nature and location of a VPN is unknown it makes cracking it infinitely harder.<br></div><div><br></div><div>But this tears it;  I'm switching to Libreswan.<br></div><div> <br></div><blockquote class="protonmail_quote" type="cite"><blockquote><pre><code>  Personally, I wouldn't know.  But I do know that
</code><br></pre><div><div>Strongswan has the option of lattice encryption, which is a strong indicator to me. (... although,<br></div><div> their Android app doesn't<br></div><div> support it)  And they have a special Android app.<br></div></div><div><div>The IETF, and specifically the CFRG, has not made any decisions on which<br></div><div> post-quantum protocols to pick. While experimentation is good, this is<br></div><div> not standards work and so I find the argument that support of lattice<br></div><div> means anything beyond supporting an experimental lattice protocol rather<br></div><div> weak.<br></div></div><div><div>We disagree here.  Those developing early are likely to be included in the final standard.  It's an indicator of<br></div><div> resources and determination.<br></div></div></blockquote><div><div> <br></div><div> CFRG develops early. Pretending we know better what to do then CFRG<br></div><div> would do is silly. I agree it is good to have experimental code for<br></div><div> the things that will come out of CFRG, but that does require a draft<br></div><div> to implement. While we keep our eyes open, we won't rush things. For<br></div><div> example, we are monitoring this draft:<br></div><div>  <br></div><div> <a href="https://tools.ietf.org/html/draft-tjhai-ipsecme-hybrid-qske-ikev2">https://tools.ietf.org/html/draft-tjhai-ipsecme-hybrid-qske-ikev2</a><br></div><div>  <br></div></div><blockquote><div>I see.  For me IKEv2 is the only viable option, and there seems to be no alternative to the Ss app.<br></div></blockquote><div><div> <br></div><div> True for Android. Everything else has native IKEv2 support now.<br></div><div>  <br></div></div><blockquote><pre><code>  Is there a port knock function?
</code><br></pre><div><div>That offers no security whatsoever. It's not an RFC standard, so not<br></div><div> part of IKE or IPsec, so it has no bearing whatsoever to security of<br></div><div> IKE/IPsec servers. It also simply does not scale if you have 100's or<br></div><div> 1000's of users. Either you can figure out the algorithm or just copy<br></div><div> it. Or just get it from a single compromised client.<br></div></div><div><div>The question is, what is the main threat?  If it's a targeted one Ok, your point is taken.  But there are<br></div><div> thousands of bots trying every second to get into well-known ports with the relevant protocol using known and<br></div><div> zero-day vulns.  In my opinion port-knock is a defense from these, as is relocating to an unprivileged port where<br></div><div> these wholesale attempts are vastly less likely.<br></div></div></blockquote><div><div> <br></div><div> I'm not worried about those, because those bots have no credentials,<br></div><div> so after an IKE_INIT exchange, they cannot pass AUTH. I'm pretty<br></div><div> confident our (de)marshalling code does not allow for RCE, at worst<br></div><div> it will crash/restart our daemon causing a Denial Of Service.<br></div><div>  <br></div><div> Once a client is authenticated, they would have a much better chance<br></div><div> at doing something. This is also true for the Opportunistic IPsec<br></div><div> use case, where the client does not authenticate to the server. I'm<br></div><div> still confident about not having authentication bypass or RCE. We<br></div><div> have a good track record.<br></div><div>  <br></div><div> If you have thousands of bot knocking your wellknown port, and<br></div><div> "wholesale attempts are vastly less likely", you still have them<br></div><div> knocking at your non-500 port pretty regularly.<br></div><div>  <br></div><div> I have run opportunistic on a busy open DNS server, resulting in<br></div><div> thousands of weird things responding to my IKE requests. While that<br></div><div> did find one error (remote peer sending a 0 DH KE payload causing<br></div><div> an assertion to crash+reboot our daemon), no crashes that could cause<br></div><div> RCE were found after tens of thousands of IPs with rogue stuff<br></div><div> contacting us (those using my open DNS server are usually pretty<br></div><div> malicious people)<br></div><div>  <br></div></div><blockquote><pre><code>  Can I change 500 to something else?
</code><br></pre><div><div>Our code does not allow for an easy differenty UDP port. Patches are<br></div><div> welcome :)<br></div></div></blockquote><div><div> <br></div><div> I mean, I do consider this a bug and do want to fix it. It is just not<br></div><div> a very high priority for us.<br></div><div>  <br></div></div><blockquote><div><div>That said, we have implemented IKE over any TCP port, and are awaiting<br></div><div> the linux kernel code completion of ESP over TCP, so we are fully<br></div><div> compliant to RFC 8229. That will allow you to bypass networks dropping<br></div><div> UDP 500/4500 or all UDP. Once TCP support is in, we will look at TLS<br></div><div> support as well. So that will allow you to use any port.<br></div></div><div>Is your TCP functionality usable now?  Is there a reference I can study?<br></div></blockquote><div><div> <br></div><div> The IKEoverTCP part of the RFC has successfully interoperated with<br></div><div> Apple's code. Both parties are now working on their ESP code and we<br></div><div> expect to do ESPoverTCP interop this month.<br></div><div>  <br></div></div><blockquote><div>No Curve25519, hm.<br></div></blockquote><div><div> <br></div><div> We had to wait a bit longer for Curve25519 to be available to use via<br></div><div> the NSS crypto library. Now it is there, we will add support for it.<br></div><div>  <br></div></div><blockquote><div><div>I HEARD THAT.  Strongswan is a priesthood, where mere users are unworthy of response.  This has wasted WEEKS of my<br></div><div> time in trying to suss out the deep secrets of VPN, when 15 minutes of answers would have gotten me there.  Ls<br></div><div> devs have been pretty responsive, and I'd like to thank you Paul and bleve on IRC.<br></div></div></blockquote><div><div> <br></div><div> I file strongswan bugs when I find interop issues, and even I get<br></div><div> smacked and slammed in their bugtracker (and never are personally<br></div><div> contacted). I've read some of their bug reports and how they treat<br></div><div> their customers or potential customers would get you fired from any<br></div><div> real company.<br></div><div>  <br></div></div><blockquote><div><div>What drove me from Libreswan originally was that it runs the pluto daemon, which looks for all the world to me<br></div><div> like IKEv1.  And even if it also supports IKEv2 that old name indicates low progress. (I have few ways of knowing)<br></div></div></blockquote><div><div> <br></div><div> You are <i>very</i> wrong. Look at the updated to late 2017 commit statistics<br></div><div> covering openswan and libreswan from 2006 - 2017<br></div><div>  <br></div><div> <a href="https://nohats.ca/wordpress/blog/2014/02/16/development-of-libreswan-vs-openswan/">https://nohats.ca/wordpress/blog/2014/02/16/development-of-libreswan-vs-openswan/</a><br></div><div>  <br></div><div> libreswan has seen vastly more development then openswan ever did before<br></div><div> we were forced to rename.<br></div><div>  <br></div></div><blockquote><div><div>But I am fairly angry with Strongswan at this point for costing me all this time.  I am disappointed with no<br></div><div> lattice, and the inability to change 500, but it's encouraging that Ls has SECCOMP, and I'd like to learn how to<br></div><div> switch to TCP, although I may well stay with UDP for its speed, and I can switch ports in the router which DNATs<br></div><div> the tunnel in to my VPN VM.<br></div></div></blockquote><div><div> <br></div><div> The TCP part will be auto-detect, although you can explicitely override<br></div><div> to skip trying UDP. As the RFC explains, it is always better to use UDP<br></div><div> (technically, ESPoverUDP) because otherwise you have multiple TCP layers<br></div><div> doing guaranteed delivery and retransmits. There were very good reasons<br></div><div> why ESP is stateless and not stateful like TCP.<br></div><div>  <br></div><div> We haven't released the TCP code because you will get only the IKE SA<br></div><div> established but all traffic would still be ESP or ESPinUDP. Once the<br></div><div> kernel supports ESPoverTCP, and tells us how to mark the socket as such,<br></div><div> we can add that to the code and release it.<br></div><div>  <br></div><div> Paul<br></div></div></blockquote><div><br></div>