Stabil VPN szerver (pfSense ?)

Hello,

Adott két VPS. Az egyiken fut egy Windows Server 2022, amit a felhasználóknak el kellene érnie RDP-vel. (Két külön helyről, fix ip-vel nem rendelkeznek). Az RDP elérést nem fogom publikussá tenni ezért gondoltam teszek elé egy tűzfalat, rá egy VPN szervert és mindenki boldog lesz.

Feltelepítettem a pfSense-t (2.7.2) és nekiláttam egy L2TP+IPSEC szervert felhúzni rá. Azóta eltelt két nap és nem sokat léptem előre pedig nem ez az első amit összeraktam. Pont két napos pfSense tapasztalatom van, de elvileg egy csimpánz is összerakja leírások és videók alapján. Picit elkeserítő, hogy kb. mindenhol azt írják, hogy NAT mögött vagy megy vagy nem. Hát nálam nem.

Amúgy nem feltétlenül ragaszkodom a pfSense-hez, de a megoldásnak szoftveresnek kell lennie illetve lehetőleg ne kelljen hozzá 3rd party kliens. Köszönöm előre is a javaslatokat!

Jan 16 20:44:47	charon	10167	13[IKE] <con-mobile|38> received retransmit of request with ID 1, but no response to retransmit
Jan 16 20:44:47	charon	10167	13[NET] <con-mobile|38> received packet: from 82.1.2.3[4500] to zzz.yyy.hhh.aaa[4500] (444 bytes)
Jan 16 20:44:32	charon	10167	13[IKE] <con-mobile|38> received retransmit of request with ID 1, but no response to retransmit
Jan 16 20:44:32	charon	10167	13[NET] <con-mobile|38> received packet: from 82.1.2.3[4500] to zzz.yyy.hhh.aaa[4500] (444 bytes)
Jan 16 20:44:25	charon	10167	13[IKE] <con-mobile|38> received retransmit of request with ID 1, but no response to retransmit
Jan 16 20:44:25	charon	10167	13[NET] <con-mobile|38> received packet: from 82.1.2.3[4500] to zzz.yyy.hhh.aaa[4500] (444 bytes)
Jan 16 20:44:22	charon	10167	08[IKE] <con-mobile|38> received retransmit of request with ID 1, but no response to retransmit
Jan 16 20:44:22	charon	10167	08[NET] <con-mobile|38> received packet: from 82.1.2.3[4500] to zzz.yyy.hhh.aaa[4500] (444 bytes)
Jan 16 20:44:21	charon	10167	08[IKE] <con-mobile|38> received retransmit of request with ID 1, but no response to retransmit
Jan 16 20:44:21	charon	10167	08[NET] <con-mobile|38> received packet: from 82.1.2.3[4500] to zzz.yyy.hhh.aaa[4500] (444 bytes)
Jan 16 20:44:20	charon	10167	08[IKE] <con-mobile|38> nothing to initiate
Jan 16 20:44:20	charon	10167	08[IKE] <con-mobile|38> activating new tasks
Jan 16 20:44:20	charon	10167	08[NET] <con-mobile|38> sending packet: from zzz.yyy.hhh.aaa[4500] to 82.1.2.3[4500] (76 bytes)
Jan 16 20:44:20	charon	10167	08[ENC] <con-mobile|38> generating INFORMATIONAL_V1 request 147335877 [ HASH N(INVAL_ID) ]
Jan 16 20:44:20	charon	10167	08[IKE] <con-mobile|38> activating INFORMATIONAL task
Jan 16 20:44:20	charon	10167	08[IKE] <con-mobile|38> activating new tasks
Jan 16 20:44:20	charon	10167	08[IKE] <con-mobile|38> queueing INFORMATIONAL task
Jan 16 20:44:20	charon	10167	08[IKE] <con-mobile|38> no matching CHILD_SA config found for 82.1.2.3/32|/0[udp/l2f] === zzz.yyy.hhh.aaa/32|/0[udp/l2f]
Jan 16 20:44:20	charon	10167	08[CFG] <con-mobile|38> dynamic
Jan 16 20:44:20	charon	10167	08[CFG] <con-mobile|38> proposing traffic selectors for other:
Jan 16 20:44:20	charon	10167	08[CFG] <con-mobile|38> zzz.yyy.hhh.aaa/32|/0
Jan 16 20:44:20	charon	10167	08[CFG] <con-mobile|38> proposing traffic selectors for us:
Jan 16 20:44:20	charon	10167	08[CFG] <con-mobile|38> looking for a child config for zzz.yyy.hhh.aaa/32|/0[udp/l2f] === 82.1.2.3/32|/0[udp/l2f]
Jan 16 20:44:20	charon	10167	08[IKE] <con-mobile|38> changing received traffic selectors 192.168.1.73/32|/0[udp/l2f]=== zzz.yyy.hhh.aaa/32|/0[udp/l2f] due to NAT
Jan 16 20:44:20	charon	10167	08[ENC] <con-mobile|38> parsed QUICK_MODE request 1 [ HASH SA No ID ID NAT-OA NAT-OA ]
Jan 16 20:44:20	charon	10167	08[NET] <con-mobile|38> received packet: from 82.1.2.3[4500] to zzz.yyy.hhh.aaa[4500] (444 bytes)
Jan 16 20:44:20	charon	10167	13[NET] <con-mobile|38> sending packet: from zzz.yyy.hhh.aaa[4500] to 82.1.2.3[4500] (76 bytes)
Jan 16 20:44:20	charon	10167	13[ENC] <con-mobile|38> generating ID_PROT response 0 [ ID HASH ]
Jan 16 20:44:20	charon	10167	13[IKE] <con-mobile|38> DPD not supported by peer, disabled
Jan 16 20:44:20	charon	10167	13[IKE] <con-mobile|38> maximum IKE_SA lifetime 28431s
Jan 16 20:44:20	charon	10167	13[IKE] <con-mobile|38> scheduling rekeying in 25551s
Jan 16 20:44:20	charon	10167	13[IKE] <con-mobile|38> IKE_SA con-mobile[38] state change: CONNECTING => ESTABLISHED
Jan 16 20:44:20	charon	10167	13[IKE] <con-mobile|38> IKE_SA con-mobile[38] established between zzz.yyy.hhh.aaa[zzz.yyy.hhh.aaa]...82.1.2.3[192.168.1.73]
Jan 16 20:44:20	charon	10167	13[CFG] <38> selected peer config "con-mobile"
Jan 16 20:44:20	charon	10167	13[CFG] <38> candidate "con-mobile", match: 1/1/24 (me/other/ike)
Jan 16 20:44:20	charon	10167	13[CFG] <38> looking for pre-shared key peer configs matching zzz.yyy.hhh.aaa...82.1.2.3[192.168.1.73]
Jan 16 20:44:20	charon	10167	13[IKE] <38> remote endpoint changed from 82.1.2.3[500] to 82.1.2.3[4500]
Jan 16 20:44:20	charon	10167	13[IKE] <38> local endpoint changed from zzz.yyy.hhh.aaa[500] to zzz.yyy.hhh.aaa[4500]
Jan 16 20:44:20	charon	10167	13[ENC] <38> parsed ID_PROT request 0 [ ID HASH ]
Jan 16 20:44:20	charon	10167	13[NET] <38> received packet: from 82.1.2.3[4500] to zzz.yyy.hhh.aaa[4500] (76 bytes)
Jan 16 20:44:20	charon	10167	13[NET] <38> sending packet: from zzz.yyy.hhh.aaa[500] to 82.1.2.3[500] (372 bytes)
Jan 16 20:44:20	charon	10167	13[ENC] <38> generating ID_PROT response 0 [ KE No NAT-D NAT-D ]
Jan 16 20:44:20	charon	10167	13[CFG] <38> candidate "con-mobile", match: 1/1/24 (me/other/ike)
Jan 16 20:44:20	charon	10167	13[IKE] <38> remote host is behind NAT
Jan 16 20:44:20	charon	10167	13[ENC] <38> parsed ID_PROT request 0 [ KE No NAT-D NAT-D ]
Jan 16 20:44:20	charon	10167	13[NET] <38> received packet: from 82.1.2.3[500] to zzz.yyy.hhh.aaa[500] (388 bytes)
Jan 16 20:44:20	charon	10167	13[NET] <38> sending packet: from zzz.yyy.hhh.aaa[500] to 82.1.2.3[500] (160 bytes)
Jan 16 20:44:20	charon	10167	13[ENC] <38> generating ID_PROT response 0 [ SA V V V V ]
Jan 16 20:44:20	charon	10167	13[IKE] <38> sending NAT-T (RFC 3947) vendor ID
Jan 16 20:44:20	charon	10167	13[IKE] <38> sending FRAGMENTATION vendor ID
Jan 16 20:44:20	charon	10167	13[IKE] <38> sending DPD vendor ID
Jan 16 20:44:20	charon	10167	13[IKE] <38> sending XAuth vendor ID
Jan 16 20:44:20	charon	10167	13[CFG] <38> selected proposal: IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048
Jan 16 20:44:20	charon	10167	13[CFG] <38> configured proposals: IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048
Jan 16 20:44:20	charon	10167	13[CFG] <38> received proposals: IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/ECP_384, IKE:AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/ECP_256, IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048, IKE:3DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048, IKE:3DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MaODP_1024
Jan 16 20:44:20	charon	10167	13[CFG] <38> proposal matches
Jan 16 20:44:20	charon	10167	13[CFG] <38> selecting proposal:
Jan 16 20:44:20	charon	10167	13[CFG] <38> no acceptable ENCRYPTION_ALGORITHM found
Jan 16 20:44:20	charon	10167	13[CFG] <38> selecting proposal:
Jan 16 20:44:20	charon	10167	13[CFG] <38> no acceptable KEY_EXCHANGE_METHOD found
Jan 16 20:44:20	charon	10167	13[CFG] <38> selecting proposal:
Jan 16 20:44:20	charon	10167	13[IKE] <38> IKE_SA (unnamed)[38] state change: CREATED => CONNECTING
Jan 16 20:44:20	charon	10167	13[IKE] <38> 82.1.2.3 is initiating a Main Mode IKE_SA
Jan 16 20:44:20	charon	10167	13[ENC] <38> received unknown vendor ID: e3:a5:96:6a:76:37:9f:e7:07:22:82:31:e5:ce:86:52
Jan 16 20:44:20	charon	10167	13[ENC] <38> received unknown vendor ID: 26:24:4d:38:ed:db:61:b3:17:2a:36:e3:d0:cf:b8:19
Jan 16 20:44:20	charon	10167	13[ENC] <38> received unknown vendor ID: fb:1d:e3:cd:f3:41:b7:ea:16:b7:e5:be:08:55:f1:20
Jan 16 20:44:20	charon	10167	13[IKE] <38> received FRAGMENTATION vendor ID
Jan 16 20:44:20	charon	10167	13[IKE] <38> received draft-ietf-ipsec-nat-t-ike-02\n vendor ID
Jan 16 20:44:20	charon	10167	13[IKE] <38> received NAT-T (RFC 3947) vendor ID
Jan 16 20:44:20	charon	10167	13[IKE] <38> received MS NT5 ISAKMPOAKLEY vendor ID
Jan 16 20:44:20	charon	10167	13[ENC] <38> received unknown vendor ID: 01:52:8b:bb:c0:06:96:12:18:49:ab:9a:1c:5b:2a:51:00:00:00:01
Jan 16 20:44:20	charon	10167	13[IKE] <38> remote endpoint changed from 0.0.0.0 to 82.1.2.3[500]
Jan 16 20:44:20	charon	10167	13[IKE] <38> local endpoint changed from 0.0.0.0[500] to zzz.yyy.hhh.aaa[500]
Jan 16 20:44:20	charon	10167	13[CFG] <38> found matching ike config: 0.0.0.0/0, ::/0...0.0.0.0/0, ::/0 with prio 24
Jan 16 20:44:20	charon	10167	13[CFG] <38> candidate: 0.0.0.0/0, ::/0...0.0.0.0/0, ::/0, prio 24
Jan 16 20:44:20	charon	10167	13[CFG] <38> looking for an IKEv1 config for zzz.yyy.hhh.aaa...82.1.2.3
Jan 16 20:44:20	charon	10167	13[ENC] <38> parsed ID_PROT request 0 [ SA V V V V V V V V ]
Jan 16 20:44:20	charon	10167	13[NET] <38> received packet: from 82.1.2.3[500] to zzz.yyy.hhh.aaa[500] (408 bytes)

