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

Van 1-1 db opnsense rúterem 2 site-on. A site-okon internet elérés dinamikus publikus IP-vel van (átkos PPPoE, minden reconnect után új IP-t kap). Azaz pont a legtávolabbi ellentéte az optmális static IP setup-nak, amit az ilyen service-k elvárnának. Dynamic DNS-t használok ezért, ha a rúterre WAN oldalról kell hivatkozni. Ki akartam húzni közöttük egy site-2-site VPN-t.
Valamiért úgy döntöttem, legyen IPSEC alapú a tunnel. Mert hát ugye szabványos az IPSEC, 20 éve van már windowsban beépített kliens, android is tudja out of the box, mi baj lehetne? Openvpn valahogy nem szimpatikus, SSL VPN-t amúgy sem tudja hw-ből gyorsítani szinte semmi, ezek meg gyenge CPU-n futnak.

Megnéztem pár videót YT-on ipsec-ről, mert az opnsense dokumentáció mint olyan nem létezik még ha elsőre azt is hiszed h. igen. Írnak valamit, de az egy nagy 0-t sem ér.

Ez pl. egész jó volt, elhittem neki h. TÉNLYEG érti miről beszél nem csak észnélkül felolvassa a másik által megírt slide-okat:
https://www.youtube.com/watch?v=ikSybz2e2RU

Amúgy dunát lehet rekeszteni az ipsec-ről hablatyoló kontárokból youtube-on, egyik borzasztóbb mint a másik, sok meló kiszűrni a tényleg profi előadókat
Viszont továbbra se biztos hogy minden tiszta ezekről:

ISAKMP, IKEv1, IKEv2, AH, ESP, tunnel mode, transport mode, main mode, aggressive mode, quick mode, Phase1, Phase2, cipher-eknél már opálosodik a szemem h. mi a különbség szimpla-AES-128bit / szimpla-AES-256bit /AES-GCM-128  / AES-CBC-128 között, és amit az egyik OS így hív, azt a másik meg amúgyan hívja, de a közösen beszélt low-level valódi cipher-listabeli megfelelőjét basznak ténylegesen odaírni a sor végére legalább apróbetűvel.

Szóval a tunnelt magát ez alapján csináltam meg:
https://docs.opnsense.org/manual/how-tos/ipsec-s2s.html

Szimpla policy-based ipsec VPN, mert a route-based ipsec VPN-t nem fogtam fel mire is jó nekem, és egyelőre ez a szimpla is elégnek tűnt. Cert helyett PSK-val állítottam be. Eleve trükkös a setup ha hiszel a guide-nak, mert a fenti szamárvezető azt írja, hogy mindkét tunnel endpoint oldalán a távoli network address-t kell megadni. Erre a példákban feszt is a RouterA és RouterB LAN IP-jét írták le: 192.168.1.1/24, 192.168.2.1/24 és nem pedig helyesen a network address-t ami 192.168.1.0/24 ill. 192.168.2.0/24. Nem világos mi a célja a My identifier / Peer identifier soroknak, azt is jól agyonmagyarázza a guide (hát nem!). Mert ha azt is fix-re kellene állítani, akkor adtam a szarnak egy pofont a dinamikus IP setup-ban!

Beállítás után elvileg felépül a tunnel. Aztán 1-2 nap után ledöglik. Többszöri IPSEC service és unbound DNS service restart megoldja. Unbound-ot a DDNS miatt kell restartolni ilyenkor, mert be-cacheli a remote public IP-t 24 órára (TTL override). Ha pedig épp IP-váltás volt a túloldalon, akkor nem fogja lekérdezni az aktuális public IP-t DDNS-en keresztül, mert az unbound local DNS cache-ben még ott van a régi, egy egészségesen nagy TTL-el.
Miután levettem az unobund DNS cache TTL-t 3600sec-re (mindkét oldalon kell, mert az anomália mindkét oldalon jelentkezik a jól ismert okokból), ideig óráig élt a tunnel. Aztán megint volt public IP váltás (vegyesen hol egyik hol másik oldalon), és utána már az unbound restart / cache űrítés sem segített. Akkor meg az IPSEC service restart kellett, látszólag mintha az SA-k beragadtak volna, hiába mutatott közben jó IP-re a DNS. Most itt állok, hogy ha sikerül a távoli opnsense-hez is hozzáférni (azaz fizikailag odamegyek, ugye ha ledöglik a tunnel, meg vagyok lőve a másik site-ról), és tudok ott is restartolni service-t akkor életre kell, ha épp annak az oldalnak volt baja a tunnel felállításakor.

