[strongSwan] Help with IKEv1 Site-to-site PSK IPv4

Noel Kuntze noel.kuntze+strongswan-users-ml at thermi.consulting
Mon Sep 4 21:09:30 CEST 2017 

Hi,

Advise for your problem and corrections for incorrect statements are found in the text, below
the corresponding quoted section from your mail.

On 04.09.2017 20:20, Charles-Antoine Giuliani wrote:
> I followed the configuration at
> https://www.strongswan.org/testing/testresults/ikev1/net2net-psk/
> (closest configuration I could find, though the examples seem to have been designed for local networks)
Those are not examples, as the introduction page to the test results says[1][2]. You are not supposed to use those.
There is a dedicated article[3] on the wiki about example configurations. Read the introduction[4] and the article about forwarding[5] first,
then use the configuration for the corresponding scenario (site-to-site scenario). The test scenarios are tests that are run in a virtualized LAN environment
using QEMU, so this obviously does not correspond to a real life deployment. This is also made clear in the warning[2].

>
> However the computer does not manage to connect
>
> thyfate at DataLearning-001:~$ sudo ipsec start
> Starting strongSwan 5.1.2 IPsec [starter]...
> charon is already running (/var/run/charon.pid exists) -- skipping daemon start
> starter is already running (/var/run/starter.charon.pid exists) -- no fork done
> thyfate at DataLearning-001:~$ sudo ipsec up ciscoios
> initiating Main Mode IKE_SA ciscoios[3554] to 83.XXX.XXX.XXX
> generating ID_PROT request 0 [ SA V V V V ]
> sending packet: from 93.XXX.XXX.XXX[500] to 83.XXX.XXX.XXX[500] (196 bytes)
> sending retransmit 1 of request message ID 0, seq 1
> sending packet: from 93.XXX.XXX.XXX[500] to 83.XXX.XXX.XXX[500] (196 bytes)
> sending retransmit 2 of request message ID 0, seq 1
> sending packet: from 93.XXX.XXX.XXX[500] to 83.XXX.XXX.XXX[500] (196 bytes)
> sending retransmit 3 of request message ID 0, seq 1
> sending packet: from 93.XXX.XXX.XXX[500] to 83.XXX.XXX.XXX[500] (196 bytes)
> sending retransmit 4 of request message ID 0, seq 1
> sending packet: from 93.XXX.XXX.XXX[500] to 83.XXX.XXX.XXX[500] (196 bytes)
> sending retransmit 5 of request message ID 0, seq 1
> sending packet: from 93.XXX.XXX.XXX[500] to 83.XXX.XXX.XXX[500] (196 bytes)
> giving up after 5 retransmits
> establishing IKE_SA failed, peer not responding
> establishing connection 'ciscoios' failed

That obviously does not work, because you are neither supposed to, nor allowed to send IP packets from an IP
address that is not bound to your host. You can work around that, but it is neither the or even a solution to your problem
nor advised to try to do that. At least your home router would drop the packets because of the bogus source. I am very certain
that charon logs a corresponding error message in syslog or the journal, whenever you try to initiate the connection

The "left" parameter is described as follows in the first paragraph about it on the man page:
>       left = <ip address> | <fqdn> | %any | <range> | <subnet>
>              The IP address of the left participant's public-network interface or one of several magic values.  The value %any (the default) for the local endpoint signifies an address
>              to be filled in (by automatic keying) during negotiation. If the local peer initiates the connection setup the routing table will be queried to determine the correct local
>              IP address.  In case the local peer is responding to a connection setup then any IP address that is assigned to a local interface will be accepted.

As you can read, that parameter is neither appropriate nor needed in your case, because 93.XXX.XXX.XXX is not bound to any local interface. Just don't use "left". Charon is smart
enough to determine the correct source IP by itself, as the man page describes.

