IPSEC site-2-site VPN gyakori leállás (opnsense)

Én egy hetet dolgoztam, mire megcsináltam egy ehhez nagyon hasonló IPsec site-to-site csatornát OPNsense és Mikrotik között úgy, hogy mindkettő dinamikus publikus című Digi PPPoE internetre kapcsolódik. Az OPNsense oldal ugyan erős Xeon-on fut, AES-NI-vel menne az OpenVPN gyorsítás, viszont a Mikrotik csak IPsec-et tud HW gyorsítani OpenVPN-t csak CPU-ból, támogatás nélkül, kis sávszélességgel tolja. Így itt a HW korlát miatt kellett az IPsec.

Most sajna nincs időm ide beírni minden lépést és részletet, de a hétvége folyamán szívesen megosztom itt vagy máshol a megoldásom. Az a lényeg, hogy hiába tudja elvileg az OPNsense és a Mikrotik is a dinamikus publikus címen az IPsec-et, a gyakolratban ez úgy igaz, hogy induláskor csinál DNS feloldást, és utána azzal megy örökre (újraindításig), tehát ha közben változik az IP cím, mindkét oldalon tudatni kell az IPsec stack-kel ezta tényt. Mindkét oldalon saját script van eseményhez rendelve ehhez (ezeket is bemásolom majd).

Nekem remekül, hozzányúlás nélkül működik azóta, bármelyik odallal bármi történik, kis idő alatt helyreáll a tunnel. Csak azért írtam be gyorsan, hogy tudd, van megoldás, csak kicsit melós.

Módosítsd úgy mindkét oldalt hogy ne hostnév hanem IP-IP között épüljön ki az ipsec.
Ehhez annyit kell tenned hogy készítesz egy-egy scriptet ami pl. 5 percenként ellenőrzi hogy a másik oldal IP címe, vagy a saját IP publikus cím változott-e.
Ha igen, akkor ipsec-ben módosítja az adott IP címet, és reconnect.Ami fontos, a másik oldal IP címét ne szolgáltatói DNS-ből, hanem a hostnévhez tartozó DNS szervertől kérdezd!
Ilyen 1xű ….

Az én megoldásom elemei:

OPNsense oldal:

Az OPNsense oldal a Mikrotik oldalhoz hasonlóan működik. Cron-nal 5 percenként nézi, hogy él-e az IPsec tunnel, és ha nem, akkor frissít. Viszont az OPNsense oldalon a saját IP cím frissítése szükséges inkább, mert a távoli IP cím dinamikus frissítése jól működik (az OPNsense csak responder, nem kell tudnia a túloldal IP címét előre - tudom, tudom, ez biztonságilag nem a legjobb), de a saját cím változását csak a szolgáltatás újraindítás vagy update esetén frissíti, annak változását nem figyeli folyamatosan, és a régi címet használva pedig nem épül fel a tunnel címváltozás után, hiába próbálkozik a túloldal az új címen csatlakozva.
Ezt úgy valósítottam meg, hogy készült egy script az ellenőrzésre/frissítésre, és készült egy action (OPNsense egyedi dolog), hogy a webfelületen fel lehessen venni a scipt-et a cron-ba (nem kényelmi okokból, hanem azért, hogy frissítéskor és konfig mentéskor is megmaradjon a beállítás). Az action bemásolása után az OPNsense doksiból tudható meg, hogyan látja meg a rendszer az új elemet.

IPsec tunnel beállítások (talán így képként érthetőbb, mintha beírogatom ide soronként, remélem minden egyedi, fontos infót töröltem...): OPNsense IPsec beállítások
Természetesen phase2-ből 3 db van a megfelelő beállításokkal, itt csak az első van kifényképezve.

root@firewall:~ # cat ipsec-test.sh
#! /bin/sh

ping -S 172.16.0.254 -c 3 -t 3 192.168.1.254
res=$?
if [ $res -ne 0 ];
then
  /usr/local/sbin/ipsec update
  echo "VPN disconnected -> IPsec updated"
fi

root@firewall:/usr/local/opnsense/service/conf/actions.d # cat actions_ipsectest.conf
[test]
command:/root/ipsec-test.sh
parameters:%s
type:script
message:Test/update %s IPsec VPN connection
description:Test/update specified IPsec VPN connection