Hozzászólások

Szerkesztve: 2024. 01. 16., k – 21:27

" ne kelljen hozzá 3rd party kliens"

 

ha ezt nem mondtad volna, akkor ravagtam volna, hogy tailscale :)

 

https://tailscale.com/

 

Ezzel igazabol nem kellene a Pfsense sem, mehet direktben a winre.

 

Ha rakaszkodsz a "clientless" felepiteshez, akkor miert nem allitasz be a winserver-re egy SSTP servert? (gondolom a kliensek is windowsok). Az a legfajdalommentesebb, megy barmilyen korlatozott halozatbol, (443-as port kell csak neki)

 

https://www.infrastructureheroes.org/microsoft-infrastructure/microsoft…

Szerkesztve: 2024. 01. 16., k – 21:55

Amúgy akár engedélyezhetned az RDS t is. Két user free a winserver en

RDS el nem biztos h free... Lehet csak rdp. Nem vágom annyira a licenszet.

Nem rossz persze, meg ugye megis az PFsense csak tuzfal... De mondjuk ha tenyleg csak RDP eleres kell neki a winserverhez, semmi mas, akkor ez igy elegge agyuval verebre...

Annyi opcio van, pl a fentebb irt RD gateway ami HTTPS-be csomagolja az RDP-t, vagy RDP over SSH (OpenSSH for Windows mar szolgaltatas is. Ehhez mondjuk kell egy putty, vagy van ilyen kulturaltabb progi is https://github.com/micahmo/RDPoverSSH)....

Esetleg csinalsz a usereknek egy egyszeru powershell scriptet, pl:

 

Get-WindowsCapability -Online | ? Name -like 'OpenSSH'
Start-Process -NoNewWindow -FilePath ssh -ArgumentList '-N -L 4567:server_local_ip:3389 -i public_key -p 22 user@firewall_public_ip'
start mstsc /v:localhost:4567

elmented mondjuk "tavoli_gep.ps1" neven es megmondod h ezzel kell kapcsolodni.

Az elso sort igazabol csak egyszer kell a usernel futtatni. igy nem kell semmi kulso progi, nem kell vpn. Faek egyszeru az egesz. szamara olyan lesz, mint egy sima RDP.

Két okot mondok. Az egyik, hogy nem érezném magam biztonságban, ha a Win server-t közvetlenül el lehetne érni. (Itt most mindegy, hogy ez egy VPN szerver vagy RDP). Ez inkább csak érzés. A másik, hogy a tűzfalnak lesz rövidesen más szerepe is nem csak ez az 1 db port forward.

Nem vettem meg, benne van a VPS díjában :). Az ötletet minden esetre köszönöm!

