Eigen vpn-server met DD-WRT Router

[bruma]

ik heb een PPTP opgezet achter een gateway op een asusrouter (in de range van de gateway) en heb vpn ter beschikking.
asus router werkt met tomatousb en niet al teveel problemen gehad om het geheel in te stellen.
Is wel de bedoeling om over te stappen naar openvpn echter de instellingen zijn daar moeilijker en ik wou eerst eens kijken wat de mogelijkheden waren van vpn en of die wel zo makkelijk van overal toegankelijk was.

[smikkeltjen]

Ik heb zojuist OpenVPN even geprobeerd (via deze uitleg), maar telkens krijg ik vanop de client een connection timeout. Niet veel beterschap dus en werken met certificaten voor elke client is ook niet echt optimaal voor mijn situatie.
Als een overstap naar Tomato het probleem zou kunnen oplossen, wil ik die gerust wel nemen.
Weet je toevallig nog de uitleg staan die je gehanteerd hebt?

[ubremoved_2964]

Routes worden niet gepushed via DHCP... enkel een default gateway.

Duidelijk een KMO prutser met geen expert kennis.
https://ercpe.de/blog/advanced-dhcp-opt ... to-clients

[ubremoved_539]

Duidelijk een KMO prutser met geen expert kennis.

Ik beweer ook nergens een netwerk expert te zijn... networking is zelfs m'n job niet.

In ieder geval als ik connecteer naar m'n VPN server thuis dan krijgt m'n PC gewoon netjes een IP-adres in m'n eigen LAN... ik zie dus zelfs niet in waarom ik dan extra routes zou nodig hebben (tenzij ik thuis meerdere subnets zou hebben maar dat werkt zo ie zo al niet - los van de VPN - bij een HGW).

[ubremoved_2964]

Je kan in theorie je vpn server op een andere node dan je router in je LAN draaien, je bent niet verplicht om die op je home router te draaien, maar dat maakt het wel makkelijker. Ik draai openvpn ook op mijn dd-wrt, maar dat is niet verplicht.

Op een andere node draaien zal als gevolg hebben, dat alle subnetten die bereikbaar zijn via de VPN, op alle clients zullen geïnstalleerd worden via een manuele route of via dhcp opties. Deze andere node is dan de gateway naar de VPN ranges.

Net zoals je op één LAN ook meerdere gateways kan hebben, ik heb thuis bvb een gateway naar telenet, en eentje naar een wireless isp.

[ubremoved_539]

Ik draai openvpn ook op mijn dd-wrt, maar dat is niet verplicht.

Niet verplicht maar 99% van de huis-tuin-keuken setups zijn wel zo... en daar heb je bij TN geen last van.

Op een andere node draaien zal als gevolg hebben, dat alle subnetten die bereikbaar zijn via de VPN, op alle clients zullen geïnstalleerd worden via een manuele route of via dhcp opties. Deze andere node is dan de gateway naar de VPN ranges.

Waarom zou je manuele routes nodig hebben... het is je router die de routes moet kennen... je client heeft enkel één gateway nodig om de router te bereiken. Hier heb je bij TN (en bij alle providers die NAT doen) wel een probleem omdat de router functionaliteit in hun toestel zit en je daar geen (static) routes kan bijmaken.

Net zoals je op één LAN ook meerdere gateways kan hebben, ik heb thuis bvb een gateway naar telenet, en eentje naar een wireless isp.

Dat is een keuze... maar op zich niet noodzakelijk... één gateway naar je router is voldoende (die zal dan wel routen naar de juiste interface op basis van de juiste criteria). Ik kan me trouwens niet herinneren ooit al een LAN (waar clients op zitten) gezien te hebben met meerdere gateways in professionele omgevingen.

Los van dit alles... er zijn genoeg mensen die OpenVPN draaien bij TN met een HGW... je opmerking was dus eerder provider bashing.

[ubremoved_2964]

Los van dit alles... er zijn genoeg mensen die OpenVPN draaien bij TN met een HGW...