Nem találtam a guide-ban 1 büdös szót sem arról, hogy ilyen dinamikus IP / DDNS felálláson is működőképes ez a Site-2-Site IPSEC tunnel setup? Persze mindenki a static rútolható IP-t szereti az oktatóanyagban, mert azzal van a legkevesebb melója gyorsan túl lehet rajta esni. Avagy minden egyes WAN IP váltáskor ledöglik és úgy is marad amíg a rúteren vki kézzel nem restartol service-eket? Mert ha magától nem tud helyreállni ilyen IP váltások után rövid idővel, akkor ez a megoldás kalap szart sem ér :(

Hozzászólások

É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.

És akkor itt ki a hülye? Az IPSEC maga? Vagy az OPnsense? Vagy a mikrotik-re is kellett script? Csak mert vettem egy Ubiquiti edgerouter X-et is a 3. site-ra, ott pedig bajban leszek mert ötletem sincs azon lehet-e szkriptelni.

Amúgy hálás köszönetem, franc se gondolta volna ennyire körülményes protokoll ez az Ipsec. És akkor a remote access-ig még el se jutottam! Pedig már olvasgatom a windows (10) beépített kliens hardkódolt ciphersuite listáját, ami sehol nem látszik, de ha nem azt állítod be a túloldalon akkor ha falnak mész se épül fel a tunnel. Illetve hogy IKEv1-et vagy IKEv2-t melyik client tud, milyen crypto-val.

Igazából itt (ha szabad ezt mondanom) mi vagyunk a hülyék. Az IPsec alapjában véve ismert fix IP címekre van kitalálva, meg mellé van technológiája "road warrior" kliensek fogadására, amiknek akár dinamikus címük is lehet, és így dinamikusan jön létre a megfelelő peer, stb. Mi meg nem szerver-kliens, hanem telephelyek közötti kapcsolatot gyártunk (ami alapból fix címeket igényelne) úgy, hogy egyik oldalnak sem statikus a címe (plusz a PPPoE miatt még átfutási ideje is van a kapcsolat újra épülésének session bontás után)... Szóval mi használjuk rosszul az egyébként jó eszközt véleményem szerint.

Az IKEv2 ezen (is) javított sokat (abban sokkal jobban működik a nem cím, hanem FQDN alapú kapcsolódás, mert hivatalosan támogatott lett - én is ezt használom a megoldásomban), de az sincs felkészítve a menet közbeni cím változásra. Na persze lehet olyan rövid phase1 és phase2 időket adni, hogy aránylag gyorsan helyreálljon, de az aránytalanul sokszor fogja megszakítani a kapcsolatot, ami akár érezhető lesz az átvitelben is.

Az OpenVPN-nek nem véletlenül a mai napig egyik kiemelt képessége a bármelyik oldalon változó IP cím tűrése, és a Mikrotik közösség nem véletlenül kéri emiatt évek óta, hogy az OpenVPN megvalósítás is tudja használni a sok MT eszközben meglévő HW AES gyorsítást.

Script kérdésedre válaszolva a Mikrotik-re is kell script ugyan arra, amire az OPNsense esetén. Az ugyan úgy nem kezeli ezt a helyzetet jó, ugyan azért amiért az OPNsense is. Az Edgerouter-re pedig a minta alapján Neked kell majd a megoldást szülni (ha lehetséges rá egyáltalán). Én nem szeretem az UBNT router-eket, mert mindenhez képest nagyon macerás (számomra) a konfigurációjuk és rettentő csapnivaló ezen felül a doksija (szintén: szerintem).

Nekünk Mikrotik hEX (RB750Gr3) túloldallal megy 200-220 Mbit az IPsec tunnel-en (a nap bizonyos szakaszaiban, mikor bírja a Digi) az 1000/300-as Digi PPPoE kapcsolatokon.

Disclaimer: Sosem próbáltam minkét oldalon dinamikus IP-vel Ipsec-et.  Road warrior setupoknál legalább a szerver IP fix volt.

De ezek a konfigokat pl próbáltad?

https://www.strongswan.org/testing/testresults/ikev2/dynamic-two-peers

https://www.strongswan.org/testing/testresults/ikev2/dynamic-initiator

 

Az ikev1-et felejtsd el ha minkét oldal támogatja az ikev2-t.

Ha valamihez nem értek, nekem nem fáj beismerni. Network-el műkedvelő szinten foglalkozok, nincs ccie routing szviccsing szekuritim, de sokszor jól jött már hogy ehhez is konyítok. Ha datacenter, vrf, bgp kerül szóba, az mar nem az én asztalom.

Irodalomkutatással sokra nem mentem, az Ipsec guide-ok a fősodratú vonalon csak a public static IP-t tárgyalják, mert az a kényelmes gyors, egyszerűen letudható. Franc se gondolta volna hogy ennyi szívás a dinamikus IP, csak ha már az ember beszerezte az eszközt és beállította. Hagyjam a francba, és inkább openvpn legyen a site2site tunnel? Mobil kliensek (csak android, abból is preferált lenne az app nélkül natív támogatott), road warrior windows 7,8,10 natív ipsec kliens is szopás lesz?

Road Warrior Windows kliensek vs Mikrotik esetén nekem bevállt az SSTP. Kicsit maszírozni kellett azt is, de kliens oldalon nem kellett semmi külső eszközt telepíteni, elég volt egy PS szkript (valamint tanúsítvány telepítés, de vagy AD-val vagy LetsEncrypttel orvosolható volt ez is.).

Telephelyek között meg OpenVPN PC alapú routerekkel, de kis sebességigény esetén még Mikrotikek között is bevállalható az OpenVPN és stabil, úgy is, hogy az egyik oldal szimpla nem üzleti mobilneten csücsül. IPSec nekem csak fix IP-k esetén valamilyen Mikrotikes IPIP csatorna felett jött össze normálisan, pláne, hogy nem is nagyon kell semmit állítani :) 