> Below some details on the setup:
>
> I am using Ubuntu 14.04. My computer is behind an ISP-provided router box where ports 500 and 4500 have been NAT - forwarded, both on TCP and UDP. My computer external address is 93.XXX.XXX.XXX and the local network the computer is on has ranges 192.168.1.XXX, the specific machine having ip 192.168.1.104. On the other side, a Cisco ASA 5520 is used to create the VPN on an external ip address of 83.XXX.XXX.XXX.
>
> Strongswan was installed with the following command line
>
> sudo apt-get install strongswan strongswan-plugin-af-alg strongswan-plugin-agent strongswan-plugin-certexpire strongswan-plugin-coupling strongswan-plugin-curl strongswan-plugin-dhcp strongswan-plugin-duplicheck strongswan-plugin-eap-aka strongswan-plugin-eap-aka-3gpp2 strongswan-plugin-eap-dynamic strongswan-plugin-eap-gtc strongswan-plugin-eap-mschapv2 strongswan-plugin-eap-peap strongswan-plugin-eap-radius strongswan-plugin-eap-tls strongswan-plugin-eap-ttls strongswan-plugin-error-notify strongswan-plugin-farp strongswan-plugin-fips-prf strongswan-plugin-gcrypt strongswan-plugin-gmp strongswan-plugin-ipseckey strongswan-plugin-kernel-libipsec strongswan-plugin-ldap strongswan-plugin-led strongswan-plugin-load-tester strongswan-plugin-lookip strongswan-plugin-ntru strongswan-plugin-pgp strongswan-plugin-pkcs11 strongswan-plugin-pubkey strongswan-plugin-radattr strongswan-plugin-sshkey strongswan-plugin-systime-fix strongswan-plugin-whitelist strongswan-plugin-xauth-eap
> strongswan-plugin-xauth-generic strongswan-plugin-xauth-noauth strongswan-plugin-xauth-pam

Never do that unless you need the package and know what it does. There are packets that cause very hard problems and obstacles when installed without reason, e.g. "strongswan-plugin-kernel-libipsec". Remove that package.


> ============================================================
> /etc/ipsec.conf
> ============================================================
> # ipsec.conf - strongSwan IPsec configuration file
>
> # basic configuration
>
> config setup
> # strictcrlpolicy=yes
> # uniqueids = no
>
> # Add connections here.
>
> # Sample VPN connections
>
> #conn sample-self-signed
> #      leftsubnet=10.1.0.0/16 <http://10.1.0.0/16>
> #      leftcert=selfCert.der
> #      leftsendcert=never
> #      right=192.168.0.2
> #      rightsubnet=10.2.0.0/16 <http://10.2.0.0/16>
> #      rightcert=peerCert.der
> #      auto=start
>
> #conn sample-with-ca-cert
> #      leftsubnet=10.1.0.0/16 <http://10.1.0.0/16>
> #      leftcert=myCert.pem
> #      right=192.168.0.2
> #      rightsubnet=10.2.0.0/16 <http://10.2.0.0/16>
> #      rightid="C=CH, O=Linux strongSwan CN=peer name"
> #      auto=start
>
> conn %default
>         ikelifetime=1440m
>         keylife=60m
>         rekeymargin=3m
>         keyingtries=1
>         keyexchange=ikev1
>         authby=secret
>
> conn ciscoios
>         left=93.XXX.XXX.XXX                  #strongswan outside address
>         leftsubnet=172.31.17.0/28 <http://172.31.17.0/28>         #network behind strongswan
>         leftid=93.XXX.XXX.XXX                #IKEID sent by strongswan
>         leftfirewall=no
>         right=83.XXX.XXX.XXX                 #IOS outside address
>         rightsubnet=172.21.148.0/28 <http://172.21.148.0/28>        #network behind IOS
>         rightid=83.XXX.XXX.XXX               #IKEID sent by IOS
>         auto=add
>         ike=aes256-sha-modp1024           #P1: modp1024 = DH group 2
>         esp=aes256-sha1                   #P2

DH group 2 is broken[6]. Avoid it.
In any case, use auto=route, don't set "left", "leftfirewall" is superfluous, rightid does not need to be set in your case and try to use PFS. It's basically free and it is good practice to use it.
Remove anything above the "conn ciscoios" section and move "keyexchange=ikev1" into "conn ciscoios". Set "keyingtries=%forever", "leftauth=psk" and "rightauth=psk".

