Locale resources aanspreken wanneer VPN verbinding actief is

[Homewrecker]

Hallo,

Voor mijn werk moet ik op VPN zitten om overal aan te geraken, echter staat mijn muziek op mijn lokale NAS en die kan ik niet benaderen wanneer de VPN actief is. Ik heb wat opzoekwerk gedaan en de oplossing is om een custom route toe te voegen. Echter lukt me dit niet want mijn NAS draait op 192.168.1.17 en als ik in de routing tabel kijk, dan voegt de VPN reeds routes toe voor 192.168.1.*:



Is het mogelijk om dit te overriden?

Alvast bedankt.
Groeten

[lier]

Denk dat het eenvoudigste is om je lokale netwerk in een ander netwerksegment te plaatsen (bijvoorbeeld 192.168.2.0/24). Hooguit dat je dan je lokale resources op IP adres moet benaderen.

[Glashelder]

Kans is dik aanwezig dat dit niet mogelijk is.

Dit doet men als beveiligingsmaatregel. Door al het andere netwerkverkeer af te kappen voorkom je dat derden via een VPN client toegang kunnen verkrijgen tot een corporate netwerk.

[MasterL]

De routes van jouw screenshot zijn /32 routes (255.255.255.255) ik zie geen routes die van toepassing zijn op 192.168.1.17. Misschien een screenshot van de gehele route table?
Is dit niet gewoon jouw eigen interface? met andere woorden gebruik jij lokaal niet "gewoon" 192.168.1.239?

Om sec je vraag te beantwoorden, ja.
Als je route print doet zie je bovenstaan "Interface List" staan, daar stant de ID's van je netwerk adapter (in mijn geval bijvoorbeeld 13). Ik kan zelf een /32 "on link" route aanmaken om zeker te zijn dat traffic over die interface loopt:

Ik zou dus doen:
route add 192.168.1.17 mask 255.255.255.255 0.0.0.0 IF 13

Overigens wie bedacht heeft of 192.168.1.1 te gebruiken (zakelijk/vpn routing subnet).........

Glashelder schreef op woensdag 4 augustus 2021 @ 13:32:
Kans is dik aanwezig dat dit niet mogelijk is.

Dit doet men als beveiligingsmaatregel. Door al het andere netwerkverkeer af te kappen voorkom je dat derden via een VPN client toegang kunnen verkrijgen tot een corporate netwerk.

Dit lukt toch niet, ze kunnen firewallen op source IP-adressen alle RFC1918 proberen te routeren over de tunnel maar met SRC NAT/masquerade en routing krijg je dit toch wel voor elkaar.

[ Voor 33% gewijzigd door MasterL op 04-08-2021 14:10 ]

[Glashelder]

MasterL schreef op woensdag 4 augustus 2021 @ 14:05:
Dit lukt toch niet, ze kunnen firewallen op source IP-adressen alle RFC1918 proberen te routeren over de tunnel maar met SRC NAT/masquerade en routing krijg je dit toch wel voor elkaar.

Het mag voor zich spreken dat als je een computer van een slachtoffer als hop gebruikt dat je dan ook het VPN adres als source gebruikt.

Zo dom zijn kwaadwillenden nou ook weer niet

[DataGhost]

Glashelder schreef op woensdag 4 augustus 2021 @ 13:32:
Kans is dik aanwezig dat dit niet mogelijk is.

Dit doet men als beveiligingsmaatregel. Door al het andere netwerkverkeer af te kappen voorkom je dat derden via een VPN client toegang kunnen verkrijgen tot een corporate netwerk.

Dit gebeurt helemaal niet als beveiligingsmaatregel. Deze is namelijk prima te "omzeilen" door lokaal een ander subnet te gebruiken zoals 192.168.0.0/24 of iets in de 10. of 172. ranges. De VPN-server weet helemaal niet wat jij voor je thuisnetwerk gebruikt. Dit is gewoon een enorm domme config als opzettelijk 192.168.1.0/24 voor het VPN-subnet is gebruikt, omdat dat namelijk voor ontzettend veel thuisnetwerken de standaardrange is. If anything wekt het de suggestie dat het VPN gewoon in bridge staat met het kantoornetwerk wat toevallig ook op 192.168.1.0/24 zit (vanwege de standaardsettings van het modem van de provider gok ik dan maar even). In dat geval zit er qua beveiliging uberhaupt geen enkele gedachte achter.

De makkelijkste oplossing is inderdaad het thuisnetwerk andere IP's geven. Een soort van lelijke oplossing is het weggooien van de normale VPN-route en alleen voor de benodigde IP's statische routes maken via de VPN, of andersom alleen voor je lokale IP's statische routes maken. De beste oplossing is om het VPN een van de vele andere mogelijke "obscure" ranges te geven (10.37.42.0/24 is wat ik zelf voor m'n VPN heb) en alle services die toegankelijk moeten zijn een IP in die range te geven. Zo blijft de rest van het bedrijf onbereikbaar minus het minimaal noodzakelijke. Met DNS hoef je als gebruiker ook niet te weten op welke IP's alles zit. Maar deze oplossing vereist een kundige netwerkbeheerder die er genoeg zin in heeft.

