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 2167504worker 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 authenticationtunnel: 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_rtunnel[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 forever2: 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.1broadcast 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 256unreachable 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 256unreachable 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 destinationI 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: [email protected]
Web: http://www.tu-dresden.de/zih
OTR-Fingerprint:
9CD3BC97 ACFB7430 D084BA9D 4BEB1775 4B0BA9F1
smime.p7s
Description: S/MIME Cryptographic Signature
