Check alle échte Black Friday-deals Ook zo moe van nepaanbiedingen? Wij laten alleen échte deals zien
Toon posts:

DD-WRT PPTP VPN-probleem

Pagina: 1
Acties:

Vraag


Verwijderd

Topicstarter
Opmerking vooraf: We proberen op een boerderij een stal op afstand te verbinden met de hoofdlocatie. We zijn dus niet bezig met een VPN op te zetten voor illegale activiteiten.

Op de hoofdlocatie draait een systeem wat een aantal stations uitleest die RFID-halsbanden van koeien uitleest. Deze stations moeten allemaal in hetzelfde subnet/broadcast-domain zitten om met elkaar te communiceren. (ja, ik weet dat het geen best-practice is om broadcast-verkeer over een VPN te sturen. Maar deze apparatuur kan niet op een andere manier functioneren)

Wat we tot nu toe geprobeerd hebben:

Op de hoofdlocatie staat een router met DD-WRT. Op deze router is de PPTP-server geactiveerd. Voor de routing hebben we de volgende route toegevoegd:
In Dest. LAN IP: 10.0.0.1
Subnetmask : 255.255.255.255
Gateway : 0.0.0.0
Interface : LAN/WLAN
Deze router is getest door er met een Windows-laptop mee te verbinden. Dat werkte. Aan de serverkant lijkt dus alles goed ingesteld, en staan alle poorten naar buiten correct open. Ik ga er dus van uit dat de fout in de andere router zit.

Op de sublocatie staat een LTE-router, met daarachter een tweede router met DD-WRT. Op deze router is de PPP-client ingesteld volgens deze handleiding

Omdat we willen dat alle apparatuur achter deze DD-WRT-router via de PPTP-verbinding loopt hebben we de instellingen de volgende instellingen toegevoegd:
#!/bin/sh
sleep 120
PPTPSERVER=$(/usr/sbin/nvram get pptpd_client_srvip)
PPTPGWY=$(/usr/sbin/nvram get wan_gateway)
/sbin/route add -host $PPTPSERVER gw $PPTPGWY dev vlan2
/sbin/route del default
/sbin/route add default dev ppp0
iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE
Desondanks lukt het ons niet om verbinding te krijgen met het VPN via de DD-WRT-router. Wat doen we fout ?

Alle reacties


  • boyette
  • Registratie: November 2009
  • Laatst online: 23:19
Verwijderd schreef op vrijdag 15 december 2017 @ 18:12:
(ja, ik weet dat het geen best-practice is om broadcast-verkeer over een VPN te sturen. Maar deze apparatuur kan niet op een andere manier functioneren)
Ondanks dat het vast wel op te lossen is..

Betwijfel ik dit ten zeerste..
En lijkt het mij juist onnodig gecompliceerd x10

  • johnkeates
  • Registratie: Februari 2008
  • Laatst online: 04-07 16:30
Wat je wil kan niet met PPP of PPTP, daarnaast ga ik niemand helpen om anno 2017 nog PPTP op te zetten.

Je hebt trouwens L2 tunnels nodig om broadcast mee te pakken, of je moet het bi-directioneel herschrijven om een soort cross-broadcast-multicast in elkaar te klussen, maar dat lijkt me geen goed plan.

Opties:

- Non-VPN techniek gebruiken, bijv. Ethernet-over-IP om een groot Ethernet netwerk te maken
- VXLANs
- MPLS
- OpenVPN in TAP mode en interfaces simpelweg bridgen, en als qua crypto niet uit kan met brakke MIPS hardware kan je dat altijd nog op arc4 zetten ofzo ;-)

Eigenlijk is dit niet iets wat je met basic MIPS/ARM hardware en DD-WRT moet willen oplossen.

  • Thralas
  • Registratie: December 2002
  • Laatst online: 16:17
In ieder geval vertel je ons niet zien wat je wel ziet, behalve 'werkt niet'. Is er iets terug te vinden van het opzetten van een verbinding, aan de server- of clientkant?
johnkeates schreef op vrijdag 15 december 2017 @ 18:18:
Wat je wil kan niet met PPP of PPTP, daarnaast ga ik niemand helpen om anno 2017 nog PPTP op te zetten.
Eens.

Ik vermoed dat PPTPs GRE niet door de LTE router raakt, dus dan gaat de tunnel zelf sowieso nooit werken.
- OpenVPN in TAP mode en interfaces simpelweg bridgen, en als qua crypto niet uit kan met brakke MIPS hardware kan je dat altijd nog op arc4 zetten ofzo ;-)
Dat lijkt me de meest voordehandliggende optie voor TS. OpenVPN in TAP mode met een static key is zo opgezet...

EDIT: Of iets als ZeroTier. Simpeler kan niet.
Eigenlijk is dit niet iets wat je met basic MIPS/ARM hardware en DD-WRT moet willen oplossen.
Mwah, zo heel veel verkeer hoeft er waarschijnlijk ook niet overheen toch? Grote kans dat het prima werkt.