Mivel a 7-es ROS támogatni fogja (támogatja, 7.1 b2), figyelgetem a WireGuard-ot is.

Pont tegnap láttam, h. kijött a napokban  uqibuity ER X-hez egy masszív update, tele hw offload és IPSEC/VPN fixekkel, nemsokára adok neki esélyt egy másik site-on lerakom, aztán kipróbálom összelőnni ott is a site-2-site IPSEC-et opnsense-el. Sok jóra most már nem számítok :)

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.

Végül most opnsense-n ezt a megoldast betatesztelem pár hétig:

----------------------------------------------

Ping a host inside our main site that is only reachable through ipsec, if it isn't reachable, restart ipsec service (strongswan).

Steps:

Services > Monit > Settings
General Setings:

Set Polling Interval to 120 and Start Delay to 60. This will make monit checks to execute each 2 minutes. Check Enable Monit. -> itt kicsit konzervativabb értékeket választottam, 10 percenként csekkolok, startup delay meg 2 perc

Service Test Settings > Add New
Name: IPSEC_ICMP_MONITOR
Condition: failed ping4 count 5 address 10.x.x.254 -> azaz ha ruterA-n konfigolom a monit rule-t, akkor ruterA LAN IP címe jön ide, NEM a ruterB-jé!!!!!!
Action: Restart

10.x.x.254 is the IP Address of this firewall LAN interface. This will ensure that i'm using a source address that will be able to reach that host inside the IPsec tunnel. Keep in mind that i have a specific SPD rule that will deal with delivering traffic.

Service Settings > Add New
Name: REDIAL_IPSEC
Type: Remote Host
Address: 172.y.y.y -> ha routerA-n konfigolom a monit rule-t, akkor ide routerB LAN IP-je kell !
Start: /usr/local/sbin/configctl ipsec start
Stop: /usr/local/sbin/configctl ipsec stop
Tests: IPSEC_ICMP_MONITOR