A community edition ez nem található meg, így nehezen lesz használható

Én is "tűzfalat" raknák a Win szerver elé. A probléma az, hogy ezek a disztribúciók (pl. OPNSense) nem támogatják az "egyszerű" kliens VPN megoldásokat. 

Én inkább egy sima linux-ra feltelepítenék egy SSTP servert (Softether talán) és azon keresztül oldanám meg a megosztást.

Közben haladok azért a dologgal. WireGuard-nak adtam egy esélyt (ellentmondván magamnak :) ). Szépen működik. Egy hiányosságot látok talán. Ha a tunel aktív (márpedig az kb. mindig), akkor bárki odaül a géphez az mindenféle külön authentikáció nélkül látja a másik oldalt. Ez még nem azt jelenti, hogy be is tud jelentkezni RDP-n keresztül, de láthat(hat)ja a másik hálózatot.Tudom, paranoid.

IKE2 még hátravan, a PS tunel-es megoldás megy remekül. 

Tailscale-t probald meg ki! (van pfsense plugin hozza). Ahhoz van tok jo ACL, amivel lekorlatozhatod, mit lasson a tobbi halozatbol/portbol.

 

https://www.netgate.com/blog/tailscale-on-pfsense-software

 

https://tailscale.com/kb/1018/acls

 

