From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Rymes To: development@lists.ipfire.org Subject: Re: IPSec Roadwarrior Configuration Date: Mon, 29 Jan 2018 12:26:09 -0500 Message-ID: <3b16015a-cbc5-83a0-2d07-cf78b858000f@rymes.com> In-Reply-To: <20180129155850.6dbe2413.peter.mueller@link38.eu> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6231053686254546476==" List-Id: --===============6231053686254546476== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 01/29/2018 9:58 AM, Peter M=C3=BCller wrote: > Hello Tom, >=20 > I completely agree with you. Setting up IPsec connections between two > IPFire machines works well out of the box, but everything else is really > complicated. We do this regularly, and it works well. Having spent a fair amount of=20 time lurking on the Strongswan Users list, I suspect that the IPFire N2N=20 tunnel configurations built by the WUI could be optimized, and a recent=20 post by me to that list made clear that the Roadwarrior configs are off. I have spent a fair amount of time climbing up the learning curve on=20 this issue since my first message, and it's a mess out there. The best=20 summary I ran across was that working with Strongswan/Libreswan/Freeswan=20 required an almost "tribal knowledge". Add in the fact that seemingly no=20 two clients respond in the same way or can be supported by the same=20 configuration, and it gets worse. I did get Windows and MacOS RW connections working, but it's still way=20 too difficult. I also updated and improved the Wiki page I linked to=20 earlier for Windows RW connections, and I intend to put one up for MacOS=20 connections, too. I have been meaning to summarize my thoughts here and offer a few=20 suggestions, but I haven't had a chance, so rather than wait, I will use=20 your response as an excuse to toss out a few thoughts I have had without=20 really organizing them as best as I can (I will try to open bug reports=20 later today, where appropriate): 1.) It would be nice if the "Advanced Settings" page was a drop-down=20 portion of the main settings page for a tunnel. Having to click through=20 to a second page to view those settings is an annoyance. It also results=20 in the tunnel being brought up with default settings when created, then=20 brought back down and restarted after you change the advanced settings. 2.) It would be great if there were a "Enable weak ciphers" setting in=20 the global settings area that were disabled by default. If you needed to=20 connect to some old, out-of-date Cisco ASA that only supports SHA1 and=20 MODP-1024, then you can check the box and those ciphers will appear in=20 the WUI. 3.) According to Noel at Strongswan, the settings "authby=3Drsasig",=20 "leftrsasigkey=3D%cert", and "rightrsasigkey=3D%cert" written out to RW=20 configs are superfluous, as leftauth/rightauth both default to "pubkey".=20 I suspect that this is due to leftover code from the old ikev1 pluto=20 setup, or even OpenSWAN. 4.) Regarding the settings "leftfirewall=3Dyes" and "lefthostaccess=3Dyes",=20 Noel mentioned "Don't do that, you better use static iptables rules with=20 the policy match module." I'm not certain where to go with that, but I=20 put it here for those that might. 5.) Client Configuration and certificate import is a major PITA. 6.) Not all clients support the same (or even strong) ciphers. 7.) I would imagine modifications to the RW config pages that would=20 allow a user to select "Support MacOS" and "Support Windows 7/8/10",=20 etc. Then, depending on which boxes were checked, different options=20 would be built in the config. Using the "also=3D" to include settings from=20 other tunnels, the WUI would write out multiple conn sections that=20 include the proper settings for each platform. See the examples under=20 "responder" and "ipsec.conf" listed here:=20 https://wiki.strongswan.org/projects/strongswan/wiki/UsableExamples Lastly, I am wondering if the project is reinventing the wheel here a=20 bit. While researching this stuff, I ran across this project, which=20 looks really promising, and which could, perhaps, be built as an add-on,=20 or we could at least look into adopting some of their better ideas? One=20 super-cool feature is the automated building of XML configuration=20 profiles for Apple devices. https://blog.trailofbits.com/2016/12/12/meet-algo-the-vpn-that-works/ >> https://wiki.ipfire.org/configuration/services/ipsec/example_configuration= -_roadwarrior_with_windows I did update this, and it is much improved, but we still need to amke=20 this simpler, I think. I was able to make MacOS clients work, but you=20 have to add this to the /etc/ipsec.user.conf file (replace=20 "xxx.xxx.xxx.xxx" with your DNS IP address - I used the IPFire Green=20 address): conn tunnelname leftsendcert=3Dalways leftallowany=3Dyes rightdns=3Dxxx.xxx.xxx.xxx rekey=3Dno reauth=3Dno You also need to set the root CA to always trust on the Mac, and to=20 avoid an annoying dialog, you need to "Allow access for all apps" for=20 the private key. > I currently struggle setting up an IPsec connection to an OpenBSD machine. > IKE seems to work fine now, but IPFire seems to request a sort of "virtual > IP request". This is unwanted since the OpenBSD road warrior is supposed > to have a static IP. >=20 > Log snippet: >=20 > 21:21:41 charon: 13[IKE] failed to establish CHILD_SA, keeping IKE_SA > 21:21:41 charon: 13[IKE] traffic selectors 10.XXX.XXX.0/24 10.YYY.YYY.0/24= =3D=3D=3D 10.ZZZ.ZZZ.0/24 10.ZZZ.ZZZ.0/24 inacceptable > 21:21:41 charon: 13[IKE] expected a virtual IP request, sending FAILED_CP_= REQUIRED >=20 > Has anybody managed to set up an road warrior connection with a static > IP on the remote end with Linux or OpenBSD? I haven't tried, but are you trying to connect a user with a static WAN=20 IP on their end, or are you trying to provide a static IP to them on the=20 Green LAN or similar? If it's the latter, I am pretty certain that the setting "rightsourceip"=20 is what controls whether Strongswan tries to give out a DHCP address to=20 the client when authenticating. In IPFire, this is set to whatever you=20 have in the global setting "Host-to-Net Virtual Private Network=20 (RoadWarrior):". Perhaps setting that to null would eliminate that=20 setting, or perhaps placing something in /etc/ipsec.user.conf would=20 override what is set by the WUI? > Generally, it seems that quite some bugs are related to IPsec: For example, > even though a N2N connection is using /24 remote networks, it says it uses > a /3 (virtually _everything_) at the main WebUI page... We have around 20 tunnels between IPFire hosts, and I had never noticed=20 that before, but I just went and looked, and sure as ****, it's there.=20 Perhaps this is the source of the bugs saying that an address is part of=20 an existing IPSec scope? The index.cgi page shows: "tunnelname 10.6.1.0/3 CONNECTED" while the output of "ipsec status tunnelname" shows: Routed Connections: tunnelname{102}: ROUTED, TUNNEL, reqid 17 tunnelname{102}: 10.254.0.0/23 =3D=3D=3D 10.253.1.0/24 10.253.2.0/24 Security Associations (26 up, 0 connecting): tunnelname[348]: ESTABLISHED 119 seconds ago, x.x.x.x[C=3DUS,=20 ST=3DNH, O=3DMyOrg, OU=3DEngineering Dept.,=20 CN=3Dhost1.myorg.dom]...y.y.y.y[C=3DUS, ST=3DNH, O=3DMyOrg - tunnelname,=20 OU=3DEngineering, CN=3Dhost2.myorg.dom] tunnelname{5022}: INSTALLED, TUNNEL, reqid 17, ESP SPIs:=20 cdbada31_i c4e24e27_o, IPCOMP CPIs: 5431_i 6977_o tunnelname{5022}: 10.254.0.0/23 =3D=3D=3D 10.253.1.0/24 10.253.2.0/24 tunnelname{5023}: INSTALLED, TUNNEL, reqid 17, ESP SPIs:=20 cfdce8b8_i c1d1780e_o, IPCOMP CPIs: 6d81_i cbd4_o tunnelname{5023}: 10.254.0.0/23 =3D=3D=3D 10.253.1.0/24 10.253.2.0/24 I'd say that's enough for now? Tom PS: I'm really excited about the Algo project. I have an Ubuntu host=20 built and I am going to try to test it out. I'll let you know what I=20 find, but it would be cool if some others would take a look. --===============6231053686254546476==--