Mikrotik oldal:

A működése egyszerű: netwatch figyeli (1 percenként), hogy a tunnel túloldalán elérhető-e aminek kell. Ha elérhető akkor tiltja, ha nem elérhető, akkor engedélyezi az ütemezőben a frissítő ütemezését.
Az ütemezőben, mikor engedélyezve van, akkor 1 percenként lefuttatja a update script-et. A netwatch és a scheduler beépített szolgáltatások, hatékonyabbak mint egy komplett figyelő script futtatása folyamatosan.
Az update script annyit csinál amikor lefut, hogy próbálja feloldani a megadott FQDN-t, és ha sikerül, és nem egyezik az érvényben lévővel, akkor lecseréli az új címre minden érintett beállításban. Amikor a frissített beállításokkal felállnak a tunnel-ek, akkor a netwatch ezt meglátja, és tiltja a frissítő ütemezett futtatását (amíg a tunnel él).
Ebben a példában három tunnel van ugyanazon publikus címek között felállítva, az én oldalamon 3 különböző IP alhálózatot ér el munkatársam saját otthoni hálózata.

/ip firewall filter
add action=accept chain=input comment=IPsec protocol=ipsec-esp
add action=accept chain=input dst-port=500 protocol=udp
add action=accept chain=input dst-port=4500 protocol=udp
/ip firewall nat
add action=accept chain=srcnat dst-address=192.168.0.0/24 src-address=192.168.1.0/24
add action=accept chain=srcnat dst-address=172.16.0.0/24 src-address=192.168.1.0/24
/ip ipsec profile
add dh-group=modp2048 enc-algorithm=aes-256 hash-algorithm=sha256 lifetime=4h name=MY-profile
/ip ipsec peer
add address=a.b.c.d/32 exchange-mode=ike2 name=MY profile=MY-profile
/ip ipsec proposal
add auth-algorithms=sha256 enc-algorithms=aes-256-cbc name=MY-proposal
/ip ipsec identity
add peer=MY secret=12345678
/ip ipsec policy
add comment=MY-1 dst-address=172.16.0.0/24 level=unique proposal=MY-proposal sa-dst-address=a.b.c.d sa-src-address=0.0.0.0 src-address=192.168.1.0/24 tunnel=yes
add comment=MY-2 dst-address=192.168.0.0/24 level=unique proposal=MY-proposal sa-dst-address=a.b.c.d sa-src-address=0.0.0.0 src-address=192.168.1.0/24 tunnel=yes
add comment=MY-3 dst-address=192.168.254.0/24 level=unique proposal=MY-proposal sa-dst-address=a.b.c.d sa-src-address=0.0.0.0 src-address=192.168.1.0/24 tunnel=yes
/ip route
add comment="MY - LAN" distance=1 dst-address=172.16.0.0/24 gateway=bridge
add comment="MY - DMZ" distance=1 dst-address=192.168.0.0/24 gateway=bridge
add comment="MY - CPNY" distance=1 dst-address=192.168.254.0/24 gateway=bridge
/system scheduler
add disabled=yes interval=1m name=ipsec-peer-update-My on-event="/system script run ipsec-peer-update-MY" policy=read,write start-date=\
    apr/11/2019 start-time=16:56:51
