Trable s konfigurací site-to site IPsec tunelu mezi Mikrotikem a Unifi UDM Pro

pelirob

Zdravím,
nenašel by se tu někdo, kdo má funkční site-to-site VPN tunel mezi Mikrotikem (ROS 7.18.2) a UniFi UDM Pro (UniFi OS 4.3.6) a podělil by se o řešení za lahev něčeho dobrého?
Sedím tu nad tím víc než dvě hodiny, postupně jsem prošlapal mnohé slepé uličky a nakonec jsem skončil ve fázi, kdy Unifi sice tvrdí, že VPN je on-line, ale mikrotik píše do logu, že úspěšně proběhla jen fáze 1 a pak už vidím opakovaně chybové hlášky "parsing packet failed, possible cause: wrong password"

Už si nevím rady ani já, ani AI tak hledám někoho chytřejšího.

jcltm

pelirob Mám u jednoho známého propoj na OpenVPN mezi pfSense (server) a UCG-Ultra (klient) a funguje to naprosto bez problému. WG by fungoval IMHO taky. Zkusil bych jedno z toho být tebou.

vaaaasa

Toto nepomuze?
https://pokorak.cz/posts/unifi-mikrotik-s2s-ipsec/

pelirob

vaaaasa Bohužel nepomůže - je to psaný na ROS 7.8 a Network aplikaci v8.5.6.
Aktuálně ROS 7.18.2 a Network 9.4.19. Některé položky menu jsou v aktuálních verzích jinde, nebo nejsou vůbec.

Snažil jsem se k tomu to udělat tak podobné, jak jen to šlo a skončil jsem u toho, že UDM hlásí že tunel je aktivní. Ze sítě za UDM už dokonce dokážu pingnou na výchozí bránu vzdálené sítě v Mikrotiku (ale nikam jinam) a na mikrotiku se v logu neustále opakuje:
ISAKMP-SA established aa.bb.cc.dd[4500]-dd.cc.bb.aa[4500] spi:f9c184e175cf1abd:783a58f7ca7a0cbe
purging ISAKMP-SA aa.bb.cc.dd[4500]<=>dd.cc.bb.aa[4500] spi=428050966c193843:a2b53b6e9e016ea6.
ISAKMP-SA deleted aa.bb.cc.dd[4500]-dd.cc.bb.aa[4500] spi:264fbf7ae2f0bb9b:195b659ac9aed584 rekey:1

Adresa tunelu aa.bb.cc.dd je za NATem, druhá strana dd.cc.bb.aa je naroutovaná až na rozhraní.
Když byl na obou koncích mikrotik, tak to šlapalo úplně v pohodně, nenapadlo mě, že UniFi má tu konfiguraci až zas tak odlišnou.

Alois

Předpokládám, že záměr je, aby Mikrotik hw akceleroval ten tunel a nebrzdil provoz pomalým CPU. S WG ani s OpenVPN to žádnou akceleraci mít nebude a na rychlosti je to sakra poznat.
U té chyby mě napadá, že PSK může mít nějaký nevyhovující znak, který Mikrotik nerozdýchá nebo nějaký špatný pravidlo na firewallu. Případně by mohlo pomoct zapnout na Mikrotiku debug IPSec, aby bylo vidět mnohem víc v rámci toho sestavení spojení.
Jinak předpokládám, že na tom Unifi dělá IPSec Strongswan a ten oproti Mikrotiku není problém provozovat jak s PSK tak s certifikátem.

pelirob

Alois Ne, s rychlostí není problém, Wireguard jede prakticky na rychlosti linky, záměr je propojit transparentně dvě sítě ve dvou loklalitách. A byť je USG Pro docela zajímavý hardware, tak z nějakého neznámého důvodu neumí s Wirguardem site-to-site VPN. S Wireguardem umí být buď VPN server, nebo VPN klient.

jcltm

pelirob No a ono to jako hraje roli? Na tom co má veřejku uděláš server, na tom co nemá klient. Ono je to u WG ošidné, peeři jsou si rovni, ale jde na to pohlížet i jako na OpenVPN trochu, když logicky rozlišíš klienta a server. U OpenVPN je site to site mode taky už obskurní záležitost, transparentní tunel normálně funguje i při spojení klient server. Zkus to nakonfigurovat tak a uvidíš, že to pojede. Spoj si WG tunel, nastav routování + FW a máš to.

pelirob

jcltm Taky mě to napadlo, ale někde mám špunt a nemůžu ho vytáhnout...
Mám funkční WG tunel z UDM na mikrotika (mikrotik dělá server, UDM je v režimu WG klient), z počítačů za UDM se normálně připojím do počítačů za Mikrotikem, funguje ping, RDP, VLC...prostě všechno co mě napadne.
Na Mikrotiku jsem pridal statickou routu, aby se všechno co jde na adresy vnitřní sítě za UDM posílalo přes IP Wireguard tunelu - ale tam neproleze vůbec nic, traceroute z Mikrotika do sítě za UDM hlásí "Destination address required"

jcltm

pelirob Zkoušel bych v nefunkčním směru traceroute postupně jsk jdou adresy po cestě a kde se to zastaví, tam bych hledal problém. Taky jsem s tím bojoval než jsem se naučit dělat site-to-site tunely na konkrétním HW.
Vážně ti to neblokuje někde FW, třeba omylem špatně nastavené pravidlo nebo tak něco? Jak na UDM tak na Mikrotiku bych to zkontroloval.

pelirob

Pokud se bavíme o wireguard tunelu, tak traceroute z Mikrotiku na UDM skončí hned na prvním skoku - "Destination address required", ale z UDM na mikrotika projde cokoliv a kamkoliv (ping, RDP, www, atd.).

jcltm

pelirob Tohle nabízí Google AI, nepomohlo by to jako vodítko? Pokud nemáš správně Allowed IP (dávám když to vyloženě nechci jinak 0.0.0.0/0) tak to nejede.

The error "Destination address required" when using MikroTik WireGuard usually means the device doesn't know where to send the traffic because the Allowed IPs in the peer configuration is incorrect or missing, or because there's no appropriate route for that traffic on the MikroTik router. To fix this, you must ensure the peer's Allowed IPs are configured correctly to include the desired IP addresses and subnets, and that a matching route exists on the router to direct traffic to the WireGuard interface.