MikroTik VPN IKEv2 + Ubuntu Strongswan nem megy [MAJDNEM MEGOLDVA]

Hálózatok általános

Beállítottam egy VPN szervert MikroTik router-en, IPSEC/IKEv2 tanúsítványos azonosítással. Windows 10-ből tudok is hozzá kapcsolódni minden gond nélkül. Ubuntu 20.04-ből strongswan klienssel nem megy.

Kapcsolódáskor a phase 1 sikerül, a phase 2 már nem.

MikroTik oldalon el látszódik:

10:45:51 ipsec,info new ike2 SA (R): 1.2.3.4[500]-1.2.3.5[38686] spi:204f64a24c6547c9:138380a9aa8a7f1e
10:45:51 ipsec,info,account peer authorized: 1.2.3.4[4500]-1.2.3.5[52733] spi:204f64a24c6547c9:138380a9aa8a7f1e
10:45:51 ipsec,info killing ike2 SA: 1.2.3.4[4500]-1.2.3.5[52733] spi:204f64a24c6547c9:138380a9aa8a7f1e

Linux oldalon syslogban ez látszódik:

Dec 22 10:45:51 laci-ryzen charon-nm: 11[IKE] authentication of 'vpn.my.server.hu' with RSA signature successful
Dec 22 10:45:51 laci-ryzen charon-nm: 11[IKE] IKE_SA laci@my.server.hu[9] established between 192.168.14.2[C=HU, ST=Heves, L=Eger, O=my.server.hu, CN=laci@vpn.my.server.hu]...1.2.3.5[vpn.my.server.hu]
Dec 22 10:45:51 laci-ryzen charon-nm: 11[IKE] scheduling rekeying in 35986s
Dec 22 10:45:51 laci-ryzen charon-nm: 11[IKE] maximum IKE_SA lifetime 36586s
Dec 22 10:45:51 laci-ryzen charon-nm: 11[IKE] received TS_UNACCEPTABLE notify, no CHILD_SA built
Dec 22 10:45:51 laci-ryzen NetworkManager[1175]: <warn>  [1608630351.9743] vpn-connection[0x5581fb598160,e430f863-b8b7-4f23-8b49-0fd2a8036d13,"laci@my.server.hu",0]: VPN plugin: failed: connect-failed (1)
Dec 22 10:45:51 laci-ryzen charon-nm: 11[IKE] failed to establish CHILD_SA, keeping IKE_SA
Dec 22 10:45:51 laci-ryzen NetworkManager[1175]: <warn>  [1608630351.9744] vpn-connection[0x5581fb598160,e430f863-b8b7-4f23-8b49-0fd2a8036d13,"laci@my.server.hu",0]: VPN plugin: failed: connect-failed (1)
Dec 22 10:45:51 laci-ryzen charon-nm: 12[IKE] deleting IKE_SA laci@my.server.hu[9] between 192.168.14.2[C=HU, ST=Heves, L=Eger, O=my.server.hu, CN=laci@vpn.my.server.hu]...1.2.3.5[vpn.my.server.hu]

Dec 22 10:45:51 laci-ryzen NetworkManager[1175]: <info>  [1608630351.9744] vpn-connection[0x5581fb598160,e430f863-b8b7-4f23-8b49-0fd2a8036d13,"laci@my.server.hu",0]: VPN plugin: state changed: stopping (5)
Dec 22 10:45:51 laci-ryzen charon-nm: 12[IKE] sending DELETE for IKE_SA laci@my.server.hu[9]
Dec 22 10:45:51 laci-ryzen NetworkManager[1175]: <info>  [1608630351.9744] vpn-connection[0x5581fb598160,e430f863-b8b7-4f23-8b49-0fd2a8036d13,"laci@my.server.hu",0]: VPN plugin: state changed: stopped (6)
Dec 22 10:45:51 laci-ryzen charon-nm: 12[ENC] generating INFORMATIONAL request 2 [ D ]
Dec 22 10:45:51 laci-ryzen charon-nm: 12[NET] sending packet: from 192.168.14.2[52733] to 1.2.3.5[4500] (80 bytes)
Dec 22 10:45:51 laci-ryzen dunst[2914]: WARNING: No icon found in path: 'gnome-lockscreen'
Dec 22 10:45:51 laci-ryzen /usr/lib/gdm3/gdm-x-session[2427]: "No such interface “org.freedesktop.DBus.Properties” on object at path /org/freedesktop/NetworkManager/ActiveConnection/13"
Dec 22 10:45:51 laci-ryzen /usr/lib/gdm3/gdm-x-session[2427]: "No such interface “org.freedesktop.DBus.Properties” on object at path /org/freedesktop/NetworkManager/ActiveConnection/13"
Dec 22 10:45:51 laci-ryzen charon-nm: 13[NET] received packet: from 1.2.3.5[4500] to 192.168.14.2[52733] (128 bytes)
Dec 22 10:45:51 laci-ryzen charon-nm: 13[ENC] parsed INFORMATIONAL response 2 [ ]
Dec 22 10:45:51 laci-ryzen charon-nm: 13[IKE] IKE_SA deleted

