pfsense 2.2.X site to site problema

FreeBSD-all

hello,

2.1.X -rol upgrade 2.2.3-ra es elojott, hogy a phase1 lifetime lejartakor szakad a site to site...es csak percekkel kesobb kepes ujra felepulni. A neten sok errol szolo panaszt talaltam, de megoldast egyelore nem. A pfsense egyeb tuzfal applience -ekkel van osszesite-olva.

Koszi!

  • 2497 megtekintés

( szollosiimre | 2015. 07. 11., szo – 09:10 )

Nem a 2.2 ben volt a racoon->strongswan váltás? P1 debug?

Minden tunnel?

De, ott volt. Sajnos valamit nagyon elnyestek, mert a backupból visszatöltött konfiggal sem épült fel egyetlen IPSec kapcsolatom sem. A debug során a következőket sikerült kiderítenem:
- gond van a peer ID-vel: mivel a partner NAT mögött van, most hirtelen probléma lett, hogy az az IP cím, amit várna, nem az, amit a túloldal küld. A peer ID manuális megadásával ez a probléma ugyan orvosolható volt, csak nem szép.
- amikor a partner pfSense helyett MikroTik volt (nem NAT mögül), akkor viszont a Phase2 fel sem épült: nem sikerült egyeztetni a titkosítási paramétereket! Érdekes, mert eddig ment. A debug eredménye: a pfSense nem azt a titkosítást ajánlja fel a túloldalnak, ami a konfigban van! A túloldal átállítása után a Phase2 továbbra sem akart összejönni. Mivel éles rendszeren az embernek véges ideje van kisérletezni, ezért maradt a downgrade... :-(

Mondjuk ezen tapasztalataim már legalább 4 hónaposak, azóta jött ki újabb verzió. Abban lehet, javították már ezt a hibát - ha lesz egy kis időm és lehetőségem, teszek egy próbát vele.

Tegnap éjjel feltettem az aktuálisan legfrissebb 2.2.3 verziót. Eredmények:
- az a Microtik, amivel eddig képtelen volt összefütyülni, elsőre azonnal összejött, sőt most már akkor is felépül a kapcsolat, ha a forgalmat a pfSense generálja. (Korábban a kapcsolat csak a Microtik felől volt felépíthető.)
- a P1 lifetime lejárta előtt kicsivel a kapcsolatok szakadnak - ez annyira nem szerencsés
- a korábban NAT mögött lévő másik három pfSense felé az IPSec kapcsolat nem épül fel. Manuálisan, ha minden kapcsolatot lelövök, majd a NAT mögött lévőket kézből egyesével felélsztem, akkor megy, utána a NAT nélküliek is elindíthatóak - de a P1 lifetime miatti szakadás a kapcsolatot a padlóra küldi és ott is marad, többet nem épül vissza, manuális rugdosásra sem. A túloldali log szerint (ott még 3.1.5 pfSense van, racoon-nal) racoon: [torpicsek]: [aaa.bbb.ccc.ddd] WARNING: remote address mismatched. db=aaa.bbb.ccc.ddd[4500], act=aaa.bbb.ccc.ddd[500] Az megvan, hogy a port nem stimmel, illetve a portok alapján az egyik oldal tolná direktben, a másik meg NAT mögül várná - na de ezt így hogy és miért?

Mondjuk a dolgot tovább árnyalja, hogy az előző teszt az irodai tűzfalon történt, valós IP-vel, az aktuális teszt meg hostingban, NAT mögött...

Az első és az utolsóból nekem valami olyasmi tűnik ki, hogy a friss pfsense nincs tisztában azzal hogy ő kezdeményező, vagy fogadó fél. ( initiator / responder )

https://wiki.strongswan.org/projects/strongswan/wiki/VirtualIp#Responde…

Érdemes lenne még belekukkantani a konfigurációs fájljába, de igazság szerint se az új pfsense-t, se a strongswant nem ismerem. Utóbbit nem is kedvelem.. .

Igazából bármelyik lehet - kezdeményező is, fogadó is.
Alapban, ha nincs forgalom, akkor egy idő után az IPSec bontja a kapcsolatot. Ekkor ha bármelyik telephelyen forgalom akar generálódni a másik telephely felé, ismét fel kell építeni a VPN kapcsolatot. Ekkor a kezdeményező az a telephely lesz, ahol a forgalom generálódik - és ez az előbbiekből adódóan bármely telephely lehet -, a fogadó pedig a másik telephelyen lesz.
A gondom ott kezdődik, hogy jelenleg bármelyik oldalról kezdeményezve a VPN felépítést, a NAT mögötti partnerek esetén pofára esés van.

Viszont ez nem változtat azon, hogy a működő kapcsolatok is P1 lifetime környékén erősen szakadoznak. Ez önmagában is probléma.

Strongswan kapcsán: a racoon-nal nekem is sokkal több sikerélményem van, de sajnos az új pfSense alá ezt gyűrték be.

Nade, a strongswan viszont nem mondja meg a peernek, hogy légyszi ESP-ben küld már. Ez implementációs baki.

2.1.5-be nálam van olyan flag, hogy nat traversal. Szerintem force-ol meg.

Am egy id alapú VPN-ben a responder sosem fog kapcsolatot kezdeményezni, mert pont nem tudja, hogy hol vannak a peerjei. Majd ha beesnek, válaszol. ezért írtam a left-right side problémakört.

Nem szeretem a csak adat esetén beinduló tunneleket. Jó az az interface monitoring.

P1 lifetime környéki gond valóban baki. Egyelőre úgy látom nem érdemes erőltetni a 2.2-őt

Ebben a fórumban még vannak érdekességek:
https://forum.pfsense.org/index.php?topic=87333.0;prev_next=next#new valamint itt pont kifejtik a nat mögötti működés dolgát is.
https://doc.pfsense.org/index.php/IPsec_Troubleshooting#Common_Errors_…

( rts | 2015. 07. 13., h – 11:46 )

Elnézést kérek a destruktív kommentért, de a 2.2* pfsense egy baromi nagy bugbánya, ha véletlenül működött vele valami, akkor ne nyúlj hozzá, istenőrizz frissíteni bármit.. inkább cseréld le.

( FBK | 2015. 07. 13., h – 12:59 )

sajnos +1

2.1.X -ig jol mukodott, sikerult el..ni :-)

--
FBK