On 2016/11/29 06:49, Damian McGuckin wrote: > > Hi Stuart, > > On Mon, 28 Nov 2016, Stuart Henderson wrote: > > > ipsec.conf isn't required for this (or anything that you can do with > > ipsec.conf; though not all of it is documented in the isakmpd.conf > > manual, i.e. NAT-ID). > > With the kind help of 'mxb' with a Swedish email address, I learned that. > Mind you, it uses features of 'isakmpd.conf' that are well beyond my level > of knowledge.
The format is a bit weird because it's shown as control commands rather than showing the config sections directly, but the configs it generates are reasonably straightforward, for example this C set [Phase 1]:Default=peer-default force C set [peer-default]:Phase=1 force C set [peer-default]:Configuration=phase1-peer-default force translates to [Phase 1] Default: peer-default [peer-default] Phase=1 Configuration=phase1-peer-default The main unusual feature for someone coming from isakmpd.conf is in the sections like "phase1-transform-peer-default-RSA_SIG-SHA-AES128-MODP_3072". With isakmpd.conf the normal way is to use suites from the "AUTO-GENERATED PARTS OF THE CONFIGURATION" (as described in the manpage). ipsecctl/ipsec.conf used to use these, but it was changed to instead generate its own full config sections specifying AUTHENTICATION_METHOD, HASH_ALGORITHM etc individually, this was done so that it could set extra options like SA lifetime per peer. (it is slightly buggy and actually only allows one choice of lifetime per transform, but I digress. :) > > > I would love to use both concurrently if I can? > > > > > > Has anybody got any experience with both working well together? > > > > That will be fine. > > Yes. I have it working thanks to the list. But not quite as flexibly as I > would like. > > If I use a particular PSK across 'isakmpd.policy' and 'isakmpd.conf', and > then try to use a different PSK for all inbound L2TP/IPSec connections, it > fails. If they agree, it works. And I cannot remove the former (.policy) > which I assume enforces an 'isakmpd'-wide PSK and try and use different ones > in the different files, iaakmpd.conf and ipsec.conf i.e. what I use for > IPSec over UDP500 and L2TP/IPSec over 1701 respectively. > > For completeness of description, for the latter I use > > ike passive esp transport \ > proto udp from egress to any port 1701 \ > main auth "hmac-sha1" enc "3des" group modp1024 \ > quick auth "hmac-sha1" enc "3des" group modp1024 \ > psk "MY-PRE-SHARED-SECRET" "to any" in ipsec.conf creates a configuration for what isakmpd.conf(5) describes as "the default ISAKMP peer". There can only be one such section, so if you're using "default" in isakmpd.conf you have such a conflict. The simplest fix, but not always possible, is to tie configs down by IP address of the other side; if you can rely on normal lan-to-lan tunnels to come only from specific addresses, just list them separately and leave "default" for roaming clients. By doing things on the isakmpd.conf/policy side you can write an isakmpd.policy section fairly easily that allows somebody to connect with either of a choice of PSKs (it's similar to one of the examples in the manpage). I think it may also be possible (though more complicated) to write a section that allows the port 1701 UDP tunnel with one psk, and other tunnels with a different psk. Here's an *untested* rough equivalent to the ipsec.conf entry you included, with the standard auto-generated suite/transforms rather than the ones that ipsecctl generates (using 192.0.2.1 as the local address in this case). [Phase 1] Default=peer-default [peer-default] Phase=1 Authentication=MY-PRE-SHARED-SECRET Configuration=default-phase1-config [default-phase1-config] EXCHANGE_TYPE=ID_PROT Transforms=3DES-SHA-GRP2 [phase2-default] Phase=2 ISAKMP-peer=peer-default Configuration=default-phase2-config Local-ID=from-self-udp Remote-ID=to-any-udp1701 [default-phase2-config] EXCHANGE_TYPE=QUICK_MODE Suites=QM-ESP-TRP-3DES-SHA-PFS-GRP2-SUITE # note -TRP; l2tp+ipsec uses transport not tunnel [from-self-udp] ID-type=IPV4_ADDR Address=192.0.2.1 Protocol=17 [to-any-udp1701] ID-type=IPV4_ADDR_SUBNET Network=0.0.0.0 Netmask=0.0.0.0 Protocol=17 Port=1701 [Phase 2] Passive-Connections=phase2-default > The above is what I found works for both Windows 10 (which has '3des' > hardcoded) and Apple. Why I need the 'group modp1024' for quick-mode I do > not know. This is an area where isakmpd.conf is significantly more useful than ipsec.conf; it allows you to list different encryption methods and allow any of them to be chosen, so you can still offer 3DES for legacy clients and allow newer ones to connect with AES, whereas ipsec.conf only allows a single one. > I must figure out how to obtain a more flexible Windows VPN > client. Microsoft says that only the earlier versions of its L2TP client are > so inflexible. > > https://support.microsoft.com/en-us/kb/325158 > > But even my laptop's version for an up-to-date Windows 10 Home does not give > me any choice for encryption from what I can see. Although I am far from an > expert on Windows 10, in anything and I have used OpenBSD for 20 > years. After you've created the connection in Windows, you can edit it in network connections, you can't set ciphers directly there but can set encryption type as something like No/Optional/Require/Maximum. Outside the gui you can set things up more directly via netsh, or via powershell on W10 (Set-VpnConnectionIPsecConfiguration). But for most cases setting to "Maximum" via gui is probably enough. I've used shrewsoft and thegreenbow on Windows, they worked well for me on W7 but had various problems last time I tried them with W10. This was a couple of months ago though and maybe better now. I'm not certain but I don't think either of these do l2tp. > > Though if you have an example ipsec.conf fragment, feed it into > > "ipsecctl -nv" and it shows the isakmpd fifo commands that it would send > > to add the config sections, > > I noticed. I learned more about the complexity of ISAKMPD commands in that > split second of viewing output than I ever really needed to know. Wow. I awe > of those that create such networking tools. > > > which you could clean up and add to isakmpd.conf yourself if you wanted > > to keep things in one place. > > That sounds frought with risk. Not a big fan of jumping into the unknown. > > And the future is 'ipsec.conf' so I probably need to learn that. Mind you, > one I cannot see is how to nominate a list of CRYPTO TRANSFORMS to the 'enc' > keyword inside 'ipsec'. For example how does one achieve the equivalent in > 'isakmpd.conf' to the alternatives > > Transforms= AES-SHA-GRP2,3DES-SHA > > or even > > Suites= QM-ESP-AES-SHA-PFS-GRP2-SUITE, QM-ESP-3DES-SHA-PFS-SUITE See above. Also it is important to note that ipsec.conf doesn't handle the isakmpd.policy side of things. This is quite important with the common "to any" setup on a VPN server. Unless you have restrictions in isakmpd.policy, a connecting client can set "its" side of the tunnel to be whatever address or network it likes (even 0.0.0.0/0, a.k.a. "the whole internet"). I discovered this the hard way by accidentally having "from any" instead of "to any" in ipsec.conf on a client machine then connecting to a vpn server. (Many people do ignore this; I hope they trust their authorised clients, and have strong PSKs or, better, use certificates). > While I am here, I still see on the passive IPSec Port 500 traffic > > got AES_CBC, expected 3DES_CBC > > on the IPSec/port500udp even when the originating side (A Billion Router > running some version of embedded Linux) is configured to talk AES and only > AES. Very weird. But I notice that in the past, even old versions of ISAKMPD > (4.6 and 4.7) with both ends the same produced that message it seems. I am > clueless as to the cause of that. That is "incoming packet was AES, but I expected it to be 3DES". Is this tunnel configured in default from the isakmpd.conf setup? If so, it sounds like that section is being overridden by the ipsec.conf one. You also see this if config is cleared without reloading a new one and you get an incoming request for AES request, because the default "default peer" setting is for 3DES.