Először azt gondoltam hogy azért nem fogadja el, mert az IKE_SA maximum lifetime-nak 36586 másodpercet írt, de a szerver oldalon a /ip ipsec proposal alatt lifetime=8h van beállítva. Ezt átírtam 11h -ra hogy beleférjen, de így se működik.

Van bárkinek bármi ötlete, hogy mi lehet a baj? A naplók ebből a szempontból nem túl informatívak. Ez a TS_UNACCEPTABLE csak annyit jelent, hogy a szerver szerint valami nem elfogadható. De hogy mi???

507 megtekintés

A TS_UNACCEPTABLE azt jelenti hogy a Traffic Selectorral van probléma amit a Strongswan küld a Mikortiknek, ezért jön vissza az üzenet.

De mivel a konfigot nem látjuk ennyiből nem tudjuk, hogy mi a baj. A Mikrotikon lehet loglevelt kéne emelni, és akkor látszanak talán milyen net/mask-ot küld a Strongswan és a Mikrotik szerint miért nem jó az neki.

0 szavazat

A hozzászóláshoz be kell jelentkezni

Bemásoltam ide:

https://pastebin.com/8GKtZ9Cv

Az IP címeket és host neveket átírtam, illetve a packet debug részt (sok hexa kódot) kivettem.

0 szavazat

A hozzászóláshoz be kell jelentkezni

A logban ez az első ami error:

11:02:19 ipsec searching for policy for selector: 192.168.13.0/24 <=> 192.168.14.2
11:02:19 ipsec no template matches
11:02:19 ipsec,error no policy found/generated

A szerver oldalon ez van megadva policy-nak:

/ip ipsec policy
add dst-address=10.0.88.0/24 group="group vpn.my.server.hu" proposal="proposal vpn.my.server.hu" \
    src-address=0.0.0.0/0 template=yes

A dst-address része nem stimmelne? A VPN szerver oldalon a mode-config-ban ez a pool van megadva:

/ip ipsec mode-config
add address-pool=vpn.my.server.hu address-prefix-length=32 name="modeconf vpn.my.server.hu" \
    split-include=192.168.13.0/24 static-dns=10.0.88.1 system-dns=no

És az a pool ilyen:

/ip pool
add comment="VPN IKEv2 clients" name=vpn.my.server.hu ranges=10.0.88.100-10.0.88.200

Szóval a linuxos kliens ebből a pool-ból kellene hogy kapjon címet, és ehhez kellene hogy generáljon policy-t a template-ből. Helyette olyan, mintha a Linuxos gép helyi LAN-on levő címéhez akarna policy-t generálni. De nem tud, mert nincs hozzá template.

Nem annyira vagyok szakértő a témában, de azt hiszem hogy a linuxos kliens 192.168.14.2 címe egyáltalán nem szabadna hogy átkerüljön a VPN szerver oldalra.

0 szavazat

A hozzászóláshoz be kell jelentkezni

Oké megvan a megoldás. Az nm appletben a VPN beállításainál be kell pipálni a "Request an inner IP address" pipát. Ha ez nincs bepipálva, akkor nem kér címet a VPN szervertől. Azt mondjuk nem teljesen értem, hogy miért pont a saját LAN-on levő 192.168.14.2 címre próbált meg kérni traffic-ot (mert hogy van neki másik címe is), de ez végülis nem számít.

Probléma megoldva!

0 szavazat

A hozzászóláshoz be kell jelentkezni