Amugy sima wireguardal ha jol allitod be a subnet routingot (pl csak a wines gep IP-jet ereszted at) Akkor nem ernek el mast, csak azt. PFsense-en meg szurod 3389 portra. (tuzfal erre (is) van). Vagy Pfsense-en szurod IP/Portra is :) a lehetoseg vegtelen :)

Ezt nem értem. Ha bármelyik (ipsec, openvpn, bármi) VPN tunel aktív, akkor látni fogod a másik gépet. Vagy valami olyasmit szeretnél, hogy az RDP kapcsolódás triggerelje a VPN kapcsolódást, a bontása pedig bontsa azt is?

Amúgy én hasonló megoldásnak ipsec/ikev2 VPN-t csináltam már pár helyre strongswannal, kulcsos auth-al, nem azt mondom, hogy faék egyszerű, de azért nem olyan bonyolult, és ezer leírás van hozzá neten. PSK-val meg még egyszerűbb. Az ipsec/ikev2 meg tényleg megy mindenféle OS-en kliens telepítgetés nélkül. Na jó, androidra kellett a stronswan app, bár elvileg anélkül is fel lehet valahogy éleszteni.

Ezt nem értem. Ha bármelyik (ipsec, openvpn, bármi) VPN tunel aktív, akkor látni fogod a másik gépet. Vagy valami olyasmit szeretnél, hogy az RDP kapcsolódás triggerelje a VPN kapcsolódást, a bontása pedig bontsa azt is?

