On 01/29/2018 9:58 AM, Peter Müller wrote:
Hello Tom,
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 time lurking on the Strongswan Users list, I suspect that the IPFire N2N tunnel configurations built by the WUI could be optimized, and a recent 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 this issue since my first message, and it's a mess out there. The best summary I ran across was that working with Strongswan/Libreswan/Freeswan required an almost "tribal knowledge". Add in the fact that seemingly no two clients respond in the same way or can be supported by the same configuration, and it gets worse.
I did get Windows and MacOS RW connections working, but it's still way too difficult. I also updated and improved the Wiki page I linked to earlier for Windows RW connections, and I intend to put one up for MacOS connections, too.
I have been meaning to summarize my thoughts here and offer a few suggestions, but I haven't had a chance, so rather than wait, I will use your response as an excuse to toss out a few thoughts I have had without really organizing them as best as I can (I will try to open bug reports later today, where appropriate):
1.) It would be nice if the "Advanced Settings" page was a drop-down portion of the main settings page for a tunnel. Having to click through to a second page to view those settings is an annoyance. It also results in the tunnel being brought up with default settings when created, then 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 the global settings area that were disabled by default. If you needed to connect to some old, out-of-date Cisco ASA that only supports SHA1 and MODP-1024, then you can check the box and those ciphers will appear in the WUI.
3.) According to Noel at Strongswan, the settings "authby=rsasig", "leftrsasigkey=%cert", and "rightrsasigkey=%cert" written out to RW configs are superfluous, as leftauth/rightauth both default to "pubkey". I suspect that this is due to leftover code from the old ikev1 pluto setup, or even OpenSWAN.
4.) Regarding the settings "leftfirewall=yes" and "lefthostaccess=yes", Noel mentioned "Don't do that, you better use static iptables rules with the policy match module." I'm not certain where to go with that, but I 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 allow a user to select "Support MacOS" and "Support Windows 7/8/10", etc. Then, depending on which boxes were checked, different options would be built in the config. Using the "also=" to include settings from other tunnels, the WUI would write out multiple conn sections that include the proper settings for each platform. See the examples under "responder" and "ipsec.conf" listed here: https://wiki.strongswan.org/projects/strongswan/wiki/UsableExamples
Lastly, I am wondering if the project is reinventing the wheel here a bit. While researching this stuff, I ran across this project, which looks really promising, and which could, perhaps, be built as an add-on, or we could at least look into adopting some of their better ideas? One super-cool feature is the automated building of XML configuration 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-_...
I did update this, and it is much improved, but we still need to amke this simpler, I think. I was able to make MacOS clients work, but you have to add this to the /etc/ipsec.user.conf file (replace "xxx.xxx.xxx.xxx" with your DNS IP address - I used the IPFire Green address):
conn tunnelname leftsendcert=always leftallowany=yes rightdns=xxx.xxx.xxx.xxx rekey=no reauth=no
You also need to set the root CA to always trust on the Mac, and to avoid an annoying dialog, you need to "Allow access for all apps" for 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.
Log snippet:
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 === 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
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 IP on their end, or are you trying to provide a static IP to them on the Green LAN or similar?
If it's the latter, I am pretty certain that the setting "rightsourceip" is what controls whether Strongswan tries to give out a DHCP address to the client when authenticating. In IPFire, this is set to whatever you have in the global setting "Host-to-Net Virtual Private Network (RoadWarrior):". Perhaps setting that to null would eliminate that setting, or perhaps placing something in /etc/ipsec.user.conf would 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 that before, but I just went and looked, and sure as ****, it's there. Perhaps this is the source of the bugs saying that an address is part of 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 === 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=US, ST=NH, O=MyOrg, OU=Engineering Dept., CN=host1.myorg.dom]...y.y.y.y[C=US, ST=NH, O=MyOrg - tunnelname, OU=Engineering, CN=host2.myorg.dom] tunnelname{5022}: INSTALLED, TUNNEL, reqid 17, ESP SPIs: cdbada31_i c4e24e27_o, IPCOMP CPIs: 5431_i 6977_o tunnelname{5022}: 10.254.0.0/23 === 10.253.1.0/24 10.253.2.0/24 tunnelname{5023}: INSTALLED, TUNNEL, reqid 17, ESP SPIs: cfdce8b8_i c1d1780e_o, IPCOMP CPIs: 6d81_i cbd4_o tunnelname{5023}: 10.254.0.0/23 === 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 built and I am going to try to test it out. I'll let you know what I find, but it would be cool if some others would take a look.