VPN opzetten naar LAN

[renevanh]

Een klant waar ik regelmatig wat computerdingetjes regel gebruikt een ERP pakket voor zijn bedrijf, wat twee werknemers telt, inclusief hemzelf.
De afgelopen jaren hebben ze beide hiermee gewerkt, de 2de persoon via Radmin op de PC in het kantoortje aan huis. Dat werkt wel, maar ze kunnen nooit tegelijk iets doen. Dat moest veranderen.

Het ERP pakket ondersteund meerdere gebruikers in een server/client situatie. Dat hebben we nu ingericht en werkt in principe, maar alleen binnen het LAN. Het idee is juist dat de 2de gebruiker vanuit zijn eigen huis- of werklocatie aan de gang kan.

Mijn idee: VPN opzetten en gaan. Ik dacht dat doe ik even, maar dat valt toch even tegen.
Eisen aan de VPN:
- remote client moet de lokale netwerkinterface kunnen benaderen (applicatieserver van het ERP systeem is gebonden aan één interface, niet wijzigbaar) en poort 4506 kunnen benaderen.
- Name resolving voor het LAN moet werken, de ERP software werkt uitsluitend met de hostnaam, niet met het IP-adres (hoe verzinnen ze het...).
- Filesharing moet mogelijk zijn (maar dat is het meestal wel als je bovenstaande punten hebt).

Ik aan de slag. Eerst OpenVPN geprobeerd. Verbinding komt tot stand, pingen naar VPN interface kan, maar name resolve en lokale interface niet. Best wat zitten knoeien maar niet aan de praat gekregen.

Ingebouwde VPN van Windows geprobeerd, ook weinig succes. File sharing werkt over IPv6 prima, over IPv4 niet. Idem voor name resolving die over IPv6 de VPN interface bereikt, niet de lokale. Ik krijg geen verbinding met de lokale interface en dus geen contact met de applicatieserver. Redelijk zitten knoeien met de routing binnen Windows, maar zonder succes.

Hamachi geprobeerd. Daar werkt alles wel, maar Hamachi filter het verkeer en poortje 4506 ook. Daardoor geen verbinding.


Nu weet ik het niet meer. OpenVPN moet het kunnen, maar ik kreeg het niet aan de praat, ook niet met hulp op het forum van OpenVPN. Daar werd vooral heel moeilijk gedaan met 'wij weten het wel maar als je het niet kan mag je het niet doen' gedrag
Is er hier iemand die een goede tip heeft of mij kan bijstaan? Ik wil er ook van leren, maar nu zit ik vast

[Thralas]

renevanh schreef op woensdag 20 januari 2016 @ 22:24:
- Name resolving voor het LAN moet werken, de ERP software werkt uitsluitend met de hostnaam, niet met het IP-adres (hoe verzinnen ze het...).

Wat bedoel je met name resolving? In een 'simpel' LAN hebben devices geen DNS entry op een lokale resolver. Bedoel je NetBIOS name resolution?

Ik aan de slag. Eerst OpenVPN geprobeerd. Verbinding komt tot stand, pingen naar VPN interface kan, maar name resolve en lokale interface niet. Best wat zitten knoeien maar niet aan de praat gekregen.

Je zult in ieder geval uit moeten zoeken of je op layer 2 moet kunnen communiceren (tap in OpenVPN-land) en of je in hetzelfde subnet moet zitten (vermoed ik wel als je echt niet om NetBIOS heen kunt).

Ingebouwde VPN van Windows geprobeerd, ook weinig succes. File sharing werkt over IPv6 prima, over IPv4 niet. Idem voor name resolving die over IPv6 de VPN interface bereikt, niet de lokale. Ik krijg geen verbinding met de lokale interface en dus geen contact met de applicatieserver. Redelijk zitten knoeien met de routing binnen Windows, maar zonder succes.

Wat is de lokale interface?

Daar werd vooral heel moeilijk gedaan met 'wij weten het wel maar als je het niet kan mag je het niet doen' gedrag
Is er hier iemand die een goede tip heeft of mij kan bijstaan? Ik wil er ook van leren, maar nu zit ik vast

Wij weten het misschien wel, maar alleen als je je OpenVPN config post