Nem zavar, hogy folyamatosan megy. Az inkább, hogy anélkül épül fel, hogy a user azt kezdeményezné illetve ebben az esetben nincs user/pass auth "csak" a kulcspárok ellenőrzése alapján történik meg a csatlakozás. Tegyük fel, h Marika elmegy kávézni és a gépét nem zárolja. Jucika erre odasettenkedik és ügyesen rákattint az RDP ikonra (ahol ugye  a  user/pass-t már megjegyeztette Marika) és vidáman nézheti a szenzitív adatokat. 

Amúgy a kérdésedre válaszolva igen, lehet h a triggerelés és bontás jobb lenne, de ez egyenlőre csak paranoia. Örülök, ha ez a jelenlegi formában működik majd stabilan.

 Az ipsec/ikev2 meg tényleg megy mindenféle OS-en kliens telepítgetés nélkül

Egyenlőre nem volt időm/energiám mindent végigrágni, de annak örülnék talán a legjobban, ha ez a megoldás nálam is működne OOTB. Mivel jövő hét elejére élesbe fordul a rendszer ezért egyenlőre maradok a WireGuard-nál. Az IKE2-t meg végigjárom, mert arra is szükségem lesz úgy érzem.

a gépét nem zárolja

Itt van a kutya elásva. Gondolom a jelszavakat sem menti el Marika sehol, tehát csak a VPN-nel lehet visszaélni.

Amikor utoljára multinál dolgoztam, ott az volt a móka, hogy ha otthagytad a gépedet, a kollégák máris odaültek, küldték a nevedben mindenki@-nek hogy "buzi vagyok, most már nem félek kimondani", és még ez volt a legenyhébb üzenet.

Azonkívül, hogy a fél irodaház röhögött amikor visszaértél, rögtön a szőnyeg szélén állás után ülhettél főni elé, meghallgatni az adatvédelmi szabályzat megfelelő passzusát, és csinálhattál mindenféle tréninget mégegyszer.

Plussz a vicceskedő kollégát a hr akár ki is baszhatta, ha éppen olyan (rossz)kedvükben voltak. Mert az illető elkövető egy akármelyik multinál is aláírt legalább egy tucat olyan orra elé tolt felelősségvállalós papírt, amik alapján ez főbenjáró büntettnek számít, és AKÁR kirúgás is lehet belőle.

Aztán persze ha a főnöke rögvest bevédi és amúgy normális hétköznapokon egy jómunkásember, akkor nincs tényleges azonnali kirúgás. Csak lebasszák őt is, és büntetésül elküldik hasonló tréningeket végigülni mint a vicceskedés áldozatának kell.

