IPSec Roadwarrior Configuration

IPSec Roadwarrior Configuration

[Tom Rymes]

[-- Attachment #1: Type: text/plain, Size: 2594 bytes --]

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-_roadwarrior_with_windows

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

Re: IPSec Roadwarrior Configuration

[Peter Müller]

[-- Attachment #1: Type: text/plain, Size: 3832 bytes --]

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-_roadwarrior_with_windows
> 
> 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

Re: IPSec Roadwarrior Configuration

[Tom Rymes]

[-- Attachment #1: Type: text/plain, Size: 7551 bytes --]

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-_roadwarrior_with_windows

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.

Re: IPSec Roadwarrior Configuration

[Tom Rymes]

[-- Attachment #1: Type: text/plain, Size: 2271 bytes --]

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