Dotaz: VPN IKEv2

[zipi]

Zdravím, řeším VPN IKEv2 postavenou na balíčku StrongSwan -> mám plně funkční přihlašování do VPN pomocí EAPu .. Nyní k problému, snažím se celý provoz z daného klienta nasměřovat do tunelu po připojení do VPN potřebuji řidit kdo kam může z hlavní firewallu. Klient běží na Windows 10. Neřešil někdo už obdobní problém ..?? Též přikládám svůj konfigurační soubor. Děkuji za každou radu .. PS: je to náhrada za L2TP VPN..

config setup

    uniqueids=no

conn %default

    esp = aes256-sha256,aes256-sha1,3des-sha1!
    ike = aes256-sha256-modp2048,aes256-sha1-modp2048,aes128-sha1-modp2048,3des-sha1-modp2048,aes256-sha256-modp1024,aes256-sha1-modp1024,aes128-sha1-modp1024,3des-sha1-modp1024!

    dpdaction=clear
    dpddelay=35s
    dpdtimeout=2000s

    keyexchange=ikev2
    auto=add
    rekey=no
    reauth=no
    fragmentation=yes
    compress=yes

    leftcert=fullchain.pem
    leftsendcert=always
    leftsubnet=0.0.0.0/0
    leftfirewall=yes

    eap_identity=%identity
    rightsourceip=192.168.10.0/24 ## nejde použít parametr 0.0.0.0/0

    leftdns = 192.168.10.1
    rightdns = 192.168.10.1

conn ikev2-mschapv2
    rightauth=eap-mschapv2
    leftid=vpn.dserver.cz

conn ikev2-mschapv2-apple
    rightauth=eap-mschapv2
    leftid=vpn.dserver.cz

---

---

Odpovědi

[NN]

Pochopil jsem dobre, ze na Win10 potrebujes nasmerovat cely provoz do VPN?

[zipi]

ano chápeš to správně ..

[NN]

Dobre, muzes dodat log sestaveni tunelu? Jak to vypada na klientovi po sestaveni?

[Kriegel]

Řešil jsem opačnou situaci (tedy jen specifické routy přes VPN) na W8.1 -- tam to bylo defaultně routováno vše přes VPN, u W10 je to údajně vypnuto -- bylo na to zaškrtávátko v nastavení -- "use default gateway on remote network" v nastavení IP toho VPN připojení (dostupné jen z control panelu - network connections); jinak se to dalo rozbourat i ručně modifikací routovací tabulky přes netsh

Podle strongswan dokumentace je další možnost push routy přes DHCP options -- tyto routy údajně Windows neignorují... to jsem ale neřešil, byl to můj stroj, nepotřeboval jsem žádné centralizované bezpečnostní nemodifikovatelné řešení.

[Max]

Řešil jsem také split tunneling. Ve win jde defaultně vše přes VPN. Osobně to mám rozjeté všude (win7-10, Win mobile 8.1 - 10, Android, iPhone) jako split, nakonec i ve win a bez dhcp. To mi tenkrát nešlo, možná proto, že jsem byl v mezičase, kdy se z linux implementace vyhodilo pluto s virtuálním vpn interface. Je na čase se na to podívat znovu.
Zdar Max

[zipi]

Max, jsi ochoten nasdílet konfiguraci ..? Právě, že ve WIN10 nejede defaultne vše přeš VPN musel jsem upravit ve WIN na interface VPN metric, aby to všechno posílalo do daného tunelu .. JInak to Win úspešně ignorovalo.

[zipi]

Zdravím, neřešil někdo z Vás obdobní problém na straně Windows "Přihlašovací údaje pro ověření výměnu klíčů po internetu jsou nepřijatelné" :(

[Max]

Log na straně serveru ti více napoví.
Každopádně pokud používáš ověřování certifikátu serveru + login a pw uživatele, tak musíš mít v klientském PC nainstalován kořenový cert, kterým je podepsán ten server.
Každopádně toto značí nějaký problém při tom první ověření serveru, že to ještě nedojde k loginu a heslu, aspoň myslím.
Zdar Max

[zipi]

právě, že log nic moc neřekne :( Jabko, třeba na první dobrou se připojí.

May 25 15:31:48 16[IKE] ikev2-vpn|16 initiating EAP_IDENTITY method (id 0x00)
May 25 15:31:48 16[IKE] ikev2-vpn|16 peer supports MOBIKE
May 25 15:31:48 16[IKE] ikev2-vpn|16 authentication of 'vpn.xxx.com' (myself) with RSA signature successful
May 25 15:31:48 16[IKE] ikev2-vpn|16 sending end entity cert "CN=vpn.xxx.com"
May 25 15:31:48 16[ENC] ikev2-vpn|16 generating IKE_AUTH response 1 [ IDr CERT AUTH EAP/REQ/ID ]
May 25 15:31:48 16[ENC] ikev2-vpn|16 splitting IKE message (1696 bytes) into 2 fragments
May 25 15:31:48 16[ENC] ikev2-vpn|16 generating IKE_AUTH response 1 [ EF(1/2) ]
May 25 15:31:48 16[ENC] ikev2-vpn|16 generating IKE_AUTH response 1 [ EF(2/2) ]
May 25 15:31:48 16[NET] ikev2-vpn|16 sending packet: from xxx.xxxx.xxx.xxx[4500] to xxx.xxxx.xxx.xxx[4500] (1236 bytes)
May 25 15:31:48 16[NET] ikev2-vpn|16 sending packet: from xxx.xxxx.xxx.xxx[4500] to xxx.xxxx.xxx.xxx[4500] (532 bytes)
May 25 15:32:04 07[JOB] ikev2-vpn|16 deleting half open IKE_SA with xxx.xxxx.xxx.xxx after timeout
May 25 15:32:12 14[JOB] ikev2-vpn|15 deleting half open IKE_SA with xxx.xxxx.xxx.xxx after timeout
May 25 15:32:18 16[JOB] ikev2-vpn|16 deleting half open IKE_SA with xxx.xxxx.xxx.xxx after timeout

[Max]

Tohle jsem řešil teď nedávno. Máš tam timeouty, tj. jedna strana nevidí na druhou. Může to být i chybně nastaveným natem.
Zdar Max

[zipi]

Aspoň, vím, že to má nějaké řešení - jsi ochoten se podělit o řešení .? Vyzkoušel jsem snad dneska všechno a bez výsledku ..

[zipi]

Ještě přikládám strongswan.conf.

charon {

       # duplicheck.enable = no
       dns1 = 8.8.8.8

       # for Windows only
       nbns1 = 8.8.8.8

  plugins {
    eap-tls {
      fragment_size = 512
    }
  }


    filelog {
        charon {
            path = /var/log/strongswan.log
            time_format = %b %e %T
            ike_name = yes
            append = yes
            default = 1
            flush_line = yes
        }
        stderr {
            ike = 2
            knl = 3
        }
    }

    load_modular = yes
    compress = yes
    plugins {
        include strongswan.d/charon/*.conf

   }
}

include strongswan.d/*.conf
~                              

[zipi]

Celý problem je v tom, že win pracuje jinak s certifikáty :( /etc/strongswan/ipsec.d/cacerts/ -> zde museji být komplet certifikáty - certifikační autorita

However, instead of self-generating my own certificate authority and having to deal with manually trusting this untrusted CA on every device I have to use VPN on, I decided that since I had letsencrypt in standalone mode set up on my server already (and the vpn subdomain properly covered under the certificate), I might as well use that certificate instead. I’m sure I’m committing half a dozen security sins, but it saves me time that I used to spend googling “how to trust certificate authority on [device name]”.