[MasterL]

Glashelder schreef op woensdag 4 augustus 2021 @ 14:11:
[...]

Het mag voor zich spreken dat als je een computer van een slachtoffer als hop gebruikt dat je dan ook het VPN adres als source gebruikt.

Zo dom zijn kwaadwillenden nou ook weer niet

Beetje offtopic maargoed:
Precies en dus kan je als VPN "aanbieder" niet weten waar de traffic exact vandaan komt en moet je VPN als "untrusted" behandelen. Onnodig verkeer de tunnel in routeren wat bandbreedte kost en computing power in de routers om het vervolgens weer te firewallen lijkt mij daarom ook niet wenselijk.
Ik denk dus dat:

A: De VPN client 192.168.1.X/24 toevoegt als route.
B: De VPN client een IP (routing) adres krijgt in de 192.168.1.X/24 range welke een interface
route toevoegt met een lagere metric/distance als de IF van zijn lokale netwerk.

Als bovenstaande klopt vind ik het een uitermate onhandig gekozen subnet maar dat terzijde

[Rik.]

Glashelder schreef op woensdag 4 augustus 2021 @ 13:32:
Kans is dik aanwezig dat dit niet mogelijk is.

Dit doet men als beveiligingsmaatregel. Door al het andere netwerkverkeer af te kappen voorkom je dat derden via een VPN client toegang kunnen verkrijgen tot een corporate netwerk.

Ik denk niet dat het helemaal niet mogelijk is. Voorheen was dit bij de VPN op mijn werk ook niet mogelijk, maar sinds kort maken we gebruik van een andere VPN service en gaat al het interne (werk) verkeer via de VPN, en alle andere dingen gaan buiten de VPN om. Ik kan dus prima mijn interne netwerk benaderen, terwijl ik verbonden ben met het bedrijfsnetwerk.

[MasterL]

DataGhost schreef op woensdag 4 augustus 2021 @ 14:21:
[...]

Dit gebeurt helemaal niet als beveiligingsmaatregel. Deze is namelijk prima te "omzeilen" door lokaal een ander subnet te gebruiken zoals 192.168.0.0/24 of iets in de 10. of 172. ranges. De VPN-server weet helemaal niet wat jij voor je thuisnetwerk gebruikt. Dit is gewoon een enorm domme config als opzettelijk 192.168.1.0/24 voor het VPN-subnet is gebruikt, omdat dat namelijk voor ontzettend veel thuisnetwerken de standaardrange is. If anything wekt het de suggestie dat het VPN gewoon in bridge staat met het kantoornetwerk wat toevallig ook op 192.168.1.0/24 zit (vanwege de standaardsettings van het modem van de provider gok ik dan maar even). In dat geval zit er qua beveiliging uberhaupt geen enkele gedachte achter.

De makkelijkste oplossing is inderdaad het thuisnetwerk andere IP's geven. Een soort van lelijke oplossing is het weggooien van de normale VPN-route en alleen voor de benodigde IP's statische routes maken via de VPN, of andersom alleen voor je lokale IP's statische routes maken. De beste oplossing is om het VPN een van de vele andere mogelijke "obscure" ranges te geven (10.37.42.0/24 is wat ik zelf voor m'n VPN heb) en alle services die toegankelijk moeten zijn een IP in die range te geven. Zo blijft de rest van het bedrijf onbereikbaar minus het minimaal noodzakelijke. Met DNS hoef je als gebruiker ook niet te weten op welke IP's alles zit. Maar deze oplossing vereist een kundige netwerkbeheerder die er genoeg zin in heeft.

Bridged daar had ik helemaal niet over nagedacht..Hoop toch niet dat dit een soort van L2 VPN is.

[Homewrecker]

Ik moet iets verkeerd gedaan hebben vorige keer want met route add 192.168.1.17 mask 255.255.255.255 0.0.0.0 IF 14 lukt het. Hartelijk bedankt!

[MasterL]

Mooi dat het is gelukt, ben het overigens wel eens met @lier en @DataGhost op de lange termijn kan je beter jouw eigen netwerk voorzien van een nieuw (unieker) subnet.

[Glashelder]

DataGhost schreef op woensdag 4 augustus 2021 @ 14:21:
[...]

Dit gebeurt helemaal niet als beveiligingsmaatregel. Deze is namelijk prima te "omzeilen" door lokaal een ander subnet te gebruiken zoals 192.168.0.0/24 of iets in de 10. of 172. ranges. De VPN-server weet helemaal niet wat jij voor je thuisnetwerk gebruikt. Dit is gewoon een enorm domme config als opzettelijk 192.168.1.0/24 voor het VPN-subnet is gebruikt, omdat dat namelijk voor ontzettend veel thuisnetwerken de standaardrange is. If anything wekt het de suggestie dat het VPN gewoon in bridge staat met het kantoornetwerk wat toevallig ook op 192.168.1.0/24 zit (vanwege de standaardsettings van het modem van de provider gok ik dan maar even). In dat geval zit er qua beveiliging uberhaupt geen enkele gedachte achter.

