I suppose that this isn't particularly "Development" related, but I think it does touch upon features and functionality that are important to making the project attractive to new users and I also think that, perhaps, some changes might be needed to the WUI to keep up with changes to clients. I would think that a tried-and-true configuration that makes it easy for any user to implement a VPN using built-in clients would be a major benefit to the project.
IPFire supports two methods for roadwarrior VPN clients, OpenVPN and IPSec. Of these, OpenVPN requires a client, while IPSec is supported natively by most or all major operating systems. For various reasons, I prefer IPSec.
Perusing the internet, one can find many tutorials for how to configure Strongswan to work with roadwarrior clients, and some of them might even work. There seems to be a lot of confusion out there over which settings are needed to support the various client OSs, too.
Most importantly, the WUI makes it look like this should just work out of the box, but I have not been able to find a good tutorial for using the WUI in IPFire to accomplish this task. There is one here:
https://wiki.ipfire.org/configuration/services/ipsec/example_configuration-_...
However, it is missing many details, and has not kept up with changes in the WUI. Worse, still, it requires one to manually modify the configuration files, which, ideally, should not be necessary.
After messing about with that tutorial, I have succeeded in connecting a Windows 10 computer, but I have not been able to succeed with a MacOS device, and I haven't even dared to try with iOS.
As it stands, it is unclear what one should enter for the fields Remote host/IP, Remote Subnet, Local ID, and Remote ID, and I am still unclear on what the proper settings for IKE/ESP settings, DPD, and the other options at the bottom of the page are.
I will continue to experiment and do my best to update the docs, but I'm flying pretty blind here. This leads me to a few questions (the forum has not been of much help in this area):
1.) Does anyone have a good tutorial that they can provide to help me in making this work and in improving the documentation? 2.) What changes to the WUI, if any, are needed to avoid the need to manually edit text files and properly support RoadWarrior connections to Windows 7/8/10, MacOS, Android, and iOS? 3.) What changes need to be made to the certs, configs, etc to support MacOS, iOS, and Android?
Many thanks,
Tom
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.
I suppose that this isn't particularly "Development" related, but I think it does touch upon features and functionality that are important to making the project attractive to new users and I also think that, perhaps, some changes might be needed to the WUI to keep up with changes to clients. I would think that a tried-and-true configuration that makes it easy for any user to implement a VPN using built-in clients would be a major benefit to the project.
IPFire supports two methods for roadwarrior VPN clients, OpenVPN and IPSec. Of these, OpenVPN requires a client, while IPSec is supported natively by most or all major operating systems. For various reasons, I prefer IPSec.
Me to.
Perusing the internet, one can find many tutorials for how to configure Strongswan to work with roadwarrior clients, and some of them might even work. There seems to be a lot of confusion out there over which settings are needed to support the various client OSs, too.
Most importantly, the WUI makes it look like this should just work out of the box, but I have not been able to find a good tutorial for using the WUI in IPFire to accomplish this task. There is one here:
https://wiki.ipfire.org/configuration/services/ipsec/example_configuration-_...
However, it is missing many details, and has not kept up with changes in the WUI. Worse, still, it requires one to manually modify the configuration files, which, ideally, should not be necessary.
+1
After messing about with that tutorial, I have succeeded in connecting a Windows 10 computer, but I have not been able to succeed with a MacOS device, and I haven't even dared to try with iOS.
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?
@Michael: Any hints? :-)
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...
Best regards, Peter Müller
As it stands, it is unclear what one should enter for the fields Remote host/IP, Remote Subnet, Local ID, and Remote ID, and I am still unclear on what the proper settings for IKE/ESP settings, DPD, and the other options at the bottom of the page are.
I will continue to experiment and do my best to update the docs, but I'm flying pretty blind here. This leads me to a few questions (the forum has not been of much help in this area):
1.) Does anyone have a good tutorial that they can provide to help me in making this work and in improving the documentation? 2.) What changes to the WUI, if any, are needed to avoid the need to manually edit text files and properly support RoadWarrior connections to Windows 7/8/10, MacOS, Android, and iOS? 3.) What changes need to be made to the certs, configs, etc to support MacOS, iOS, and Android?
Many thanks,
Tom
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.
Regarding the issue with display of subnets on the index.cgi page, I think I have (in our case) narrowed it down to tunnels with multiple subents defined in a comma separated list.
A tunnel with remote subnet "10.7.0.0/24,10.7.1.0/24" displayed on index.cgi as "10.7.0.0/3". When changed to "10.7.0.0/23", it displays properly on index.cgi.
I suspect that the code to display the subnet pre-dates the change to allow multiple subnets in one tunnel and needs to be modified?
I have opened bug 11604 for this issue. https://bugzilla.ipfire.org/show_bug.cgi?id=11604
Tom
PS: My output below was wrong, the index.cgi page showed 10.253.0.0/3, not "10.6.0.0/3". I fixed that in the bug description.
On 01/29/2018 12:26 PM, Tom Rymes wrote:
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
On 01/24/2018 3:33 PM, Tom Rymes wrote:
I suppose that this isn't particularly "Development" related, but I think it does touch upon features and functionality that are important to making the project attractive to new users and I also think that, perhaps, some changes might be needed to the WUI to keep up with changes to clients. I would think that a tried-and-true configuration that makes it easy for any user to implement a VPN using built-in clients would be a major benefit to the project.
Just to keep everyone up to date, I have posted instructions for setting up an IPSec Roadwarrior connection with MacOS to the Wiki.
https://wiki.ipfire.org/configuration/services/ipsec/example_configuration-_...
If anyone can test it out and see if I have forgotten anything, made a typo, or two, or simply just made it too complicated, that would be awesome.
I think that there might be some additional improvements that could be made, including adding a uniqueids=no (or similar) to allow more than one connection to the tunnel at a time. That would, of course, require manual editing of /etc/ipsec.user.conf, but that's already the case.
My suspicion is that this could easily be made to work with iOS, but I haven't tried yet.
Also, I was able to install and work with Algo (https://blog.trailofbits.com/2016/12/12/meet-algo-the-vpn-that-works/), and I can say that it is simply head and shoulders above what we currently offer in IPFire. Setup is easy on the server side (once I worked out a few small, confusing items), and installation on the client (especially for Apple devices) is so easy it could make a grown man cry.
MacOS: Download file, double-click file, enter password, done. iOS: Download file to mac, airdrop to device, tap accept, tap install, enter password, done.
If you want, you can set up Algo to tell MacOS and iOS clients to automatically connect to VPN when on cellular, when on WiFi, or both. You can also manually edit the profile on the server to do things like force VPN except when connected to Wi-Fi on ESSID "MyNetwork", etc.
I haven't tried Windows clients, yet, but just avoiding the "what do I put in this field?" portion of configuring a tunnel is a major achievement.
I am not in possession of the skills required to move the WUI forward in this area, or I would gladly do so. Having said that, there are two things I think would be worthwhile:
1.) Add the server hostname to the SAN when generating certs. https://bugzilla.ipfire.org/show_bug.cgi?id=11594 2.) Update the Roadwarrior portion of the WUI to automatically configure the various parts to work properly with Windows/Mac/iOS/Android. Eliminate fields such as "Local ID" if those have to be set to a specific value for a given platform, etc. This can get a bit tricky, as if the user didn't specify the proper setting when generating the host cert, then it may not work with all platforms.
Does anyone other than myself and Peter have any thoughts on this? I'm surprised that nobody else has chimed in about something I consider a really important/beneficial feature. This is important for any business needing to provide remote access to roaming users, plus anyone that wants to protect their data from prying eyes while on public Wi-Fi, etc.
Tom
-
Peter Müller -
Tom Rymes