Openvpn Client gaat rats doorheen NAT en port forwarding, zelf nog ooit opgezet om in frankrijk hadopi te omzeilen, hotel had enkel poort 443 allowed en niet poort 1194, dus op een vrije node in het datacenter een port forward opgezet van poort 443 naar de doos ernaast die openvpn draaide op 1194.

Dus in principe werkt een port forward vanaf de TN home router naar je eigen router daar net achter ook normaal zonder problemen.

[smikkeltjen]

Het enige wat me met die public ip lukt, is pingen indien het apparaat waarvan de ip in DMZ staat (bijvoorbeeld een nas die op de gateway aangesloten is) ingeschakeld is.
Indien ik die nas dan uitschakel, verschijnt bij het pingen "destination host unreachable" (normaal dus).
Hetzelfde geldt voor de DD-WRT indien hij uitgeschakeld is: indien zijn ip in DMZ staat, verschijnt "destination host unreachable" bij het pingen.
Nu de DD-WRT als Client Bridge ingesteld staat (door die tutorial uit mijn eerste bericht), en zijn local ip niet meer te vinden is in de lijst met geconnecteerde toestellen op Mijn Telenet, had ik verwacht dat de DD-WRT zo goed als onbestaande zijn voor de TN-gateway.
Toch verschijnt bij een ingeschakelde DD-WRT bij het pingen iets anders: "request timed out".
Waar zou dit op kunnen wijzen?
Voor alle duidelijkheid: het pingen gebeurde telkens vanop een hotspot op mijn gsm.

Mocht ik dit fenomeen kunnen oplossen, kan ik mischien toch voort met OpenVPN.
Ondertussen is de DD-WRT al gereset en is zijn WAN-ip in DMZ op de HGW ingevuld, maar het fenomeen blijft aanhouden:

• uitgeschakeld: destination host unreachable
• ingeschakeld: request timed out

Met de nas ingeschakeld lukt pingen wel gewoon.
Hoe kan dat nu?

[Sasuke]

Begin al eens met een tekeningetje en wat IP adressen, dan kunnen we volgen want met ''het werkt niet' zijn we niet veel he.

[ubremoved_539]

Openvpn Client gaat rats doorheen NAT en port forwarding, zelf nog ooit opgezet om in frankrijk hadopi te omzeilen, hotel had enkel poort 443 allowed en niet poort 1194, dus op een vrije node in het datacenter een port forward opgezet van poort 443 naar de doos ernaast die openvpn draaide op 1194.

Dus in principe werkt een port forward vanaf de TN home router naar je eigen router daar net achter ook normaal zonder problemen.

Dan begrijp ik niet dat je op de vorige pagina nog het volgende schrijft... waar dat totaal niet nodig is.

Conclusie: gooi die achterlijke big brother buiten en ga voor een modem only.

[Garpenlov]

Dan begrijp ik niet dat je op de vorige pagina nog het volgende schrijft... waar dat totaal niet nodig is.

Conclusie: gooi die achterlijke big brother buiten en ga voor een modem only.

Een echte netwerk expert zoals ub4b plakt op elke router en server tin-folie, om straling & de Amerikaanse regering weg te houden!

[smikkeltjen]

Begin al eens met een tekeningetje en wat IP adressen, dan kunnen we volgen want met ''het werkt niet' zijn we niet veel he.

[ITnetadmin]

Normaal doen enkel routers de routing.
Enfin, en tegenwoordig ook de layer3 switches.

Meerdere routes instellen is eerder een techniek voor bepaalde toestellen die routes moeten hebben die de rest niet mag krijgen. Eerder voor testing dus, of een specifiek toestel dat een apart netwerk moet bereiken.

Sommige (kleinere) routers hebben wel last met static routes die via hun LAN poorten gaan ipv hun WAN poort.

[ubremoved_539]

In een TN HGW kan je volgens mij maar één toestel in de DMZ zetten... en ik zie zowel je NAS als DD-WRT in de DMZ staan volgens je tekening ?

