Date: Sat, 11 Jan 2020 10:02:28 -0600 From: Karl Denninger <karl@denninger.net> To: freebsd-net@freebsd.org Subject: Re: replacement of security/ipsec-tools Message-ID: <b7b56621-6632-b811-4bf1-479e43e25678@denninger.net> In-Reply-To: <20200111112307.GA62210@admin.sibptus.ru> References: <50378AC0-0A0A-4E33-961F-3D180987A8C1@ellael.org> <20200110035009.GB67842@admin.sibptus.ru> <20200110065131.GA79879@admin.sibptus.ru> <20200111112307.GA62210@admin.sibptus.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --] On 1/11/2020 05:23, Victor Sudakov wrote: > Victor Sudakov wrote: >>> If you ever find good documentation/howto for strongswan on FreeBSD, >>> please share with me. >> Really, please! I know there are people present here using strongswan. >> >> I would like to try and replace racoon with it. > Now thanks to Sergey Matveev and some good docs on > https://wiki.strongswan.org/ , I have some working examples of > strongswan usage. I must admit it is rather elegant. > > But for this bug-or-feature: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242744 > I could even easily and elegantly secure all communications between my > FreeBSD hosts (I can't of course due to the above bug, but this is not > strongswan's fault). > > However, not the same with Windows. By much experimenting, I once > created a working configuration for IPsec transport mode between FreeBSD > and Windows with racoon: > > remote "win2012" { > exchange_mode main; > my_identifier address; > peers_identifier address; > remote_address 192.168.246.12; > proposal_check obey; > proposal { > encryption_algorithm 3des; > hash_algorithm sha1; > authentication_method pre_shared_key; > dh_group 2; > } > } > sainfo anonymous { > pfs_group 2; > lifetime time 1 hour; > encryption_algorithm aes,3des; > authentication_algorithm hmac_sha512,hmac_sha384,hmac_sha256,hmac_sha1; > compression_algorithm deflate ; > } > > But now when I try to replace racoon with strongswan, the following > configuration does not work: > > conn Win2012 > keyexchange = ikev1 > ike=3des-sha1-modp1024! > esp=3des-sha1-modp1024! > left=192.168.246.1 > right=192.168.246.12 > type=transport > compress=yes > authby=psk > auto=route > > In Wireshark, I see ISAKMP exchange between 192.168.246.1 and > 192.168.246.12. Also "service strongswan status" reports that there is a SA: > > Security Associations (1 up, 0 connecting): > Win2012[5]: ESTABLISHED 114 seconds ago, 192.168.246.1[192.168.246.1]...192.168.246.12[192.168.246.12] > > but in fact there are none: > > # setkey -D > No SAD entries. Strongswan works fine with Win10 HOWEVER note that Windows 10 until somewhat recently (last summer, I believe) and ALL PREVIOUS VERSIONS (e.g. Win7, 8, etc.) had a SEVERE problem with IkeV2 connections, which you want, in that their fragmentation support was just flat-out broken. What you'd see is the part of the initial ISKAMP exchange but you never got the full message in both directions. Thus if you had a path that refused UDP frags the connection would never come up. Once it was connected it was fine but these days due to the abusive potential for frag UDP packets they are often black-holed somewhere between source and destination. This is now fixed for Win10, however, I believe there's no fix for Win8 and before. Allegedly Ikev1 will work with frags correctly in any event but I never got that working well; until Microsoft fixed the IkeV2 frag problem I used to run OpenVPN for Windows clients. Fortunately that's no longer necessary and the internal IkeV2 client is a LOT faster in terms of performance over the network than OpenVPN. Here's the stanzas I use: ca StrongSwan cacert=CudaSystems.Int.crt ocspuri=http://ocsp.cudasystems.net:8888 auto=add conn %default keyingtries=5 keyexchange=ikev2 fragmentation=yes conn WinUserCert left=%any leftsubnet=0.0.0.0/0 leftcert=ipgw-rsa.denninger.net.crt leftauth=pubkey right=%any rightsourceip=192.168.2.0/24 rightauth=eap-tls eap_identity=%identity auto=add dpdaction=clear dpddelay=300s ike=aes256-sha2_256-prfsha256-modp1024 This assigns an address out of 192.168.2.0; you need to have your firewall (which ideally is the same machine that's the gateway) handle that properly for NAT out to the "wider world" assuming you want that all to work. Also, make very, very sure you do not publish an IPv6 listener via DNS (e.g. "ipgw.denninger.net" does NOT resolve both an IPv6 and IPv4 address) because by default StrongSwan WILL respond to an IPv6 connection attempt. You can configure it to run dual-stack but it's a bit tricky because your IPv6 prefix can (does) change dynamically and thus you need to have something to detect that and re-write the source IP and restart the stack if it happens. In addition Windows doesn't add an IPv6 route when it brings up the VPN so you need to run a router advertisement daemon and do some work on the StrongSwan side, or have some other workaround (like adding a default route manually on the client, which is a five-alarm pain in the butt and violates the "it just works" aspect of IPv6.) Note that this configuration uses a machine certificate (not a user and password) so you need the "ca" stanza to tell the software who can issue certificates it will accept. You can also use the "secrets" file and eap-mschapv2 if you want for username/password authentication (in "rightauth") but I prefer the machine certificate option. Note that if you do the user/password thing you also need "eap_identity=%any" I have my own CA and OCSP responder that issues and answers for the machine certificates in question. There is another issue you may want to take care of dealing with Window's proposals. The Wiki on StrongSwan's site has details on this and is the reason I have a specific proposal set; it's not the best but is decent. If you don't set anything specific at all Windows' proposal will be laughably weak (try it and then do an "ipsec status" and you'll see what I mean) and StrongSwan will happily allow that. If you set something even better (e.g. modp2048) and haven't made the registry changes on the client side then a client that hasn't done it with registry changes (whether by Powershell or direct edit) will not be able to connect. Also be aware that by default Windows (since 1803 I think) defaults to split routing which for most users of a VPN is NOT what they want. That's easily set, however, on the Windows client in the connection profile without having to engage in registry hackery (check the "default gateway on remote" box.) https://wiki.strongswan.org/projects/strongswan/wiki/WindowsClients -- Karl Denninger karl@denninger.net <mailto:karl@denninger.net> /The Market Ticker/ /[S/MIME encrypted email preferred]/ [-- Attachment #2 --] 0 *H 010 `He 0 *H 00 H^Ōc!5 H0 *H 01 0 UUS10U Florida10U Niceville10U Cuda Systems LLC10U Cuda Systems CA1!0 U Cuda Systems LLC 2017 CA0 170817164217Z 270815164217Z0{1 0 UUS10U Florida10U Cuda Systems LLC10U Cuda Systems CA1%0#U Cuda Systems LLC 2017 Int CA0"0 *H 0 h-5B>[;olӴ0~͎O9}9Ye*$ g !ukvʶLzN`jL>MD'7U 45CB+kY`bd~b*c3Ny-78ju]9H euέsӬDؽmgwER?&UURj'}9nWD i`XcbGz \gG=u%\Oi13ߝ4 K44pYQr]Ie/r0+eEޝݖ0C15Mݚ@JSZ(zȏ NTa(25DD5.l<g[[Z arQQ%Buȴ~~`IohRbʳڟu2MS8EdFUClCMaѳ !}ș+2k/bųE,n当ꖛ\(8 WV8 d]b yXw ܊:I39 00 U ]^§Q\ӎ0U #0T039N0b01 0 UUS10U Florida10U Niceville10U Cuda Systems LLC10U Cuda Systems CA1!0 U Cuda Systems LLC 2017 CA @Ui0U 0 0U 0 *H :P U!>vJ n io -#ן]Wyu jǑR̀Q nƇ!G ѦF g\ yLx gw=OPycehf[ }ܷ['4ڝ\[p 6\o.B&JF" ZC{;*o*mcCcLY߾` t*S!(` ]DHP5A~/NPp6=mhk밣'doA$86hm5ӚS@ j ެEgl )0JG`%k35PaC?σ ׳HEt}!P㏏%*BxbQwaKG$6 h¦Mve; [o-Iی& I,Tc ߎ#t wPA@l0P+KXBպT zGv;NcI3&J ĬUPNa?/%W6G۟N000 k#Xd\ =0 *H 0{1 0 UUS10U Florida10U Cuda Systems LLC10U Cuda Systems CA1%0#U Cuda Systems LLC 2017 Int CA0 170817212120Z 220816212120Z0W1 0 UUS10U Florida10U Cuda Systems LLC10U karl@denninger.net0"0 *H 0 T[I-ΆϏ dn;Å@שy.us~_ZG%<MYd\gvfnsa1'6Egyjs"C [{~ _K Pn+<*pv#Q+H/7[-vqDV^U>f%GX)H.|l`M(Cr >е͇6#odc"YljҦln8@5SA0&ۖ"OGj?UDWZ5 dDB 7k-)9Izs-JAv J 6L$Ն1SmY.Lqw*SH;EF'DĦH]MOgQQ|Mٙג2Z9y@ y]}6ٽeY9Y2xˆ$T=e CǺǵbn֛{j |@LLt1[Dk5:$= ` M 00<+00.0,+0 http://ocsp.cudasystems.net:88880 U 0 0 `HB0U 0 U %0++03 `HB &$OpenSSL Generated Client Certificate0 U %՞V =;bzQ0U #0]^§Q\ӎϡ01 0 UUS10U Florida10U Niceville10U Cuda Systems LLC10U Cuda Systems CA1!0 U Cuda Systems LLC 2017 CA H^Ōc!5 H0 U 0karl@denninger.net0 *H ۠A0-j%--$% g2#ޡ1^>{K+uGE v1ş7Af&b&O; .;A5* U)ND2bF|\= ]<sˋL!wrw٧> YMÄ3\mWR hSv!_zvl? 3_ xU%\^#O*Gk̍YI_&Fꊛ@&1n } ͬ:{hTP3B.;bU8:Z=^Gw8 !k-@xE@i,+'Iᐚ:f hztX7/(hY` O.1}a`%RW^akǂpCAufgDix UTЩ/7}%=jnVZvcF<M= 2^GKH5魉 _O4ެByʈySkw=5@h.0z> W1000{1 0 UUS10U Florida10U Cuda Systems LLC10U Cuda Systems CA1%0#U Cuda Systems LLC 2017 Int CA k#Xd\ =0 `He E0 *H 1 *H 0 *H 1 200111160228Z0O *H 1B@ 1 O7- [6jZÇ7ؖ 5UejiQn;*s&S>u׃dE0l *H 1_0]0 `He*0 `He0 *H 0*H 0 *H @0+0 *H (0 +7100{1 0 UUS10U Florida10U Cuda Systems LLC10U Cuda Systems CA1%0#U Cuda Systems LLC 2017 Int CA k#Xd\ =0 *H 10{1 0 UUS10U Florida10U Cuda Systems LLC10U Cuda Systems CA1%0#U Cuda Systems LLC 2017 Int CA k#Xd\ =0 *H yh %AJ2 up6w)֦nkܚMBJ1e]DTU<JQi 6(L8ef[{LnPƎpTVX'ǥh-8TN_}_;#Juy^Utp rgؗZJTC[(m9^wXyM'bn`,l(n=YϲbqI5`\7Xq>@r#BD/7Q@踦 gJ,*Ѐ( 5 gqTc?<v HZ"J1+!"^awb)DF#* b8k62 sEod /JjR+QfS B'3 ,+ +FHq37yeJĠ K *lK\rм y@ 'ޠ Ĝ'Tzxᄹَ$>= ZJ7dÝ
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?b7b56621-6632-b811-4bf1-479e43e25678>