IPSEC IKEV1 site to site VPN

fow0ryl · October 11, 2020, 10:23am

Hello,

I'm trying to replace an ipfire based router by an openwrt based.
Since my friend is running a small business the router has to be changed with 1:1 functionality plus addons. OpenVPN is installed to connect a roadwarrior to his local network. To do his real work they are connected via IPSEC to another company.
It is required, that a roadwarrior connected via OpenVPN can use this IPSEC connection too.

Until now I got OpenVPN and WireGuard running on OpenWrt as VPN solutions for the roadwarriors.

Next step is to get the IPSEC connection running. One problem is, that I did not get any information from the company who runs the IPSEC server. They only want to sell a closed source appliance. And I'm a IPSEC noob

Actually the connection from ipfire based router to the ipsec server is running fine. I hope that I can transfer the connection settings to OpenWrt.

Here is the config fire of ipfire:
`conn %default
keyingtries=%forever

conn SE
left=%defaultroute
leftsubnet=192.168.4.0/24,10.168.4.0/24
leftfirewall=yes
lefthostaccess=yes
right=80.70.60.50
rightsubnet=172.168.4.248/29
leftid="80.15.19.30"
rightid="80.70.60.50"
type=tunnel
ike=aes256-sha2_256-modp2048
esp=aes256-sha2_256-modp2048
keyexchange=ikev1
ikelifetime=8h
keylife=8h
dpdaction=restart
dpddelay=10
dpdtimeout=60
authby=secret
auto=start
fragmentation=yes`

found a ipsec.secrets file too
80.15.19.30 80.15.19.30 : PSK '0........L='

Of course I have replaced the real values with this ones ...
local network: 192.168.4.0/24 openvpn network: 10.168.4.0/24 remote server side network: 172.168.4.248/29 public ip ipsec server side: 80.70.60.50 public ip my side: 80.15.19.30

When looking in the OpenWrt wiki I found a Site-to-Site sample. But the configuration looks complete different. And I did not know how to convert parms

Found another HowTo for IKEV1

This seems to be much closer to the ipfire configuration. But questions over questions ...
Can I use this one with a actual snapshot?
Where to find info about different parms? i.e. "left=%defaultroute"
Are really all packages reqired? I.E. strongswan-mod-blowfish because my config shows AES

Henning

slh · October 11, 2020, 7:04pm

OpenWrt is using strongswan - and I assume ipfire is using the same as well, so you should be able to use most as-is (but it will need some tinkering).

mpa · October 11, 2020, 7:57pm

Note that IKEv1 with multiple subnets requires the Cisco Unity Extensions.

IPFire 2.7 and later indeed use strongSwan.
Search for the cisco_unity option in /etc/strongswan.conf or under /etc/strongswan.d/. If it is set to yes, you need to replicate this, and also any other options which were changed from their default.

I suggest to look at the output of ipsec statusall now and after the upgrade, and check for differences, especially in the tunneled subnets.

In the ipsec.conf manpage or the strongSwan wiki (same link as above).
About left=%defaultroute:

I changed my configuration to use %any (the default).

fow0ryl · October 14, 2020, 12:37pm

Sorry,
did not find any time the last days, to do more investigation.

I did a ipsec statusall on the ipfire machine but hrere is no hint to Cicso Extensions.
I remember it was nesserary to add the second "left subnet value" to allow users connected via openvpn to ipfire to use the ipsec connection too.
Before that it, only users from local lan are allowed.

Found that there is a additional ip in statusall.
192.168.14.10 is the routers wan interface

root@ipfire-x86-64 ~]# ipsec statusall
Status of IKE charon daemon (strongSwan 5.8.0, Linux 4.14.138-ipfire, x86_64):
  uptime: 115 days, since Jun 21 10:46:18 2020
  malloc: sbrk 3891200, mmap 0, used 1560736, free 2330464
  worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 4
  loaded plugins: charon aes des sha2 sha1 md5 mgf1 random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey pem openssl gcrypt fips-prf gmp curve25519 chapoly xcbc cmac hmac ctr ccm gcm curl attr kernel-netlink resolve socket-default farp stroke vici updown eap-identity eap-mschapv2 eap-radius eap-tls eap-ttls eap-peap xauth-generic xauth-eap xauth-noauth dhcp counters