Wat doet die andere DD-WRT daar trouwens ? Wat heb je van NAS... heeft die geen VPN mogelijkheden ?

[smikkeltjen]

In een TN HGW kan je volgens mij maar één toestel in de DMZ zetten... en ik zie zowel je NAS als DD-WRT in de DMZ staan volgens je tekening ?

Wat doet die andere DD-WRT daar trouwens ? Wat heb je van NAS... heeft die geen VPN mogelijkheden ?

Dan moest ik 3 tekeningen maken, telkens met de DMZ op één van die toestellen ingesteld.
Die 2e DD-WRT is om het IP aan te duiden toen die (dezelfde DD-WRT dus) nog als client ingesteld stond en om te duiden dat pingen toen ook iets anders aangaf dan het gebruikelijke "reply from" of "destination host unreachable".
De Nas is een Lacie Cloudbox en heeft bij mijn weten dus geen VPN-mogelijkheden.

[ubremoved_539]

Weet wel dat aanpassingen via MIjn Telenet even in beslag kunnen nemen... meteen testen kan dus "foutieve" resultaten geven.

Pings (ICMP echo replies) kunnen trouwens afzonderlijk gefilterd worden... dat een ping dus niet werkt zegt niet veel.

[Sasuke]

Waar staat je PC op de tekening (achter welke router) en welk IP adres heeft de PC vanwaar je de testen doet ? Als je op het 192.168.1.1 netwerk zit, dan is het inderdaad vrij logisch dat die pingtesten niet werken.

[smikkeltjen]

Waar staat je PC op de tekening (achter welke router) en welk IP adres heeft de PC vanwaar je de testen doet ? Als je op het 192.168.1.1 netwerk zit, dan is het inderdaad vrij logisch dat die pingtesten niet werken.

Het enige wat me met die public ip lukt, is pingen indien het apparaat waarvan de ip in DMZ staat (bijvoorbeeld een nas die op de gateway aangesloten is) ingeschakeld is.
Indien ik die nas dan uitschakel, verschijnt bij het pingen "destination host unreachable" (normaal dus).
Hetzelfde geldt voor de DD-WRT indien hij uitgeschakeld is: indien zijn ip in DMZ staat, verschijnt "destination host unreachable" bij het pingen.
Nu de DD-WRT als Client Bridge ingesteld staat (door die tutorial uit mijn eerste bericht), en zijn local ip niet meer te vinden is in de lijst met geconnecteerde toestellen op Mijn Telenet, had ik verwacht dat de DD-WRT zo goed als onbestaande zijn voor de TN-gateway.
Toch verschijnt bij een ingeschakelde DD-WRT bij het pingen iets anders: "request timed out".
Waar zou dit op kunnen wijzen?
Voor alle duidelijkheid: het pingen gebeurde telkens vanop een hotspot op mijn gsm.

Mocht ik dit fenomeen kunnen oplossen, kan ik mischien toch voort met OpenVPN.
Ondertussen is de DD-WRT al gereset en is zijn WAN-ip in DMZ op de HGW ingevuld, maar het fenomeen blijft aanhouden:

• uitgeschakeld: destination host unreachable
• ingeschakeld: request timed out

Met de nas ingeschakeld lukt pingen wel gewoon.
Hoe kan dat nu?

[Sasuke]

Ondanks het feit dat ik mezelf in staat acht om zoiets op 10 minuten te fixen, snap ik echt geen bal van wat je neerschrijft

Kan je het volgende doen:

1. Beschrijf de actuele situatie hoe alles geconnecteerd is en welke IP's ze hebben.
2. Stop met het gebruik van de termen publiek IP en dmz, want je weet niet wat ze betekenen en je maakt het alleen maar moeilijker
3. In jouw geval, als een Ping niet werkt heb je een routing of firewall issue. De foutmelding die je krijgt is eigenlijk niet belangrijk, zeker niet omdat we niet zien wat je Source IP en destination is
4. Stop met experimenteren, wat je wil doen is eigenlijk enorm eenvoudig.
5. Maak een tekeningetje van hoe jij denkt wat de to-BE situatie moet zijn of hoe je ze zou willen.