/system script
add dont-require-permissions=no name=ipsec-peer-update-MY owner=admin policy=read,write source="\
      :local peerid \"MY\"\r\
    \n:local peerhost \"fqdn.remote.tld\"\r\
    \n:local peerip [:resolve \$peerhost]\r\
    \n:local peeruid\r\
    \n:set peeruid [/ip ipsec peer find comment=\"\$peerid\" and address!=\"\$peerip/32\"]\r\
    \n:local policy1uid\
    \n\r\
    \n:set policy1uid [/ip ipsec policy find comment=\"\$peerid-1\" and sa-dst-address!=\"\$peerip\"]\r\
    \n:local policy2uid\
    \n\r\
    \n:set policy2uid [/ip ipsec policy find comment=\"\$peerid-2\" and sa-dst-address!=\"\$peerip\"]\r\
    \n:local policy3uid\
    \n\r\
    \n:set policy3uid [/ip ipsec policy find comment=\"\$peerid-3\" and sa-dst-address!=\"\$peerip\"]\r\
    \n:if (\$peeruid != \"\") do={\r\
    \n  /ip ipsec peer set \$peeruid address=\"\$peerip/32\"\r\
    \n  :log info \"Script ipsec-peer-update updated peer '\$peerid' with address '\$peerip'\"}\r\
    \n:if (\$policy1uid != \"\") do={\
    \n\r\
    \n  /ip ipsec policy set \$policy1uid sa-dst-address=\"\$peerip\"\r\
    \n  :log info \"Script ipsec-peer-update updated policy '\$peerid' with address '\$peerip'\"\
    \n}\r\
    \n:if (\$policy2uid != \"\") do={\
    \n\r\
    \n  /ip ipsec policy set \$policy2uid sa-dst-address=\"\$peerip\"\r\
    \n  :log info \"Script ipsec-peer-update updated policy '\$peerid' with address '\$peerip'\"\
    \n}\r\
    \n:if (\$policy3uid != \"\") do={\
    \n\r\
    \n  /ip ipsec policy set \$policy3uid sa-dst-address=\"\$peerip\"\r\
    \n  :log info \"Script ipsec-peer-update updated policy '\$peerid' with address '\$peerip'\"\
    \n}\r\
    \n"
/tool netwatch
add comment=ipsec-peer-update-MY down-script="/system scheduler enable ipsec-peer-update-MY" host=172.16.0.254 up-script="\
    \n/system scheduler disable ipsec-peer-update-MY"
add host=192.168.0.254
add host=192.168.254.254

Ha kérdésed van, vagy kifelejtettem valamit amit nehéz közé kitalálni, akkor szívesen segítek ha tudok. Azt nem teszteltem/néztem meg, hogy az OPNsense fejlődése során megoldódott-e egy a saját IP frissítési dolog. Nem kizárt, hogy most már nem is kellene az OPNsense oldalra semmi (több, mint 1 éve készítettem ezt a megoldást). Sőt, a Mikrotik oldalon sem néztem utána, hogy az idő közben történt fejlesztések után az IKEv2 működése változott-e, sima 0.0.0.0 cél IP-vel és FQDN-el lehet az is frissítene már plusz trükk nélkül.

Ezen felül lehetne kisérletezni a policy/route based IPsec-kel, hogy csak egy tunnel legyen, és azon menjen át a 3 IP subnet forgalma. De "if it ain't broke, don't fix it" :-)

Lehetőségeid:

1) Mindkét oldalra kérsz fix IP-t (havi 2x 2-5e Ft),

2) Csak az egyik oldalra kérsz fix IP-t, és agressive módban kell forgalmaznod,

3) Átállsz OpenVPN-re,

4) Hákolsz tovább, de nem lesz magas rendelkezésre állásod.

Nem vagyok se opnsense, se ipsec szaki, de mi lenne ha csak a tunnelt indítanád újra a komplett ipsec helyett:

/usr/local/bin/ipsec rereadall
/usr/local/bin/ipsec reload
/usr/local/bin/ipsec down <név>
/usr/local/bin/ipsec up <név>

feltételezve hogy az ipsec parancs a /usr/local/bin-ben van.

igaz ez 4 sor nem 2, lassabb, meg minden, ha nem változik a konfig meg a többi dolog (tanusítvány, titkok) akkor az elsö két sor lehagyható.

1 site-2-site esetén nem oszt, nem szoroz a komplett újraindítás, de ha már a három site van lehet hogy csak azt kellene újraindítani ahol változott valami.

innen ollóztam az alábbit: https://forum.opnsense.org/index.php?topic=17350.0

Check Enable

Name: Some name
Type: Remote host
Address: remote_gateway_ip (or some host ip inside remote network responding do pings)
Start:

Code: 

/usr/local/sbin/swanctl -i --child conN(where N is your connection position on the list in VPN/IPSEC/Status Overview, ie con1)
Stop:

Code: 

/usr/local/sbin/swanctl -t --child conN(where N is your connection position on the list in VPN/IPSEC/Status Overview, ie con1)
Tests: Select your test name from p1.
Depends: Nothing depends