[renevanh]

Thralas schreef op woensdag 20 januari 2016 @ 23:04:
[...]


Wat bedoel je met name resolving? In een 'simpel' LAN hebben devices geen DNS entry op een lokale resolver. Bedoel je NetBIOS name resolution?

Juist ja, die! Wist even niet zeker of het inderdaad om NetBIOS ging... tijdje geleden

Je zult in ieder geval uit moeten zoeken of je op layer 2 moet kunnen communiceren (tap in OpenVPN-land) en of je in hetzelfde subnet moet zitten (vermoed ik wel als je echt niet om NetBIOS heen kunt).

Ja, dat is essentieel voor de applicatie.
Je hebt nu al meer geholpen dan het OpenVPN forum denk ik, ik moet blijkbaar met tap en niet met tun aan de gang.

Wat is de lokale interface?

Simpel gezegd de fysieke interface, dus de 192.168.178.x in dit geval, de LAN interface.

Wij weten het misschien wel, maar alleen als je je OpenVPN config post

Zie hieronder. Er zitten nog een paar probeersels in qua routing, de CCD file is volgens mij niet nodig, maar dat weet ik niet zeker.
Serverzijde is een 192.168.178.0 netwerkje, client 192.168.1.0

server configuratie:

code:

port 1194
proto tcp

dev tun

ca ca.crt
cert server.crt
key server.key

dh dh1024.pem

topology subnet
server 10.8.0.0 255.255.255.0

ifconfig-pool-persist ipp.txt

push "route 192.168.178.0 255.255.255.0"
push "route 192.168.1.0 255.255.255.0"

client-config-dir ccd
route 192.168.1.0 255.255.255.0

keepalive 10 120
comp-lzo

persist-key
persist-tun

status openvpn-status.log

verb 3

Client

code:

client

dev tun
proto tcp

remote 83.82.x.x 1194

resolv-retry infinite

nobind

persist-key
persist-tun

ca ca.crt
cert wim.crt
key wim.key

remote-cert-tls server

comp-lzo
verb 3

CCD file

code:

iroute 192.168.1.0 255.255.255.0

[xzaz]

Ipforwarding moet ook aanstaan, staat die aan? Daarnaast heb ik hier een static route in mijn router.

https://openvpn.net/index...enable-ip-forwarding.html

[ Voor 16% gewijzigd door xzaz op 21-01-2016 12:08 ]

[renevanh]

xzaz schreef op donderdag 21 januari 2016 @ 12:07:
Ipforwarding moet ook aanstaan, staat die aan? Daarnaast heb ik hier een static route in mijn router.

Ja, al eerder gelezen en ingesteld, IP forwarding is actief.
Waarom een route in je router? VPN loopt tussen client en server, daar heeft je router (behalve port forward voor de VPN verbinding) toch weinig mee te maken? De routing van VPN interface naar LAN gebeurd toch op de server?
Of route je je VPN naar je router en laat je die je 192.168.1.x naar 192.168.178.x routen? Is dat geen nodeloze omweg?

[xzaz]

Ik wil dat alles in het netwerk 192.68.1.x beschikbaar is voor de 10.8.1.x netwerk. Ik heb een static route in mijn router zodat ik overal bij kan via het subnet van de vpn.

Daarnaast heb ik ook gemerkt dat veel router 1194 UDP/TCP niet leuk vinden, ik denk dat deze standaard in gebruik is / gereserveerd is voor (niet altijd) beschikbare ingebouwde VPN. Ik heb dus een andere poort gepakt op UDP.

[ Voor 8% gewijzigd door xzaz op 22-01-2016 15:59 ]

[Paul]

Waarop draaide je OpenVPN? Op de internetrouter of op de server met het ERP-pakket? Of weer ergens anders?

Welke VPN-oplossing je ook kiest, namen resolven gaat een dingetje zijn. Het makkelijkste is om op de PC met de VN-client een entry op te nemen in het hosts-bestand. Iedere naam die gebruikt wordt (waarschijnlijk alleen de computernaam van de ERP-server) zet je erin, met het juiste IP-adres (192.168.178.x).