Succes !

[smikkeltjen]

Dit huidige situatie is dus als volgt:

PC (verbonden met 3G)
ip: 188.189.30.205

TN Home Gateway
WAN-ip: 86.128.76.210
LAN-ip: 192.168.0.1
verbonden met DD-RT

DD-WRT
(verbonden met Gateway dus)
WAN-ip: 192.168.0.200
LAN-ip: 192.168.1.1
VPN-server ip: 192.168.1.100

De bedoeling is dus om vanop de pc (188.189.30.205) vpn-connectie te maken met de VPN-server (192.168.1.100)

[Sinna]

Op basis van de huidige situatie zoals door TS geschetst:

• In Mijn Telenet een port forward instellen voor 1194/udp naar 192.168.0.200. DMZ is niet nodig!
• Op de PC die via 3G verbonden is, de VPN-verbinding initiëren naar 86.128.76.210

Het LAN-gedeelte van de DD-WRT wordt niet gebruikt.
Door de port forward in te stellen krijg je géén toegang tot de web interface van de DD-WRT, tenzij via VPN verbonden.

[Sasuke]

Lijkt me nog altijd niet de volledige situatie ? Waar staat de NAS en met welk IP ? Als je de vpn verbinding zoals hierboven beschrijft ga je waarschijnlijk enkel toegang krijgen tot resources in het LAN gedeelte van je router waar vermoedelijk niks staat ?

Dus graag even puntje 1 en 5 herlezen van mijn eerdere post en de volledige informatie bezorgen. En just FYI ... Over 3G en met VPN ga je niet veel kunnen doen hoor of is dat om te testen thuis ?

[smikkeltjen]

Lijkt me nog altijd niet de volledige situatie ? Waar staat de NAS en met welk IP ? Als je de vpn verbinding zoals hierboven beschrijft ga je waarschijnlijk enkel toegang krijgen tot resources in het LAN gedeelte van je router waar vermoedelijk niks staat ?

Van zodra de VPN-verbinding in de situatie zoals hierboven beschreven lukt, is mijn probleem opgelost en moet ik enkel nog de toestellen die ik wil bereiken op de DD-WRT aansluiten hé. Of komt er toch meer bij kijken?

Over 3G en met VPN ga je niet veel kunnen doen hoor of is dat om te testen thuis ?

Dat was inderdaad gewoon om te testen. Verbinden via Wifree, Homespot, netwerk buren... had ik ook kunnen doen

Op basis van de huidige situatie zoals door TS geschetst:

• In Mijn Telenet een port forward instellen voor 1194/udp naar 192.168.0.200. DMZ is niet nodig!

En wat als ik toch (als was het maar tijdelijk) met PPTP wil werken i.p.v. met OpenVPN?
(De server stond eigenlijk daar al terug op ingesteld via de tutorial uit mijn eerste post)
Of gaat dat niet lukken?

[Sasuke]

Dan zou ik het inderdaad gewoon doen zoals hierboven. OpenVPN activeren op je DD-WRT, juiste poort(en) openzetten op MijnTelenet (geen DMZ gebruiken). En dan connecteren naar het WAN IP van je TelenetModem.

Je zou dan op je client/PC een IP adres moeten krijgen in het LAN gedeelte van je DD-WRT (192.168.1.1) en dan moet je naar alles kunnen connecteren dat achter je router staat.

Succes !

[smikkeltjen]

Dat had ik al geprobeerd enkele posts geleden, exact zoals beschreven hierboven (op het gebruik van dmz na omdat ik niet wist wat nu de juiste poorten waren om te forwarden), maar zonder succes.
En dan zou ik ook nog een manier moeten vinden om in te loggen met gebruikersnaam en wachtwoord i.p.v. met certificaten.

[Sasuke]

'Wat werkte er niet' ..; kreeg je een error in de VPN client, of kon je wel verbinden maar kreeg je geen IP of kon je niet naar je NAS ... ??

