Re: IPSec Roadwarrior Configuration

[Tom Rymes <trymes@rymes.com>]

[-- 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.