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)- 1572 megtekintés
Hozzászólások
" ne kelljen hozzá 3rd party kliens"
ha ezt nem mondtad volna, akkor ravagtam volna, hogy tailscale :)
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…
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Nem vágom annyira a licenszet.
Ne aggódj, a mikroszoftos licenszing expertek se, csak vaktában adnak ajánlásokat.
- A hozzászóláshoz be kell jelentkezni
Kozben utananeztem, RD Gateway mehet RDS nelkul is, a 2 free licenszel (sot, a winserveren keresztul barmelyik kliens gephez is, nyilvan ott csak 1 free licenszel)
https://www.experts-exchange.com/articles/33710/Standalone-RD-Gateway-S…
- A hozzászóláshoz be kell jelentkezni
2023-ban engedd el az l2tp+ipsec (ikev1)-et.
A Windows beépített vpn kliense tud Ikev2-t.
Megy NAT mögül is. És Pfsense-vel is be lehet állítani:
https://docs.netgate.com/pfsense/en/latest/recipes/ipsec-mobile-ikev2-c…
- A hozzászóláshoz be kell jelentkezni
Én azt még mindig nem értem, miért kell ehhez pfsense ha ott a telepített win, ami tud vpn server lenni. (IKEv2 is)
Én sem vagyok win fan, de ha már megvette, használja...
- A hozzászóláshoz be kell jelentkezni
Szerintem nem rossz az, ha elválasztja a két funkciót.
De az tény, hogy az L2TP/IPsec helyett az IKEv2 jobb választás.
- A hozzászóláshoz be kell jelentkezni
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)....
- A hozzászóláshoz be kell jelentkezni
Ez érdekes lehet, köszönöm.
- A hozzászóláshoz be kell jelentkezni
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:4567elmented 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.
- A hozzászóláshoz be kell jelentkezni
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 hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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 :)
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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 hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
......-n........ egyelőre
- A hozzászóláshoz be kell jelentkezni
Én ugyan Edgerouter-en használok WireGuardot, a tűzfalban be tudom állítani, melyik VPN kliens kivel kommunikálhat. Nem hiszem el, hogy ez nem konfigurálható ott.
- A hozzászóláshoz be kell jelentkezni
Nem mondtam ilyet. Igen, meg tudom mondani, hogy milyen ip-t/tartományt tud elérni.
- A hozzászóláshoz be kell jelentkezni
De, ezt írtad, legalábbis nem tudom máshogy értelmezni.
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.
- A hozzászóláshoz be kell jelentkezni
Bocsánat, valóban ezt mondtam. Ekkor még /24-et adtam a túloldalnak aztán rájöttem, hogy egy ip is elég lesz.
- A hozzászóláshoz be kell jelentkezni
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...
- A hozzászóláshoz be kell jelentkezni
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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 foundIgen, 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).
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
A VPN-en keresztül szeretnéd a GUI-t elérni? Vagy WAN oldalról? (vagy kétlem hogy LAN-ról mert ott mennie kéne)
- A hozzászóláshoz be kell jelentkezni
Nem, WAN-on keresztül. LAN-ról el tudom érni. Belépek az RDP szerverre, onnan megy.
Másik gépről eltérő hálózaton sem.
A kliensen a use default gateway on remote network nincs beállítva. Egyelőre sok időm nem volt rá, hogy nyomozzak.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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 DefaultFeltű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.
- A hozzászóláshoz be kell jelentkezni
Add-VpnConnectionRoute -ConnectionName "ipszekvépéen" -DestinationPrefix **gateway wan IP**És meg is van a "bűnös" :).
Minden esetre sokat tanultam megint, köszönöm mindenkinek a segítő szándékot. Szerintem összeállt a megoldás.
- A hozzászóláshoz be kell jelentkezni
Uh valóban benéztem a maszkírozás közben, elnézést (javítani már nem tudom az eredeti hozzászólást).
- A hozzászóláshoz be kell jelentkezni
sub
- A hozzászóláshoz be kell jelentkezni
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)
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
SoftEther VPN - Ezt használom. Sebességben is penge.
- A hozzászóláshoz be kell jelentkezni