Listening IP addresses:
  192.168.4.1
  192.168.14.10
  10.168.4.1
Connections:
          SE:  %any...80.70.60.50  IKEv1, dpddelay=10s
          SE:   local:  [80.15.19.30] uses pre-shared key authentication
          SE:   remote: [80.70.60.50] uses pre-shared key authentication
          SE:   child:  192.168.4.0/24 10.168.4.0/24 === 172.168.4.248/29 TUNNEL, dpdaction=restart
Security Associations (1 up, 0 connecting):
          SE[502]: ESTABLISHED 3 hours ago, 192.168.14.10[80.15.19.30]...80.70.60.50[80.70.60.50]
          SE[502]: IKEv1 SPIs: e45dd4d6c9d9aa37_i* a4d3aa4332406a62_r, pre-shared key reauthentication in 4 hours
          SE[502]: IKE proposal: AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048
          SE{364}:  INSTALLED, TUNNEL, reqid 5, ESP in UDP SPIs: c1511d82_i aa547304_o
          SE{364}:  AES_CBC_256/HMAC_SHA2_256_128/MODP_2048, 52734940 bytes_i (134368 pkts, 1s ago), 11487574 bytes_o (120671 pkts, 0s ago), rekeying in 3 hours
          SE{364}:   192.168.4.0/24 === 172.168.4.248/29

mpa · October 14, 2020, 2:40pm

The unity plugin is not active...

... and packets with IP addresses from the 10.168.4.0/24 subnet are not admitted to the tunnel.

Here is how it would look like if the unity plugin was active:

Now I suggest to investigate why the OpenVPN clients can use the IPsec tunnel at all. Some other mechanism must be active to enable this.

fow0ryl · October 15, 2020, 2:01pm

I have configured openwrt ipsec now.

root@OpenWrt:~# ipsec statusall
Status of IKE charon daemon (strongSwan 5.9.0, Linux 5.4.67, x86_64):
  uptime: 1 day, since Oct 13 18:08:55 2020
  worker threads: 7 of 16 idle, 5/0/4/0 working, job queue: 0/0/0/0, scheduled: 1
  loaded plugins: charon test-vectors pkcs11 aes des blowfish rc2 sha2 sha1 md4 md5 random nonce x509 revocation constraints pubkey pkcs1 pkcs8 pgp dnskey sshkey pem openssl gcrypt af-alg fips-prf gmp xcbc hmac attr kernel-libipsec kernel-netlink resolve socket-default connmark farp stroke updown xauth-generic dhcp
Listening IP addresses:
  192.168.14.13
  192.168.4.3
  10.168.14.1
  10.168.4.1
Connections:
          SE:  %any...80.70.60.50  IKEv1, dpddelay=10s
          SE:   local:  [80.15.15.30 uses pre-shared key authentication
          SE:   remote: [80.70.60.50] uses pre-shared key authentication
          SE:   child:  192.168.4.0/24 10.168.4.0/24 === 172.168.4.248/29 TUNNEL, dpdaction=restart
Security Associations (0 up, 1 connecting):
          SE[1]: CONNECTING, 192.168.14.13[%any]...80.70.60.50[%any]
          SE[1]: IKEv1 SPIs: 1c9c875eccac42de_i* 0000000000000000_r                                                                                                                              
          SE[1]: Tasks queued: QUICK_MODE                                                                                                                                                        
          SE[1]: Tasks active: ISAKMP_VENDOR ISAKMP_CERT_PRE MAIN_MODE ISAKMP_CERT_POST ISAKMP_NATD

There are still some plugins missing. But I did not know if they are really needed.

pkcs7 pkcs12 gcm curl vici eap-identity eap-mschapv2 eap-radius eap-tls eap-ttls eap-peap xauth-generic xauth-eap xauth-noauth counters

In difference to the strongSwan sample, all my roadwarriors are connected via openvpn.
And on ipfire it was necessary to add an iptables entry to allow these roadwarriors to access the ipsec network. Nothing more ...