Instellingen voor VPN (met NAT op de server side)

[hobbit_be]

1) Ik ben geen Network expert (pretty good coder though).
2) the IP addressen zijn anders - maar zijn wel 'correct' met consistency and subnet changes

Ik heb een OpenVPN opgezet op een server met een intern IP (static) van 192.168.30.200 - deze is extern te bereiken 193.55.12.200.

Zodra ik inlog krijg ik een lokaal IP (dus op de client, mijn laptop e.g. via the TAP Adapter) van 10.8.0.*. Dit is natuurlijk de NAT die de VPN doet. (geen TAP maar TUN)

Als ik andere servers aanspreek op hetzelfde subnet als de VPN server : e.g. 192.168.30.* lukt dat allemaal zonder probleem.

Maar nu moet in een IP aanspreken met een ander subnet: eg. 192.168.35.*. Dit lukt niet meer. Ik vermoed dat 'ergens' in het hele systeem ik moet aanpassend dat ik van mijn client dit wel kan bereiken.

Ik weet dat er niets firewall / hardware matig tussen 192.168.30.* -> 192.168.35.* is (dit is managed via onze IT department).

Ook weet ik, via SSH login details vanop een andere server (e.g. 192.168.30.50) dat het IP adress dat deze server ziet 192.168.30.200 is (dus die van de OpenVPN Server).

Ik gebruik SecurePoint SSL dus ik zie dit:

-Windows TUN subnet mode network/local/netmask = 10.8.0.0/10.8.0.2/255.255.255.0 [SUCCEEDED]
Tue Apr 28 18:07:17 2020 Notified TAP-Windows driver to set a DHCP IP/netmask of 10.8.0.2/255.255.255.0 on interface {ADE4D93B-D73F-40F5-9348-XXXXXXXXX} [DHCP-serv: 10.8.0.254, lease-time: 31536000]

Mijn probleem is dat deze VPN de enige manier is om van thuis te werken dus ik kan eigenlijk niets aanpassen aan de VPN want anders ben ik technish werkloos .

Mijn vraag is dus waar denken jullie dat het probleem kan zitten? Kan ik op de client mijn routes? Gateway aanpassen of is het iets waarvoor ik wel degelijk ik iets aan OpenVPN server moet veranderen?.

Helaas kan ik niet rekenen op onze IT Department want dit zijn 'persoonlijke' servers.

...

OpenVPN (on Centos), SecurePoint SSL
...

Graphish overzicht.

[ep667]

Wat is het subnet waarin je 'server' een IP-adres ontvangt? Is dat 192.168.30.0/24 of een groter subnet? Ik ben namelijk al eens benieuwd hoe dit dan intern gerouteerd wordt. Mogelijk dat het daar misgaat.

Kun je via je VPN server wel het internet bereiken?

En (hoewel het je niet helpt, toch een belangrijke vraag) waarom lost het IP Department van je bedrijf dit niet op? Is het niet belangrijk dat iedereen thuis productief kan zijn?

[BAJansen]

Is IP-forwarding (routing) ingeschakeld op de OpenVPN server? Zie hier voor meer informatie.

[jvanhambelgium]

De kans is groot dat het een eenvoudig routing probleem betreft verderop in het netwerk. Mogelijks weet de server op het 192.168.35.x netwerk niet van het bestaan af van je "client" pool 10.8.0.x
Je zal LocalIT toch moeten inschakelen om dit te bevestigen. Er moet toch iets "routerachtig" tussen staan, aangezien 192.168.30.x en 192.168.35.x echt wel andere netwerken zijn. Die "router" kan een PC met 2 netwerk-cards zijn hé.

TESTJE : Kan je na het opzetten van de VPN eventueel die server op 192.168.30.50 overnemen en inloggen (vb met RDP of SSH) en vandaar eens proberen verder te gaan naar 192.168.35.50 ?
Kan bestaat dat dit wel lukt ;-)

[hobbit_be]

Hoi allemaal - allemaal heel goede vragen en tips - ik zal die morgen (29/04) eens testen .

@ep667

1) subnet van server: 192.168.30.* (255.255.255.0) - maar de firewall tussen 192.168.30.* -> 192.168.50.* staat open.

2) Als ik op de VPN zit kan ik het grootste deel van het internet gebruiken, behalve de sites die niet toegestaan zijn.

3) Omdat we online tools gebruiken voor day to day job. Het feit dat ik mijn eigen servers heb + VPN (anders mensen hebben GEEN VPN alleen een citrix toestand) is een buitenbeentje met het previso - you take care of it . De server die ik niet kan bereiken is een ESX server (waarop de servers draaien die ik vernoem).

@BAJansen Ga ik morgen direct zien - maar ik neem aan van wel (ik herinner me toch dat)

@jvanhambelgium

- 192.168.30.x and 192.168.35.x zijn idd volledig andere VLAN's (met firewall ertussen).
- Maar aangezien de 'NAT' (10.8.0.x) eigenlijk client side is ziet de rest van het interne netwerk (192.168.30.x) alleen maar requests die van 192.168.30.200 komen (de VPN Server).
- Je test ga ik idd morgen eens proberen - want ik geraak idd zonder probleem met SSH op eender welke 192.168.30.x server. Maar idd als ik dan daar naar 192.168.35.x niet lukt zit het probleem misschien daar.