Minél nagyobb multi, minél angolszászabb kontrollal, minél frusztráltabb arrogánsabb hr-rel, annál nagyobb az esélye a kirúgásra. Ha nem vagy pótolhatatlan melós, akkor belefért nekik ennyi h. másnak legközelebb eszébe se jusson buziskodós leveleket körbeküldeni, ha a céges image a buziskodás promótálása amúgy heti-kétheti hírlevelekben (a példa valós, nem kitalált).

Amelyik nagy multinak idehaza a tv-s reklámjai határeset lmbtq-s buzigyanús arcokkal van teletömve, ott elhiheted h. alkalmazottként ehhez jó pofát kell vágnod, különben ebben a kérdésben nem lesz pardon, és akármilyen indokkal is kerültél ilyen témában a hr célkeresztjébe, sehogyan nem fogod tudni kimagyarázni amit tettél.

Az RDP ha megfelelően van beállítva és rendszeresen frissítve, akár netre is kitehető. Ha fel is törik, azt csak user/jelszó ismeretében tudják megtenni.

Ezt a biztonsági szintet kombinálva a belső hálózattal én nem félnék annyira.

Pl. Azure-ban a windows gépek publikus ip-n keresztül rdp-n elérhetőek...

Sima IPSec - IKEv2 egy fokkal könnyebb lehet. Ahol be szokott szopódni az a kliens által támogatott cypher eltalálása phase 1 és 2-nél (ahány OS annyi lehetőség), viszont ha az megvan akkor baromi gyorsan felépül és stabil a kapcsolat. Felteszem megtaláltad, hogy Phase 2-nél meg tudod mondani hogy melyik subnet(ek)et hirdeted pf oldalról.
OpenVPN is vállalható, ott viszont a usereknek is külön kell OVPN klienst telepíteni. Cserébe pf legyártja a kliens konfigot ami régen azért problémásabb volt.

Asszem most pont itt tartok.

Jan 18 14:43:06	charon	8853	15[CFG] <33> no acceptable INTEGRITY_ALGORITHM found
Jan 18 14:43:06	charon	8853	15[CFG] <33> selecting proposal:
Jan 18 14:43:06	charon	8853	15[CFG] <33> no acceptable KEY_EXCHANGE_METHOD found