De makkelijkste oplossing is inderdaad het thuisnetwerk andere IP's geven. Een soort van lelijke oplossing is het weggooien van de normale VPN-route en alleen voor de benodigde IP's statische routes maken via de VPN, of andersom alleen voor je lokale IP's statische routes maken. De beste oplossing is om het VPN een van de vele andere mogelijke "obscure" ranges te geven (10.37.42.0/24 is wat ik zelf voor m'n VPN heb) en alle services die toegankelijk moeten zijn een IP in die range te geven. Zo blijft de rest van het bedrijf onbereikbaar minus het minimaal noodzakelijke. Met DNS hoef je als gebruiker ook niet te weten op welke IP's alles zit. Maar deze oplossing vereist een kundige netwerkbeheerder die er genoeg zin in heeft.

Mee eens dat het gekozen subnet hier niet handig is voor een VPN. Maar het is wel degelijk een best practice om lokaal verkeer gewoon helemaal te blokkeren zolang de VPN actief is.

Dat omzeil je niet met een ander subnet, dat wordt gewoon dan actief geblokkeerd door je VPN applicatie

Maar gezien de opzet hier zal dat vast niet de gedachte geweest zijn inderdaad, mee eens.

[DataGhost]

Glashelder schreef op woensdag 4 augustus 2021 @ 14:36:
[...]

Mee eens dat het gekozen subnet hier niet handig is voor een VPN. Maar het is wel degelijk een best practice om lokaal verkeer gewoon helemaal te blokkeren zolang de VPN actief is.

Dat omzeil je niet met een ander subnet, dat wordt gewoon dan actief geblokkeerd door je VPN applicatie

Maar gezien de opzet hier zal dat vast niet de gedachte geweest zijn inderdaad, mee eens.

Nja, dat is gewoon een default route (of twee) met een lage metric, er wordt verder niks geblokkeerd, er wordt effectief gewoon geen verkeer meer door het lokale netwerk gestuurd (behalve het VPN-verkeer). Dat wordt vaak zo gedaan om "een ander extern IP te hebben" en om te zorgen dat VPN-verkeer voorrang krijgt bij "IP-conflicten" zoals bij TS, niet zozeer als beveiliging. Met statische routes met nog lagere metrics kan je die "blokkade" prima weer omzeilen als je dat wilt. Als zijn werk een server op 192.168.1.17 heeft staan en TS tegelijk zijn eigen server op 192.168.1.17 wil bereiken is geen enkele manier* om dat voor elkaar te krijgen, omdat het voor de client-applicatie volkomen ambigu is welke je wilt bereiken. Daarom is het makkelijker om gewoon alle verkeer door het VPN te gooien, niet zo zeer best practice. * zeer, zeer weinig client-apps hebben de optie om aan een specifieke interface te binden voor uitgaande verbindingen

[Homewrecker]

Een kleine update: als ik reboot ben ik de route kwijt dus ik dacht, ik maak er een persistent route van. Maar die lijkt een reboot ook niet te overleven. Ik zie dat de interface nummer veranderd na elke reboot, is dat misschien de oorzaak?

[Ben(V)]

Weet je wel zeker dat je dit wilt doen?
Je koppelt zo effectief je thuisnetwerk aan je werknetwerk.

Stel dat je thuis gehacked wordt en je krijgt last van randsomeware, dat is heel vervelend, maar als via deze constructie jouw werk ook besmet wordt ben jij daar aansprakelijk voor en dat kan een dure grap worden.

Ik zou mij persoonlijk niet in zo'n situatie willen manoeuvreren.

Het is niet voor niets dat normaal gesproken bedrijven alleen toestaan te connecten door middel van hun eigen VPN client die je op je PC moet installeren en die gemaakt is om alleen via die VPN te werken en als hij draait je lokale lan niet bereikbaar is.

[DataGhost]

Ben(V) schreef op dinsdag 10 augustus 2021 @ 11:44:
Weet je wel zeker dat je dit wilt doen?
Je koppelt zo effectief je thuisnetwerk aan je werknetwerk.

Dat gebeurt helemaal niet door het instellen van een statische route. Kan je anders uitleggen waarom dit volgens jou wel gebeurt?

Stel dat je thuis gehacked wordt en je krijgt last van randsomeware, dat is heel vervelend, maar als via deze constructie jouw werk ook besmet wordt ben jij daar aansprakelijk voor en dat kan een dure grap worden.

Is dat onmogelijk als je gewoon verbinding met een VPN hebt zonder zelf ingestelde routes op je lokale PC?

Het is niet voor niets dat normaal gesproken bedrijven alleen toestaan te connecten door middel van hun eigen VPN client die je op je PC moet installeren en die gemaakt is om alleen via die VPN te werken en als hij draait je lokale lan niet bereikbaar is.

Heb je de uitleg hierboven gemist waarom dat normaliter gebeurt? En kan je anders misschien uitleggen hoe je denkt dat VPN-verkeer het internet op gaat als je hele lokale lan niet bereikbaar is?

[ Voor 5% gewijzigd door DataGhost op 10-08-2021 11:51 ]