[strongSwan] Help with routing

Tue Feb 11 15:06:51 CET 2020

Dear list,

I'm new to IPSec and need a hand trying to set up a VPN with a foreign 
institution.

Basically I have a single host offering some services that should also 
act as the IPSec client / left side host. This is the only left-side 
host that must be accessible from the right-side network.

On this left-side server I installed SUSE SLES 12 SP 1 with Strongswan 
5.1.3.

The right side uses a commercial solution (Fotinet Fortigate).

Using this configuration I can establish the IPSec connection:

*ipsec.conf*

config setup
         charondebug="all"
         uniqueids=yes
         strictcrlpolicy=no

conn %default
conn tunnel
         left=141.a.b.c
         leftsubnet=192.168.66.0/24
         lefthostaccess=yes
         leftsourceip=%config
         right=193.d.e.f
         rightsubnet=192.168.19.0/24
         ike=aes256-sha256-prfsha256-ecp521!
         esp=aes256-sha256!
         keyingtries=0
         ikelifetime=28800s
         lifetime=14400s
         dpddelay=30
         dpdtimeout=120
         dpdaction=restart
         authby=secret
         auto=start
         keyexchange=ikev2
         type=tunnel

The connection seems to be ok:
**

*ipsec statusall*

Status of IKE charon daemon (strongSwan 5.1.3, Linux 
3.12.74-60.64.124-default, x86_64):
   uptime: 21 hours, since Feb 10 16:04:02 2020
   malloc: sbrk 2838528, mmap 0, used 671024, free 2167504
   worker threads: 10 of 16 idle, 6/0/0/0 working, job queue: 0/0/0/0, 
scheduled: 5
   loaded plugins: charon ldap pkcs11 aes des blowfish rc2 sha1 sha2 md4 
md5 random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 
pkcs12 pgp dnskey sshkey pem openssl gcrypt af-alg fips-prf gmp agent 
xcbc cmac hmac ctr ccm gcm curl soup attr kernel-netlink resolve 
socket-default farp stroke smp updown eap-identity eap-sim eap-sim-pcsc 
eap-aka eap-aka-3gpp2 eap-simaka-pseudonym eap-simaka-reauth eap-md5 
eap-gtc eap-mschapv2 eap-dynamic eap-radius eap-tls eap-ttls eap-peap 
eap-tnc xauth-generic xauth-eap xauth-pam tnc-imc tnc-imv tnc-tnccs 
tnccs-20 tnccs-11 tnccs-dynamic dhcp certexpire led duplicheck radattr 
addrblock unity
Listening IP addresses:
   141.a.b.c
   192.168.66.1
Connections:
       tunnel:  141.a.b.c...193.d.e.f  IKEv2, dpddelay=30s
       tunnel:   local:  [141.a.b.c] uses pre-shared key authentication
       tunnel:   remote: [193.d.e.f] uses pre-shared key authentication
       tunnel:   child:  192.168.66.0/24 === 192.168.19.0/24 TUNNEL, 
dpdaction=restart
Security Associations (2 up, 0 connecting):
       tunnel[4]: ESTABLISHED 6 hours ago, 
141.a.b.c[141.a.b.c]...193.d.e.f[193.d.e.f]
       tunnel[4]: IKEv2 SPIs: fd1ce3e19651ea83_i b0e8873d947ad4e8_r*, 
pre-shared key reauthentication in 76 minutes
       tunnel[4]: IKE proposal: 
AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/ECP_521
       tunnel[1]: CONNECTING, 141.a.b.c[141.a.b.c]...193.d.e.f[193.d.e.f]
       tunnel[1]: IKEv2 SPIs: 38a8d3b8593af26a_i* 77f1ac5ed3598059_r
       tunnel[1]: IKE proposal: 
AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/ECP_521
       tunnel[1]: Tasks active: IKE_CERT_PRE IKE_AUTH IKE_CERT_POST 
IKE_CONFIG CHILD_CREATE IKE_AUTH_LIFETIME IKE_MOBIKE

However, there is some sort of routing problem. In either direction, 
packets travel through the tunnel, are seen on the other side,  but the 
responses never come back.

The IP address of the left machine:

*ip addr*

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN 
group default
     link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
     inet 127.0.0.1/8 scope host lo
        valid_lft forever preferred_lft forever
     inet6 ::1/128 scope host
        valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP 
group default qlen 1000
     link/ether 00:x:x:x:x:x brd ff:ff:ff:ff:ff:ff
     inet 141.a.b.c/22 brd 141.a.b.255 scope global eth0
        valid_lft forever preferred_lft forever
     inet 192.168.66.1/24 brd 192.168.66.255 scope global eth0:1
        valid_lft forever preferred_lft forever
     inet6 fe::0:f:f7:b/64 scope link
        valid_lft forever preferred_lft forever

The routing tables:

*ip route list table all*

192.168.19.0/24 via 192.168.66.1 dev eth0  table 220  proto static  src 
192.168.66.1
default via 141.a.b.1 dev eth0
141.a.b.0/22 dev eth0  proto kernel  scope link  src 141.a.b.c
192.168.66.0/24 dev eth0  proto kernel  scope link  src 192.168.66.1
broadcast 127.0.0.0 dev lo  table local  proto kernel  scope link src 
127.0.0.1
local 127.0.0.0/8 dev lo  table local  proto kernel  scope host src 
127.0.0.1
local 127.0.0.1 dev lo  table local  proto kernel  scope host  src 
127.0.0.1
broadcast 127.255.255.255 dev lo  table local  proto kernel  scope link  
src 127.0.0.1
broadcast 141.a.b.0 dev eth0  table local  proto kernel  scope link  src 
141.a.b.c
local 141.a.b.c dev eth0  table local  proto kernel  scope host src 
141.a.b.c
broadcast 141.a.b.255 dev eth0  table local  proto kernel  scope link  
src 141.a.b.c
broadcast 192.168.66.0 dev eth0  table local  proto kernel  scope link  
src 192.168.66.1
local 192.168.66.1 dev eth0  table local  proto kernel  scope host  src 
192.168.66.1
broadcast 192.168.66.255 dev eth0  table local  proto kernel scope link  
src 192.168.66.1
unreachable default dev lo  table unspec  proto kernel  metric 
4294967295  error -101
local ::1 dev lo  proto kernel  metric 256
fe80::/64 dev eth0  proto kernel  metric 256
unreachable default dev lo  table unspec  proto kernel  metric 
4294967295  error -101
local ::1 dev lo  table local  proto none  metric 0
local f::2:f:7:b8 dev lo  table local  proto none  metric 0
ff00::/8 dev eth0  table local  metric 256
unreachable default dev lo  table unspec  proto kernel  metric 
4294967295  error -101

*iptables -nL*

Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

I would really appreciate if someone could give a hint or two on how to 
solve this issue!

Kind regards
Alvaro

-- 
Dipl.-Inf. Alvaro Aguilera
Wissenschaftlicher Mitarbeiter

Technische Universität Dresden
Zentrum für Informationsdienste und Hochleistungsrechnen
Verteiltes und Datenintensives Rechnen

Büro:   Falkenbrunnen, Raum 242
         Chemnitzer Straße 46b
         01187 Dresden
Tel:    +49 (351) 463 33491
Email:  alvaro.aguilera at tu-dresden.de
Web:    http://www.tu-dresden.de/zih

OTR-Fingerprint:
9CD3BC97 ACFB7430 D084BA9D 4BEB1775 4B0BA9F1

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20200211/dd02c4d3/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5224 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.strongswan.org/pipermail/users/attachments/20200211/dd02c4d3/attachment.bin>