[ Voor 3% gewijzigd door Thralas op 15-12-2017 18:48 ]


  • DJSmiley
  • Registratie: Mei 2000
  • Laatst online: 13-11 18:21
Je kan zoiets ook met een paar Mikrotikjes voor elkaar krijgen. Eventueel een LTE Mikrotik of eentje met een USB dongle, dan ben je ook van 2 losse dingen af.

SSTP, L2TP of IPSec tunnel maken tussen beide lokaties (Waarbij je met SSTP ook eigenlijk nooit problemen hebt met firewalls - het gaat gewoon encrypted over poort 443), en daarover een EoIP tunnel.

Met L2TP kun je IPSec gebruiken, met SSTP certificaten.

Dan heb je gewoon een lange netwerkkabel op L2 nivo.

https://wiki.mikrotik.com/wiki/Manual:Interface/EoIP

https://mum.mikrotik.com/...ation_2962_1445240964.pdf

Verwijderd

Topicstarter
Thralas schreef op vrijdag 15 december 2017 @ 18:31:
[...]


In ieder geval vertel je ons niet zien wat je wel ziet, behalve 'werkt niet'. Is er iets terug te vinden van het opzetten van een verbinding, aan de server- of clientkant?
Als we de actieve connecties bekijken, zijn er op de thuisrouter inkomende verbindingen te zien, en op de router op de hoofdlocatie inkomende verbindingen vanaf het externe adres op de LTE-router. Er lijken dus wel verbindingen opgebouwd te worden, maar loopt geen verkeer over.
[...]


Eens.

Ik vermoed dat PPTPs GRE niet door de LTE router raakt, dus dan gaat de tunnel zelf sowieso nooit werken.
De poorten zijn opengezet, en aan beide kanten wordt niet gefilterd op GRE.
[...]


Dat lijkt me de meest voordehandliggende optie voor TS. OpenVPN in TAP mode met een static key is zo opgezet...
[...]
Mwah, zo heel veel verkeer hoeft er waarschijnlijk ook niet overheen toch? Grote kans dat het prima werkt.
Het was vanwege dat laatste, niet veel verkeer, dat OpenVPN juist overkill leek. Het gaat om communicatie via een Canbus-over-ethernet-protocol, en dat is maximaal 125 kbit per seconde. Er hangen niet bepaald iets veeleisends achter.
DJSmiley schreef op vrijdag 15 december 2017 @ 18:48:
Je kan zoiets ook met een paar Mikrotikjes voor elkaar krijgen. Eventueel een LTE Mikrotik of eentje met een USB dongle, dan ben je ook van 2 losse dingen af.

SSTP, L2TP of IPSec tunnel maken tussen beide lokaties (Waarbij je met SSTP ook eigenlijk nooit problemen hebt met firewalls - het gaat gewoon encrypted over poort 443), en daarover een EoIP tunnel.

Met L2TP kun je IPSec gebruiken, met SSTP certificaten.

Dan heb je gewoon een lange netwerkkabel op L2 nivo.

https://wiki.mikrotik.com/wiki/Manual:Interface/EoIP

https://mum.mikrotik.com/...ation_2962_1445240964.pdf
Voor EoIP begrijp ik dat voor een werkende verbinding er aan 2 kanten een publiek IP-adres moet zijn. De LTE-verbinding is echter Carrier-Grade-NAT. Dat zou dus niet gaan werken ?

  • DJSmiley
  • Registratie: Mei 2000
  • Laatst online: 13-11 18:21
Verwijderd schreef op vrijdag 15 december 2017 @ 18:58:


Voor EoIP begrijp ik dat voor een werkende verbinding er aan 2 kanten een publiek IP-adres moet zijn. De LTE-verbinding is echter Carrier-Grade-NAT. Dat zou dus niet gaan werken ?
Hoeft niet. EoIP vereist 2 connected IP adressen. Maar dat kan ook binnen een tunnel.

Een SSTP client of L2TP client in de LTE kant werkt prima, je kan een EoIP tunnel *in* een L2TP of SSTP tunnel bouwen.

Met een Mikrotik kun je het zelfs nog gekker maken, en een 2e LTE router ernaast zetten, via een andere provider, en dan met OSPF je handel redundant maken 8)7, zelfs achter NAT.
Zolang je 'server' kant maar een publiek IP heeft zal een client connecten, al is het 3-dubbel-achter-NAT.

Ik heb een klant wel eens een publiek /29 subnet uit NL gegeven, via een L2TP verbinding naar een lokatie in Zuid-Afrika

  • laurens0619
  • Registratie: Mei 2002
  • Laatst online: 23:00
Inderdaad, koop 2x een mikrotik van 30 euro per stuk pricewatch: MikroTik RouterBoard RB941-2nD - hAP Lite