Igen, a subnet kiosztással nem lesz gond. Ha egyszer eljutok a PHASE2-ig :(.

OpenVPN-t nem akarok (körülményesnek és lassúnak érzem). 

Kliens oldalról verbose-old meg, kellene hogy írja hogy a kliens mit ajánl. Pf oldalról pedig ipsec/advanced settingsben az IKE loggolásokat billentsd át Diag-ra
Ha esetleg sietős akkor pf oldalról az IPsec Tunnelek:

P1 protocol - P1 Transforms - P1 DH-Group 
AES (256 bits) - SHA256 - 14 (2048 bit)
AES256-GCM (128 bits) - SHA256 - 14 (2048 bit)
AES (256 bits) - SHA256 - 2 (1024 bit)

Ez a legtöbb winfos/alma/linux (asszem androidot + szifont is) klienst lefedi, bár klienseken is kellhet kalapálni.
Winfos kliens oldalról a vpn konfig PS-ben (pf CA certtel):

Remove-VpnConnection -Name "ipszekvépéen" -EV Err -EA SilentlyContinue
Import-Certificate -FilePath "~/Downloads/****.crt" -CertStoreLocation Cert:\LocalMachine\Root\
Add-VpnConnection -Name "ipszekvépéen" -ServerAddress **gateway wan IP** -TunnelType "Ikev2" -SplitTunneling
### ha kell split tunnel kliensre ### Set-VpnConnection -Name "ipszekvépéen" -SplitTunneling $true
Add-VpnConnectionRoute -ConnectionName "ipszekvépéen" -DestinationPrefix **gateway wan IP**
Set-VpnConnectionIPsecConfiguration -ConnectionName "ipszekvépéen" -AuthenticationTransformConstants SHA256128 -CipherTransformConstants AES256 -DHGroup Group14 -EncryptionMethod AES256 -IntegrityCheckMethod SHA256 -PfsGroup PFS2048 -Force

Kibogoztam a leírtak alapján a protokollokat. Működik cert-el. Köszönöm a PS scriptet is! 

Egy problémám van még, ami fura. Ha felépül a kapcsolat, akkor a pfSense admin felületét nem lehet elérni. Valószínüleg routing vagy tűzfal probléma, de nem jövök rá miért nem megy.

Nem kliens oldali probléma. Másik gépről sem megy a WebGUI.

Az egyik amit érdemes megnézni hogy a System / Advanced / Admin Access menüben a Max Processes mennyire van állítva -> összesen ennyi kliens tudja egyszerre elérni a webGUI-t, ez persze nem érdekes ha a kliensenként mindig logoutoltál.

A másik hogy pfSense WAN lábon nem figyeli a GUI-t (ha még nem tetted volna meg), ergo ha kintről akarod elérni (és esetleg még nem lépted meg) akkor a Firewall / NAT / Port Forward résznél csinálj egy NAT-ot a LAN lábára pl:
Interface    Protocol    Source Address    Source Ports    Dest. Address    Dest. Ports    NAT IP             NAT Ports
WAN          TCP          *                         *                    WAN Address    *GUI port*    LAN address     *GUI port*

Ehhez megcsinálja általában a WAN fűzfal szabályt is, ha nem akkor azt is engedni kell WAN Ruleok között hogy TCP any source/any port, Destination LAN Address *GUI port*, any gateway engedve legyen. Tipikusan ezt a forgalmat érdemes logolni.
Ez nyilván security szempontból vitatható mert ezzel bárki próbálkozhat WAN oldalról belépni.

Belülről IPSeccel csak tűzfal szabály kell a LAN és IPsec interfacekre hogy a GUI port elérhető legyen. Akár létre lehet hozni pfnek egy úgy interfacet az IPsec subnetben hogy ott is legyen lába.
Cserébe itt is ez a dilemma, hogy így minden VPN kliens is el tudja érni a GUI-t.

Köszönöm az ötleteket.

Kizártam pár dolgot. A GUI más ip-ről vidáman elérhető, ha azt felveszem a tűzfal szabályok közé, tehát nincs szerver oldali probléma (nálam van a gond a kliensen). A routing táblám így néz ki kapcsolódás után (csak a releváns részek).

IPv4 Route Table
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
  srv.gw.ip.addr  255.255.255.255     xx.yy.93.254      xx.yy.93.23     26
  srv.gw.ip.addr  255.255.255.255         On-link         ipsec.local.iface.ip     26
===========================================================================
Persistent Routes:
  Network Address          Netmask  Gateway Address  Metric
          0.0.0.0          0.0.0.0     xx.yy.93.254  Default

Feltűnt, hogy a server ip-re két helyen is van bejegyzés. Egyik a LAN-om default gw-e a  másik pedig a ipsec tunel-nek kiosztott kliens ip. Mindkettő esetében a metric 26. Így fogalma sincs merre kéne mennie. A VPN kapcsolat tulajdonságaiban átírtam a metricet-et kellően magas értékre auto helyet és volia működik az elérés csatlakozás után is.

Szerkesztve: 2024. 01. 18., cs – 18:41

ha pfsense és nincs sávszélesség igény(maximum 300Mb-ig):

VPN / OpenVPN varázsló végigkattint

utánna:

System / Package manager

openvpn-client-export  -> telepít

 

ha ez is megvan:

VPN / OpenVPN / Client export

és itt ki is tudod exportálni a ovpn fájt. ha s2s.

DE ami a lényeg:

ki tudod exportálni a klienst. mármint kiadja neked egy telepíthető exe-ben mindent.

ha több user is használná a VPN servert:

System / User manager

 

na itt már el lehet menni mindenféle irányba. (RADIUS, LDAP, local)

Mi a cégnél OpnSense-en évek óta használuk az OpenVPN-t. Nagyon kényelmes vele menedzselni a usereket és kigenerálni a configokat és nagyon stabil.

Én is azt javaslom. Ingyen nem tudok jobb és tényleg minden helyzetben működő megoldásról.

Az IPSec-el nekünk is az volt a gond, hogy néha ment, néha nem.