Echt man ... je hebt nu al een hoop posts geschreven maar nooit geef je de volledige informatie. Just a quick question, wanneer je die PC met je GSM verbind (3G) kan je dan surfen over 3G met die PC, én is hij zeker niet meer verbonden (met kabel) met je thuisnetwerk hé ?

In ieder geval ... honderden UB'ers zijn je al voorgegaan en in weze is OpenVPN hetzelfde qua setup (voor Telenet) als dat je een webserver naar buiten toe wil exposen.

[smikkeltjen]

In de desbetreffende post (open linkje) had ik gezegd dat de client (188.189.30.205, dus zeker niet verbonden met het thuisnetwerk) bij het verbinden telkens een connection time-out geeft. Ik weet dat dit heel vaag is, maar meer gedetailleerde kan ik in de logs ook niet vinden. Het feit dat er een connection time-out optreedt en niet iets dat explicitiet duidt op de VPN-server die onvindbaar is, deed mij gewoon denken aan het pingen dat ook een time-out geeft in plaats van "destination host unreachable", maar dat heeft klaarblijkelijk alleen maar voor verwarring gezorgd.

Mijn vraag is dus waar ik de relevante info (op de vpn-client of eventueel op de server) kan vinden om te achterhalen wat er fout gaat, want aan de opstelling zelf lijkt mij niks verkeerd

[Sasuke]

als ge die fout krijgt, staat de poort niet open. Is de poort effectief geforward naar het WAN IP van je DD-WRT ? (dus het 0.200 adres ... ? zeker niet 1.100 hé !)

[smikkeltjen]

Dat is zeker in orde.
Kan het misschien niet aan de sleutels liggen? Want de uitleg doet hier iets raars naar mijn mening.

Links is wat de uitleg zegt dat je moet ingeven in de velden, rechts zijn de velden die bij mij beschikbaar zijn.
En dit zijn de bestanden met sleutels die ik heb:

• ca.crt
• ca.key
• dh1024.pem
• client.crt
• client.csr
• client.key
• server.crt
• server.csr
• server.key

Iemand die weet wat waar moet ingegeven worden, of is het zoals het links staat toch juist?

[Sasuke]

CA cert ==> ca.crt
Public Server cert ==> server.crt
Private key ==> server.key
DH PEM ==> dh1024.pem

That's it ... de client.crt en client.key heb je nodig op je PC in de OpenVPN client.

[Sasuke]

Maar als het certificate gebonden zou zijn dan zou ofwel de OpenVPN daemon niet starten op je router (en komt de poort niet open), of ga je op client foutmeldingen krijgen ivm. certificaten (en dus niet connection timed out).

Nu, dat je een timeout krijgt ipv refused wil bedoelen dat de poort openstaat op je Telenet router, maar zegt dus niks over je DD-WRT. Die heeft ook een firewall, zet die automatisch de OpenVPN poort open in de firewall als je OpenVPN Daemon inschakelt (geen flauw idee ...)

[smikkeltjen]