Hát még mindig nem teljesen jó, mert a szerver által push-olt route-ok nem jönnek át. :-(

0 szavazat

A hozzászóláshoz be kell jelentkezni

Nincs a "Use this connection only for resources on its network" kikipálva? (Szerintem be kellene lennie.)

0 szavazat

A hozzászóláshoz be kell jelentkezni

Próbáltam így is meg úgy is. Próbáltam úgy is, hogy az IPv4 fülön a "Method" értéke "Automatikus (VPN)" meg úgy is hogy "Csak automatikus (VPN) címek". Ezek minden kombinációjában, de egyiknél se adja hozzá a route-okat.

Egyébként nekem az se világos, hogy a "Request an inner IP address" pipa miért nincs alapértelmezésben pipálva. Szerintem 99.99%-ban úgy használják az emberek ezt, hogy a VPN szervertől várnak egy címet...

0 szavazat

A hozzászóláshoz be kell jelentkezni

Milyen SA-k jönnek létre?

ipsec statusall

vagy

swanctl --list-sas

mit mutat?

Vagy ha ezek a prancsok nincsenek fenn (nem biztos hogy felkerülnek a Strongswan NM frontend-el,de ezek kimenete egyértelműbb):

ip xfrm policy

Egyébként a strongswan nem a main táblába rakja a routeot.

ip route show table 220

mit mutat?

0 szavazat

A hozzászóláshoz be kell jelentkezni

Milyen SA-k jönnek létre?

root@laci-ryzen:~# ipsec statusall
Status of IKE charon daemon (strongSwan 5.8.2, Linux 5.4.0-58-generic, x86_64):
  uptime: 3 hours, since Dec 23 08:02:30 2020
  malloc: sbrk 2973696, mmap 0, used 835024, free 2138672
  worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 0
  loaded plugins: charon test-vectors ldap pkcs11 tpm aesni aes rc2 sha2 sha1 md5 mgf1 rdrand random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey pem openssl gcrypt af-alg fips-prf gmp curve25519 agent chapoly xcbc cmac hmac ctr ccm gcm ntru drbg curl attr kernel-netlink resolve socket-default connmark stroke updown eap-mschapv2 xauth-generic counters
Listening IP addresses:
  192.168.14.2
  10.0.88.100
  172.18.0.1
  172.17.0.1
Connections:
Security Associations (0 up, 0 connecting):
  none

Ebből szerintem a 172. elejűek a docker-hez tartoznak.

Az swanctl --list-sas nem megy nekem. (Sima userként "agent plugin requires CAP_DAC_OVERRIDE capability", root-ként meg "connecting to 'unix:///var/run/charon.vici' failed: No such file or directory")

ip xfrm policy

Ez jó hosszú...

root@laci-ryzen:~# ip xfrm policy
src 192.168.14.1/32 dst 192.168.14.1/32 
	dir fwd priority 167231 
src 192.168.14.1/32 dst 192.168.14.1/32 
	dir in priority 167231 
src 192.168.14.1/32 dst 192.168.14.1/32 
	dir out priority 167231 
src 10.0.88.100/32 dst 192.168.13.0/24 
	dir out priority 371327 
	tmpl src 192.168.14.2 dst 1.2.3.5
		proto esp spi 0x0c51282e reqid 4 mode tunnel
src 192.168.13.0/24 dst 10.0.88.100/32 
	dir fwd priority 371327 
	tmpl src 1.2.3.5 dst 192.168.14.2
		proto esp reqid 4 mode tunnel
src 192.168.13.0/24 dst 10.0.88.100/32 
	dir in priority 371327 
	tmpl src 1.2.3.5 dst 192.168.14.2
		proto esp reqid 4 mode tunnel
src fe80::/64 dst fe80::/64 
	dir fwd priority 134463 
src fe80::/64 dst fe80::/64 
	dir in priority 134463 
src fe80::/64 dst fe80::/64 
	dir out priority 134463 
src ::1/128 dst ::1/128 
	dir fwd priority 68927 
src ::1/128 dst ::1/128 
	dir in priority 68927 
src ::1/128 dst ::1/128 
	dir out priority 68927 
src 192.168.14.0/24 dst 192.168.14.0/24 
	dir fwd priority 175423 
src 192.168.14.0/24 dst 192.168.14.0/24 
	dir in priority 175423 
src 192.168.14.0/24 dst 192.168.14.0/24 
	dir out priority 175423 
src 172.18.0.0/16 dst 172.18.0.0/16 
	dir fwd priority 183615 
src 172.18.0.0/16 dst 172.18.0.0/16 
	dir in priority 183615 
src 172.18.0.0/16 dst 172.18.0.0/16 
	dir out priority 183615 
src 172.17.0.0/16 dst 172.17.0.0/16 
	dir fwd priority 183615 
src 172.17.0.0/16 dst 172.17.0.0/16 
	dir in priority 183615 
src 172.17.0.0/16 dst 172.17.0.0/16 
	dir out priority 183615 
src 169.254.0.0/16 dst 169.254.0.0/16 
	dir fwd priority 183615 
src 169.254.0.0/16 dst 169.254.0.0/16 
	dir in priority 183615 
src 169.254.0.0/16 dst 169.254.0.0/16 
	dir out priority 183615 
src 0.0.0.0/0 dst 0.0.0.0/0 
	socket in priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
	socket out priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
	socket in priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
	socket out priority 0 
src ::/0 dst ::/0 
	socket in priority 0 
src ::/0 dst ::/0 
	socket out priority 0 
src ::/0 dst ::/0 
	socket in priority 0 
src ::/0 dst ::/0 
	socket out priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
	socket in priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
	socket out priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
	socket in priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
	socket out priority 0 
src ::/0 dst ::/0 
	socket in priority 0 
src ::/0 dst ::/0 
	socket out priority 0 
src ::/0 dst ::/0 
	socket in priority 0 
src ::/0 dst ::/0 
	socket out priority 0 
root@laci-ryzen:~#

Ebben benne vannak ezek:

src 10.0.88.100/32 dst 192.168.13.0/24 
	dir out priority 371327 
	tmpl src 192.168.14.2 dst 1.2.3.5
		proto esp spi 0x0c51282e reqid 4 mode tunnel
src 192.168.13.0/24 dst 10.0.88.100/32 
	dir fwd priority 371327 
	tmpl src 1.2.3.5 dst 192.168.14.2
		proto esp reqid 4 mode tunnel
src 192.168.13.0/24 dst 10.0.88.100/32 
	dir in priority 371327 
	tmpl src 1.2.3.5 dst 192.168.14.2
		proto esp reqid 4 mode tunnel

De ez így még mindig nem kerek. A VPN szerver oldalon ez van a split-include -ban:

/ip ipsec mode-config
add address-pool=vpn.my.server.hu address-prefix-length=32 name="modeconf vpn.my.server.hu" split-include=\
    192.168.13.0/24,10.0.88.0/24 static-dns=10.0.88.1 system-dns=no

Akkor hozzá kellett volna adnia a 10.0.88.0/24 -et is. De csak a 10.0.88.100/32 -őt adta hozzá.

Teszt:

root@laci-ryzen:~# traceroute 192.168.13.254
traceroute to 192.168.13.254 (192.168.13.254), 64 hops max
  1   192.168.13.254  14,185ms  20,292ms  11,750ms 
root@laci-ryzen:~# traceroute 10.0.88.1
traceroute to 10.0.88.1 (10.0.88.1), 64 hops max
  1   192.168.14.1  0,245ms  0,098ms  0,083ms 
  2   * * *
  3   * * *
  4   * * *
  (timeout)

0 szavazat

A hozzászóláshoz be kell jelentkezni

Ez ugye egyben azt is jelenti, hogy a VPN szerver által megadott 10.0.88.1 -en levő DNS szervert se tudom használni.

0 szavazat

A hozzászóláshoz be kell jelentkezni

Na most kipróbáltam azt is, hogy hozzáadtam még néhány kamu route-ot a split-include -hoz a szerveren:

/ip ipsec mode-config
add address-pool=vpn.my.server.hu address-prefix-length=32 name="modeconf vpn.my.server.hu" split-include=\
    192.168.13.0/24,192.168.9.0/24,172.111.0.0/16,10.0.88.0/24 static-dns=10.0.88.1 system-dns=no

Ezután újracsatlakoztam, és az "ip xfrm policy" kimenete az égvilágon semmit nem változott. A következő teszt az volt, hogy más sorrendben adtam őket hozzá:

/ip ipsec mode-config
add address-pool=vpn.my.server.hu address-prefix-length=32 name="modeconf vpn.my.server.hu" split-include=\
    192.168.9.0/24,192.168.13.0/24,172.111.0.0/16,10.0.88.0/24 static-dns=10.0.88.1 system-dns=no

Ennek hatására a policy-ben megjelent a 192.168.9.0, viszont az utána levőek nem. Tehát ez benne van:

src 10.0.88.100/32 dst 192.168.9.0/24 
	dir out priority 371327 
	tmpl src 192.168.14.2 dst 1.2.3.5
		proto esp spi 0x04f1e6b5 reqid 8 mode tunnel
src 192.168.9.0/24 dst 10.0.88.100/32 
	dir fwd priority 371327 
	tmpl src 1.2.3.5 dst 192.168.14.2
		proto esp reqid 8 mode tunnel
src 192.168.9.0/24 dst 10.0.88.100/32 
	dir in priority 371327 
	tmpl src 1.2.3.5 dst 192.168.14.2
		proto esp reqid 8 mode tunnel

De most meg a 192.168.13.0/24 rész hiányzik.

Akkor most már elég jól azonosítva van a probléma: az összes route közül csak a legelsőt adja hozzá.

Az pedig egy tény, hogy a Windows 10-es beépített VPN kliens hozzáadja az összeset, tehát nem a VPN szerverrel van a gond.

Hogyan tovább?

0 szavazat

A hozzászóláshoz be kell jelentkezni

MikroTik VPN IKEv2 + Ubuntu Strongswan nem megy [MAJDNEM MEGOLDVA]

Hozzászólások