Als je de VPN termineert op de internetrouter dan kan het hele netwerk probleemloos (onder voorbehoud van de firewall op je router uiteraard) bij je VPN-client (voor retourverkeer), en als je in de VPN-instellingen opgeeft dat je client het subnet 192.168.178.0/24 kan vinden via de VPN-server dan kan je client ook naar binnen.

Draai je de VPN-server op de ERP-server dan kunnen er rare dingen gebeuren wanneer je via een bepaald IP naar een ander IP op diezelfde server gaat, het retourpad kon dan wel eens erg vreemd lopen (of geprobeerd worden en mislukken ).

Welke router betreft het? Een Ziggo UBEE (gegokt aan de hand van het IP)? Doet hij ook Wifi en zo ja, wordt die (van de router dus, niet een los AP) ook gebruikt ?

[Thralas]

Wat Paul hierboven suggereert mbt. hostnames is ook een goede - als het werkt met entries in je hosts file dan is NetBIOS blijkbaar geen vereiste, en zou je er met een paar juiste routes moeten zijn.

Grootste probleem wat ik daar zie is wat hij ook al aanstipt, als je VPN gateway niet de primaire router is heb je een extra route op je router nodig. Bij veel SoHo-routers kun je dat simpelweg niet configureren.

Alternatief blijft uiteraard om te switchen van tun naar tap, dan verdwijnen alle routingproblemen opeens als sneeuw voor de zon. Vereist wel wat extra configuratiehandelingen op de VPN server - je zult de netwerkinterface richting het LAN in een bridge moeten hangen met de tap interface van OpenVPN..

[renevanh]

VPN server draait op hetzelfde systeem waar het ERP pakketje op draait, betreft een Windows 7 hosts (wat Windows 10 gaat worden uiteraard).

Router is inderdaad een UBEE. Ingebouwde VPN is helaas niet echt werkend te krijgen. Dat heb ik geprobeerd maar lijkt erg bedoeld voor router - router verbindingen, ook gezien de feedback hierover die ik vond via Google.
Deze router doet ook WiFi en die wordt zeker ook gebruikt, maar betreffende PC is bedraad aangesloten (gelukkig!)

Het idee met de hosts file is een goede.
Netwerkbrug heb ik geprobeerd maar was niet direct een succes, zeker niet omdat ik remote bezig was natuurlijk... haha

Het verschil tussen tun en tap is me nog steeds niet helemaal duidelijk. Ik heb het - voor de duidelijkheid -
alleen nog met tap geprobeerd.

[Aionicus]

Waar het op neerkomt is eigenlijk heel simpel op te lossen via een paar truukjes.

Je kan het eventueel via openvpn doen of zelfs via een SSH/SSL tunnel met een linux kastje zo simpel als een raspberry pi.

Ik wil best een keer met je meekijken naar je openvpn configuratie en het samen met je even oplossen via webex/skype etc.

Voor openvpn heb je twee dingen nodig om dit werkend te krijgen :

* je gebruikt in general dev tun , dev tap is de ouderwetse manier en kan wel werken maar is in mijn ervaring een stuk instabieler tijdens gebruik.

1 ) je moet het ip van de "server" kunnen pingen vanaf je vpn verbinding. Dit kan je doen doen door inderdaad de route mee te pushen : push "route 192.168.1.0 255.255.255.0"
zoals je in je server config hebt aanstaan.

Als je dus vanaf de "remote werkplek" ingelogd bent op de openvpn en je het ip kan pingen dan is het heel simpel om via een truukje het op "hostname" available te maken.

er zijn middelen via openvpn (registerdns / push option "DOMAIN") etc om hostnames door te sturen maar dat is soms erg ingewikkeld om lekker aan de praat te krijgen (en goed voor kopzorgen).

Aangezien het om 1 persoon gaat is het in dit geval veel makkelijker om even in zijn hosts file te gaan (in windows) en dan het ip adres van de "server" en de "servernaam" toe te voegen in de etc/hosts.

Als je dan via command prompt / shell een nslookup zou doen of een ping "servernaam" dan pakt hij de ingestelde waardes vanuit je hosts file en dan zou hij gewoon moeten kunnen verbinden.