> thyfate at DataLearning-001:~$ sudo ipsec statusall
> [sudo] password for thyfate: 
> Status of IKE charon daemon (strongSwan 5.1.2, Linux 3.16.0-77-generic, x86_64):
>   uptime: 42 days, since Jul 24 07:41:43 2017
>   malloc: sbrk 2904064, mmap 266240, used 581776, free 2322288
>   worker threads: 10 of 16 idle, 6/0/0/0 working, job queue: 0/0/0/0, scheduled: 1
>   loaded plugins: charon test-vectors curl unbound ldap pkcs11 aes rc2 sha1 sha2 md4 md5 rdrand random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp sshkey ipseckey pem openssl gcrypt af-alg fips-prf gmp xcbc cmac hmac ctr ccm gcm ntru attr kernel-netlink resolve socket-default farp stroke updown eap-identity eap-aka eap-aka-3gpp2 eap-gtc eap-mschapv2 eap-dynamic eap-radius eap-tls eap-ttls eap-peap xauth-generic xauth-eap xauth-noauth dhcp whitelist lookip error-notify certexpire led duplicheck radattr addrblock
> Listening IP addresses:
>   192.168.1.104
> Connections:
>     ciscoios:  93.XXX.XXX.XXX...83.XXX.XXX.XXX  IKEv1
>     ciscoios:   local:  [93.XXX.XXX.XXX] uses pre-shared key authentication
>     ciscoios:   remote: [83.XXX.XXX.XXX] uses pre-shared key authentication
>     ciscoios:   child:  0.0.0.0/0 <http://0.0.0.0/0> === 172.21.148.0/28 <http://172.21.148.0/28> TUNNEL

The local TS does not match your configuration (0.0.0.0/0 <=> 172.31.17.0/28). Do not try to use larger traffic selectors than requested by the administrator
of the other peer. Other IKE software does not implement IKEv1 traffic selector narrowing, so this configuration will throw errors, because the subnets are different from the ones configured,
if the remote peer is for example a Cisco or Juniper device.

> Security Associations (1 up, 0 connecting):
>     ciscoios[3554]: CONNECTING, 93.XXX.XXX.XXX[%any]...83.XXX.XXX.XXX[%any]
>     ciscoios[3554]: IKEv1 SPIs: 1b151f2a679038df_i* 0000000000000000_r
>     ciscoios[3554]: Tasks queued: QUICK_MODE 
>     ciscoios[3554]: Tasks active: ISAKMP_VENDOR ISAKMP_CERT_PRE MAIN_MODE ISAKMP_CERT_POST ISAKMP_NATD 
>

> thyfate at DataLearning-001:~$ sudo iptables-save
> # Generated by iptables-save v1.4.21 on Mon Sep  4 08:39:12 2017
> *nat
> :PREROUTING ACCEPT [14381:2557534]
> :INPUT ACCEPT [14224:2540988]
> :OUTPUT ACCEPT [18294:1425542]
> :POSTROUTING ACCEPT [18294:1425542]
> -A POSTROUTING -s 172.31.17.0/28 <http://172.31.17.0/28> -o eth0 -j MASQUERADE

That rule will cause problems. Read the article about NAT problems[7] and then apply the rule to fix it.

> COMMIT
> # Completed on Mon Sep  4 08:39:12 2017
> # Generated by iptables-save v1.4.21 on Mon Sep  4 08:39:12 2017
> *filter
> :INPUT ACCEPT [676542:524740723]
> :FORWARD ACCEPT [0:0]

The counters are suspiciously low. Check if forwarding is enabled. Fix it appropriately following the article about forwarding[5].

> :OUTPUT ACCEPT [434134:197554510]
> :fail2ban-ssh - [0:0]
> -A INPUT -p tcp -m multiport --dports 22 -j fail2ban-ssh
> -A fail2ban-ssh -j RETURN
> COMMIT
> # Completed on Mon Sep  4 08:39:12 2017
>

Kind regards

Noel

[1] https://wiki.strongswan.org/projects/strongswan/wiki/ConfigurationExamples
[2] https://wiki.strongswan.org/projects/strongswan/wiki/ConfigurationExamplesNotes
[3] https://wiki.strongswan.org/projects/strongswan/wiki/UsableExamples
[4] https://wiki.strongswan.org/projects/strongswan/wiki/IntroductionTostrongSwan
[5] https://wiki.strongswan.org/projects/strongswan/wiki/ForwardingAndSplitTunneling
[6] https://wiki.strongswan.org/projects/strongswan/wiki/SecurityRecommendations#Logjam (Read the paragraph titled "LogJam")
[7] https://wiki.strongswan.org/projects/strongswan/wiki/ForwardingAndSplitTunneling#General-NAT-problems

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.strongswan.org/pipermail/users/attachments/20170904/656f10a9/attachment.sig>

More information about the Users mailing list