We zijn al een stapje dichterbij denk ik : de OpenVPN GUI op de client pc (mijn pc die met het 3G-netwerk verbonden is ) maakt al verbinding met de VPN-server (als ik de DD-WRT uitschakel, wordt de verbinding meteen verbroken, dus da lijkt mij ok).
Het probleem was dat bij OpenVPN Config (waar op de linkse foto "see below" staat, naar het TCP-protocol werd gevraagd, terwijl ik op alle andere plaatsen UDP had ingevuld.
Toch duikt er weer een nieuw probleem op: bij de verbinding verschijnt: "toegewezen ip is 10.8.0.6" en wanneer ik mijn ip opzoek (via whatsmyip ofzo), staat er nog altijd 188.189.30.205 (de ip van mijn gsm).
Die 10.8.0.6 is blijkbaar iets van OpenVPN zelf.
Moet ik hieronder de logs plaatsen?

[Sasuke]

Dat IP kan correct zijn hoor. Je zou nu naar het 192.168.1.0 netwerk moeten kunnen verbinden. Probeer eens te pingen naar je NAS ?

[smikkeltjen]

Zoals verwacht geeft pingen naar de nas een time-out.
Omdat ik op mijn pc geen nieuwe netwerkadapter zie (wat normaal wel moet denk ik, of niet?) heb ik geprobeerd mijn gsm als client te gebruiken via de openVPN-applicatie. De verbinding wordt tot stand gebracht en het VPN-teken verschijnt bovenaan mijn scherm, maar nog steeds is mijn ip (via whatsmyip) 188.189.30.205. In de applicatie zelf staat:

• VPN IPv4: 10.8.0.6
• VPN IPv6: leeg
• user: leeg
• client IP: leeg
• server: 86.128.76.210
• server IP: 86.128.76.210
• port: 1194
• Protocol: UDPv4

Zou de fout niet weer in OpenVPN Config op de DD-WRT verscholen zitten? Dit is wat er momenteel in staat:

push &#-109;route 192.168.1.1 255.255.255.0&#-108;
server 10.8.0.0 255.255.255.0

dev tun0
proto udp
keepalive 10 120
dh /tmp/openvpn/dh.pem
ca /tmp/openvpn/ca.crt
cert /tmp/openvpn/cert.pem
key /tmp/openvpn/key.pem

# Only use crl-verify if you are using the revoke list &#-106; otherwise leave it commented out
# crl-verify /tmp/openvpn/ca.crl

# management parameter allows DD-WRT&#-110;s OpenVPN Status web page to access the server&#-110;s management port
# port must be 5001 for scripts embedded in firmware to work
management localhost 5001

De configuratie van de client is

client
dev tun
proto udp
remote 86.128.76.210 1194
resolv-retry infinite
nobind
persist-key
persist-tun
ca ca.crt
cert client.crt
key client.key
remote-cert-tls server
comp-lzo
verb 3

[Sasuke]

Wat je zie op je client is normaal. Dat het IP nog dat van je 3G is, is omdat je OpenVPN in SplitTunnel staat by default en dan moeten de VPN routes gedefinieerd worden (in leken termen). Echter is de route inderdaad niet goed gedefinieerd, staan precies wat rare tekens in de config.

Vervang push &#-109;route 192.168.1.1 255.255.255.0&#-108; door
push "route 192.168.1.0 255.255.255.0" (opgelet! quotes) of gewoon route 192.168.1.0 255.255.255.0 (zonder quotes)

en probeer opnieuw.

[smikkeltjen]

Bij de Firewall commands op de DD-WRT heb ik ook die speciale tekens

Code: Selecteer alles

iptables -I INPUT 1 -p udp &#-106;dport 1194 -j ACCEPT
iptables -I FORWARD 1 &#-106;source 192.168.1.0/24 -j ACCEPT
iptables -I FORWARD -i br0 -o tun0 -j ACCEPT
iptables -I FORWARD -i tun0 -o br0 -j ACCEPT

Vervangen door...?

Code: Selecteer alles

iptables -I INPUT 1 -p udp dport 1194 -j ACCEPT
iptables -I FORWARD 1 source 192.168.1.0/24 -j ACCEPT
iptables -I FORWARD -i br0 -o tun0 -j ACCEPT
iptables -I FORWARD -i tun0 -o br0 -j ACCEPT

In ieder geval, mocht het hierna nog steeds niet werken, is het misschien beter dat ik het maar voor beken houdt.
Iedereen, Sasuke in het bijzonder, ontzettend bedankt voor het mee helpen denken en het eindeloze geduld dat jullie met mij gehad hebben.
Mijn manier van uitleggen was achteraf gezien niet overal even duidelijk, waarvoor mijn oprechte excuses.

Groetjes en heel veel succes toegewenst met het bieden van hulp bij de iets (waarschijnlijk veel) nuttigere vragen dan de mijne
smikkeltjen

[Sasuke]

ja ik zou dat doen. Je hebt die dingen vermoedelijk vanaf een webpagine gecopieerd en dan durft er al wel eens een vertaling gebeuren