Instellen is echt in 5 minuten gedaan.
Eerst een link opbouwen via pptp/l2tp en daarna de eoip eraan knopen. Laatste stap is een switch poort er aan toekennen. Makeijker en goedkoper dan dit gaat m niet worden.

Heb het zelf ook een keer ingesteld en draait perfect! (Gebruikte het voor tv decoder op andere locatie)

Afbeeldingslocatie: https://2.bp.blogspot.com/-G-v0uLsJwKM/U4L7sS9tZLI/AAAAAAAAAFc/U8QOAJ8EKd4/s1600/procaster_eoip_pptp_bridge.png

[ Voor 15% gewijzigd door laurens0619 op 16-12-2017 16:33 ]

CISSP! Drop your encryption keys!


  • shure-fan
  • Registratie: Maart 2002
  • Laatst online: 20:58
3 topics van de ts die over hetzelfde onderwerp gaan,

Met de spullen die je nu hebt (ddwrt gebaseert) kun je toch eerst thuis bezig gaan om een tap verbinding op te zetten via openvpn?

Als dat eenmaal werkt verplaats je de boel naar je remote side

Enige waar je je druk om moet maken bij de tap vpn is dat je certificaten aan moet maken op een pc, wellicht dat je daar even een avondje zoet mee bent (ook kwa inlezen hoe het moet)

Voip enthousiastelling, Liever een kabel dan wifi


  • Thralas
  • Registratie: December 2002
  • Laatst online: 16:17
shure-fan schreef op zaterdag 16 december 2017 @ 16:48:
Met de spullen die je nu hebt (ddwrt gebaseert) kun je toch eerst thuis bezig gaan om een tap verbinding op te zetten via openvpn?
Ja. Lijkt me zonde om extra hardware te kopen. En dat zeg ik als MikroTik fanboy.
Enige waar je je druk om moet maken bij de tap vpn is dat je certificaten aan moet maken op een pc, wellicht dat je daar even een avondje zoet mee bent (ook kwa inlezen hoe het moet)
Zelfs dat hoeft niet. Je kunt ook shared secret mode gebruiken (--secret), perfect voor site to site VPNs en dan komt er geen PKI aan te pas.

En de oplossing uit m'n edit (Zerotier) belooft hetzelfde, maar dan met vrijwel 0 configuratie. Volgens mij zijn er packages voor OpenWRT/LEDE, lijkt me dat het er dan ook wel is voor dd-wrt..

  • shure-fan
  • Registratie: Maart 2002
  • Laatst online: 20:58
@Thralas extra hardware is ook niet nodig,

Wat ik echter zie en mis: ts gooit er een hoop scriptjes en weet ik het tegenaan om "maar te hopen" dat het werkt, en zo werkt het niet...

Wat ik mis is een echt stukje diagnose van het probleem

@Verwijderd kijk eens op de forums van ddwrt en dan met name het subforum :advanced networking,
Daar staan genoeg praktijk voorbeelden die wel werken, en je kunt je vragen er stellen
( en lees je in over de materie, zomaar wat scriptjes gooien uit handleidingen van vpn providers werkt niet voor jou situatie aangezien elke situatie uniek is)

Nogmaals: openvpn tap instellen, een static key zou kunnen, echter ben ik meer een fan van aparte certificaten+tls

Ik zeg er eerlijk bij, ik heb in het verleden ook een tap verbinding werkend gehad via ddwrt maar weet niet meer hoe ik dat had (ben wel van plan dit weer te gaan doen)

Voip enthousiastelling, Liever een kabel dan wifi


Verwijderd

Verwijderd schreef op vrijdag 15 december 2017 @ 18:58:
Het gaat om communicatie via een Canbus-over-ethernet-protocol, en dat is maximaal 125 kbit per seconde. Er hangen niet bepaald iets veeleisends achter.
Behalve dan dat het geen IP is, maar "canbus-over-ethernet". Je VPN endpoints hoeven geeneens interne IPadressen te hebben, zolang ze maar ethernet frames naar het andere endpoint verschepen.

*zoeken doet* Ik dacht al dat deze vraag me bekend voorkwam. En je melkkastjes spreken dus inderdaad geen Internet Protocol.
Voor EoIP begrijp ik dat voor een werkende verbinding er aan 2 kanten een publiek IP-adres moet zijn. De LTE-verbinding is echter Carrier-Grade-NAT. Dat zou dus niet gaan werken ?
CGNAT is altijd goed om te vermijden, maar EoIP betekent zoveel als "we verschepen Ethernet Frames ongeacht of daar IP of wat anders in zit".

Dit in contrast met het verschepen van uit zulke frames uitgepakte IP paketten, zoals de meeste "standaard" VPN opzetten doen, want de extra data voegt meestal niets toe. Hoe dat precies te doen, dus wat voor tunnel je ervoor gebruikt, daar heb je meerdere opties voor.
Pagina: 1