172.y.y.y is our main AD server. Could be any host with real importance and that you know will be always up-and-running inside your main site.

Done. No more manual intervention on this host.

-------------------------------------

Volt 2 napja routerA-n WAN IP modosulas, es a tunnel meg mindig up! Ha routetA IP modosulasa utan is eletben marad, akkor felve azt merem majd mondani ez egy mukodo setup. Nyilvan hub-spoke esetben a hub-on restartolgatva a strongswan-t kilovi az osszes tobbi branch site-al is a tunnelt, ez a kovetkező fázisban lesz majd érdekes, ha feláll a ubiquity-vel a siteC is

Szerkesztve: 2020. 11. 25., sze - 15:59

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

Nem nyert. Megvártam míg leszakadt a tunnel menetrend szerint. A távoli oldalaon beállítottam még a múltkor ezt a service restartot. Vissza is állt eddig a tunnel, amíg a távoli oldalnak lehetett a baja. Úgy tűnt most épp a helyi oldalamon akadt meg a dolog, itt még nem állítottam be ugyanazt a ipsec service restart-ot Monit-ban (a strongswanctl módit sem!) szóval tudtam vele jáccani.

Úgy tűnik hogy a RouterA-n a VPN-->IPSEC--> "Status Overview" alatt a "Remote ID"-nél bent ragad az előző IP-je RouterB-nek. Strongctl stop nem is tudja ilyenkor leállítani:

/usr/local/sbin/swanctl -t --child con1
no files found matching '/usr/local/etc/strongswan.opnsense.d/*.conf'
terminate failed: no matching SAs to terminate found

Utána meg a start hiába elindítja, AUTH failed lesz az eredmény:

/usr/local/sbin/swanctl -i --child con1
no files found matching '/usr/local/etc/strongswan.opnsense.d/*.conf'
[IKE] initiating IKE_SA con1[44] to ROUTER-B-PUBLIC-IP
[ENC] generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(REDIR_SUP) ]
[NET] sending packet: from ROUTER-A-PUBLIC-IP[500] to ROUTER-B-PUBLIC-IP[500] (464 bytes)
[NET] received packet: from ROUTER-B-PUBLIC-IP[500] to ROUTER-A-PUBLIC-IP[500] (472 bytes)
[ENC] parsed IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(CHDLESS_SUP) N(MULT_AUTH) ]
[CFG] selected proposal: IKE:AES_CBC_128/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048
[IKE] authentication of 'ROUTER-A-PUBLIC-IP' (myself) with pre-shared key
[IKE] establishing CHILD_SA con1{246}
[ENC] generating IKE_AUTH request 1 [ IDi N(INIT_CONTACT) IDr AUTH N(ESP_TFC_PAD_N) SA TSi TSr N(MOBIKE_SUP) N(ADD_4_ADDR) N(MULT_AUTH) N(EAP_ONLY) N(MSG_ID_SYN_SUP) ]
[NET] sending packet: from ROUTER-A-PUBLIC-IP[4500] to ROUTER-B-PUBLIC-IP[4500] (320 bytes)
[NET] received packet: from ROUTER-B-PUBLIC-IP[4500] to ROUTER-A-PUBLIC-IP[4500] (80 bytes)
[ENC] parsed IKE_AUTH response 1 [ N(AUTH_FAILED) ]
[IKE] received AUTHENTICATION_FAILED notify error
initiate failed: establishing CHILD_SA 'con1' failed

Restartoltam RouterA-n az IPSEC-et, egyből életre kelt a tunnel.

 

Hülye kérdés: a Tunnel setting alatt Phase1-nél: "My identifier" és "Peer identifier" alatt ha mindkét oldalon valami statikus text-et vennék fel (a 2 oldalon megfelelően megcserélve a MY<-->PEER párost), a jelenlegi "My IP address" és "Peer IP address" helyett, azzal nem pont ezt a beragadást küszöbölném ki??