Ik dacht dat het eerder te maken heeft dat de DCHP die ik als klant krijg 10.8.0.x met een subnet mask van 255.255.255.0 heeft dat ie zelfs niet probeert naar 192.168.35.x te gaan (maar waarom dan geen probleem naar 192.168.30.x ? ... Zoals je kan zien echt geen network persoon.

Jullie tips heb ik ook net een 'tracert naar 192.168.35.50' en deze gaat toch eerst naar 10.8.0.1 (dus naar de VPN server).

Ik hou jullie op de hoogte!

[jvanhambelgium]

hobbit_be schreef op dinsdag 28 april 2020 @ 23:55:
- 192.168.30.x and 192.168.35.x zijn idd volledig andere VLAN's (met firewall ertussen).
- Maar aangezien de 'NAT' (10.8.0.x) eigenlijk client side is ziet de rest van het interne netwerk (192.168.30.x) alleen maar requests die van 192.168.30.200 komen (de VPN Server).
- Je test ga ik idd morgen eens proberen - want ik geraak idd zonder probleem met SSH op eender welke 192.168.30.x server. Maar idd als ik dan daar naar 192.168.35.x niet lukt zit het probleem misschien daar.

Ik dacht dat het eerder te maken heeft dat de DCHP die ik als klant krijg 10.8.0.x met een subnet mask van 255.255.255.0 heeft dat ie zelfs niet probeert naar 192.168.35.x te gaan (maar waarom dan geen probleem naar 192.168.30.x ? ... Zoals je kan zien echt geen network persoon.

Met DHCP heeft het denkelijk niets te maken. Met VPN/Tunnels is het altijd wat uitkijken want "conventionele" regeltjes worden niet altijd gevolgd. Normaal heb je standaard geen "split tunnel" dus op de moment dat je VPN clientside actief is gaat alles gewoon in de tunnel en komt het er langs de andere kant uit. Je VPN server, zonder "NAT" zou verantwoordelijk zijn voor het ARP'en van dat 10.8.0.x block zodat die , in naam van z'n clients, kan verkeer kan accepteren en dan verder naar de clients doorsluizen. Meestal in het netwerk is dan ook de nodige routing voorzien dat het 10.8.0.x block te vinden is "achter" 192.168.30.200 (VPN-server)
Met "split tunnel" geeft je client-side al op via een ACL op je client welke IP-ranges er achter de tunnel liggen en ander verkeer gaat sowieso niet in de tunnel maar gewoon langs je lokale adapter naar buiten (of volgt gewoon de routing-table van je PC)

Als je dus met je test vanaf vb die 192.168.30.50 server toch ook niet op de 192.168.35.x geraakt is het tijd om met de firewall mensen te gaan praten want verder kan jij dan niet veel doen..."staat open" is relatief en mischien moeten ze maar even bewijs leveren dat ze verkeer dan ook zien aankomen.

En ook, op de server 192.168.35.200 staat geen host-firewall / iptables te draaien die vb enkel z'n local-subnet zou toelaten ?

[hobbit_be]

Een update :

@BAJansen : IP forwarding is indeed set up:
$ cat /proc/sys/net/ipv4/ip_forward
1

@jvanhambelgium : Ik heb nu SSH'd into the VPN server (dus eerst VPN -> SSH into) 192.168.30.200.
Dan doormiddel van netcat / ping / telnet EN 'links' geprobeert aan de server die ik wil bereiken - en dat lukt NIET. Maw al zeker een probleem met de firewall tussen de 2 VLANs. Voor de rest kan ik wel gewoon met links naar www.google.com etc.

Het proberen SSH naar een andere server op dat 30.* subnet zou niet helpen want de firewall request was puur en alleen voor traffic van de VPN server (i.e. 192.168.30.200 -> 192.168.35.x - met poorten 80,8080,and 443)

Lijkt me dus idd toch een probleem voor de IT Department - daarvoor is het wachten tot vrijdag (maar 1 persoon die dat kan op een organisatie met 3000 medewerkers ).

Ik update jullie zodra ik meer weet - maar nu al enorm bedankt want een stap verder!

[ep667]

Ja, dat lag dan wel voor de hand. Het zijn gescheiden subnets die geïsoleerd zijn van elkaar, zo lijkt het. Daar zal het IT Department vast een goeie reden voor hebben, maar het is niet erg praktisch.

Kon je het systeem in de oude situatie wél vanaf 192.168.30.200 bereiken? Of was dat toen niet aan de orde?

De oplossing is enerzijds om jouw server in .35 te laten 'verplaatsen' naar het andere VLAN of de twee VLANs onderling routeerbaar te maken. Dat laatste is wellicht een beveiligingsprobleem, waardoor het niet mogelijk is?

[hobbit_be]

@ep667 Volgens de IT Dept is er 'nooit' traffic verstuurt van de VPN naar de target server. Inderdaad zijn de VLAN gescheiden voor een goede reden (die ik aanvroeg een paar geleden). Helaas vanwege de CoVid situatie moet ik nu wel door de firewall heen (maar dit was dus al aangevraagd). Ze gaan nu meewerken - wellicht een 'Leuk' probleem

VPN verplaatsen kan in niet (i.e. is mijn ENIGE weg in - dus 1 klein foutje en technish werkloos . Too high risk. (Ook kan ik geen 2 de aanmaken omdat die op de 35 moet zijn en dat kan alleen via de server die ik moet bereiken)...

Ik ga hun wel zeggen dat het misschien een echt VLAN issue (niet een gewoon firewall / routing) - I will keep you posted...

[hobbit_be]

Een dikke maand verder en het 'probleem' is 'opgelost' door onze IT Department.

Wat ze hebben gedaan is dat alle verkeer dat van van 192.128.30.* via een NAT vertalen naar de gateway van 192.128.35.8 ... Dus elke machine of .35 (waar ik dus heenmoest) ziet alle 'traffic' van 30 als komende van 192.128.35.8.

Bizarre oplossing - maar nu werkt alles, volgens mij zorgt de NAT ervoor dat het VLAN crossing is opgelost...

Bedannk voor al jullie support