Een andere optie zou zijn om bv via een (linux) bak een ssh-tunnel op te zetten en dan door bv putty of myendtunnel ervoor te zorgen dat hij de port forward naar localhost:4506 , dan zou je daarna wel in de hosts file op de client dit toevoegen : 127.0.1.1 servernaam

Lemme know if you need more help

[johnkeates]

Gebruik geen Raspberry Pi throughput is te laag. Wat je probleem is, is dat NetBIOS niet cross-subnet werkt. Hier zijn twee opties voor:

- Geen NetBIOS gebruiken
- NetBIOS relay gebruiken

Ander probleem is dat de Ubee firmware standaard niet lekker werkt met een netwerk waar onbekende routering of subnets rondspoken... komt voornamelijk door de standaard iptables2 setup die op de firmware ingebouwd zit. Dat kan je helaas niet veranderen, en zelfs al zou je aan het hacken gaan (het kan wel via een seriele console die je op het PCB van de modem kan vinden), dan is het bij de eerstvolgende TFTP boot of firmware update van de provider weer weg.

Wat je nodig hebt:

- Een fatsoenlijke router/firewall
- Een systeem dat NetBIOS kan relayen (of je gebruikt NetBIOS gewoon niet)

Wat je waarschijnlijk beter niet kan doen:

- Layer2 VPN opzetten (niet bepaald veilig voor thuisgebruik)
- RDP / terminal server optuigen (duur)
- Tinc, SSL VPN, ngrok, socks proxies, ssh tunneling, TeamViewer, Hamachi enz. (niet geschikt)

Wat ik je suggereer:

- als je low-budget werkt: een pfSense firewall
- kan kant-en-klaar bij netgate besteld worden als je net wat meer te besteden hebt
- in een VM als je niks te besteden hebt

met pfSense kan je dan je WAN IP van je kabelverbinding door bridge modus beter gebruiken, bijvoorbeeld wel poort 1194 gebruiken in plaats van wat Ubee/provider vind. Daarnaast zit OpenVPN, IPSec, L2TP enz. ingebouwd, inclusief een NetBIOS relay, en fatsoenlijke subnet routing, NAT en DNS services. Dit kan natuurlijk ook met een apparaat van een random netwerk leverancier, bijv. Cisco, HP, Juniper enz. Kost je een tienvoud in zal in je huidige situatie weinig tot geen toegevoegde waarde hebben.

Wat je qua setup dan waarschijnlijk nodig hebt:

- OpenVPN server aanmaken (duh)
- Lokale subnets die je wil kunnen bereiken toevoegen in de configuratie voor de OpenVPN server die je net aangemaakt hebt
- NetBIOS bridging aan zetten
- DNS push aan zetten

het is ook praktisch om Client Export Utility te installeren in de pfSense package manager, dan kan je met 1 druk op de knop voor Windows, OSX, Linux, Android, iOS enz. kant en klare configuraties en packages exporteren per gebruiker. Die stuur je dan naar de persoon die moet verbinden en die kan dan met een paar klikken de VPN client + juiste configuratie gebruiken. Moet natuurlijk wel met eigen username en password inloggen. Je kan interne authenticatie gebruiken door lokaal gewoon users toe te voegen, maar je kan het ook aan Active Directory koppelen waardoor mensen hun bestaande accounts kunnen gebruiken.

[renevanh]

Met al jullie tips nog wat zitten knoeien en het werkt!
Waar het nou precies misging weet ik niet, in feite heb ik weinig tot niets in de configuratie veranderd...

Ik kan zowel het 10.8.0.1 als het 192.168.178.19 adres (beide van de VPN server) pingen, dus dat is een hele fijne stap in de richting! Ik moest daar nu op de server wel nog het openbaar profiel van Windows Firewall voor uitzetten, maar dat los ik later wel weer op.

Na een edit van de hosts file werkt pingen op NetBIOS naam ook, volgens mij gaan we er komen!

Nu testen met de laptop van de klant, want daar draait de 2de licentie van de software al op.

[ Voor 18% gewijzigd door renevanh op 24-01-2016 12:46 ]

[renevanh]

Nou, het werkt!

Enige nadeeltje is dat beide netwerken op 192.168.178.0 blijken te draaien, dus geen internet als de VPN actief is bij de client.
Eentje ombouwen dus