replacement of security/ipsec-tools
Karl Denninger
karl at denninger.net
Sat Jan 11 16:03:06 UTC 2020
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 at denninger.net <mailto:karl at denninger.net>
/The Market Ticker/
/[S/MIME encrypted email preferred]/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4897 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.freebsd.org/pipermail/freebsd-net/attachments/20200111/85fde1e3/attachment.bin>
More information about the freebsd-net
mailing list