OpenVPN op de NAS, maar alleen de NAS is bereikbaar

[M.v.Veelen]

Hoi,

ik ben al dagen zoet met het volgende probleem: op mijn NAS (iX2) heb ik OpenVPN geïnstalleerd. Certificaten en keys aangemaakt en de openvpn.conf file zoveel mogelijk ingesteld zoals ik denk / dacht dat het moest.

Ik kan nu een VPN verbinding maken naar de NAS, maar ik kan alleen maar de NAS zelf bereiken (FTP, webpagina, pingen). Alle andere interne IP adressen kan ik niet bereiken, en ook heb ik geen internetverbinding als de VPN connectie is gemaakt.

De situatie:

NAS: 192.168.0.124
Router: 192.168.0.1
Poort 443
UDP

UDP gebruik ik omdat over TCP het al niet lukte om een verbinding te maken. Eerst maar eens kijken of het wil lukken om de rest van de interne IP adressen en internet te kunnen benaderen.

Inhoud openvpn.conf file:

code:

#Which TCP/UDP port should OpenVPN listen on? Ik gebruik tcp/110 omdat deze vaak op firewalls open staat in verband met POP3 mail.
port 443
 
# TCP or UDP server?
proto udp
 
# "dev tun" will create a routed IP tunnel,
dev tun
 
# SSL/TLS root certificate (ca), certificate (cert), and private key (key).
ca /opt/etc/openvpn/keys/ca.crt
cert /opt/etc/openvpn/keys/server1.crt
key /opt/etc/openvpn/keys/server1.key  # This file should be kept secret
 
# Diffie hellman parameters.
dh /opt/etc/openvpn/keys/dh1024.pem
 
# Configure server mode and supply a VPN subnet for OpenVPN to draw client addresses from.
server 10.8.0.0 255.255.255.0
management 127.0.0.1 1195
 
# Maintain a record of client <-> virtual IP address
ifconfig-pool-persist ipp.txt
 
# Push routes to the client to allow it to reach other private subnets behind
push "dhcp-option DNS 192.168.0.1"
#push "dhcp-option DNS 8.8.4.4"
push "route 10.8.0.0 255.255.255.0"
 
#Toegang geven tot machines achter de ix2
client-to-client
 
# Meerdere clients met dezelfde config toelaten:
duplicate-cn
 
#keepalive
keepalive 10 120
 
 
# Enable compression on the VPN link.
comp-lzo
 
# The persist options will try to avoid accessing certain resources on restart
persist-key
persist-tun
 
# Output a short status file showing
# current connections, truncated
# and rewritten every minute.
status openvpn-status.log
 
 
# Set the appropriate level of log
verb 4

Het moet bijna wel fout gaan door iets in de openvpn.conf file, maar ik kom er maar niet achter.

Wie kan me uit de brand helpen en aangeven wat ik verkeerd doe?

[huiser]

Kan je onderstaande regel eens toevoegen?

topology subnet

[M.v.Veelen]

Met die regel erbij kan ik nu ook de NAS niet meer pingen?

Ik krijg echter nu wel als ik de RPi probeer te pingen (op 192.168.0.100) deze melding bij het pingen: No route to host en daarna: Host is down..???

Alleen de router is te pingen op 192.168.0.1

[ Voor 17% gewijzigd door M.v.Veelen op 17-03-2015 16:15 ]

[MSteverink]

Ik ben geen expert op het gebied van VPN, verre van dat.
Maar met de VPN maak je gebruik van een virtuele netwerkkaart, genaamd tun (regel 8 van je config). De rest van je netwerk is verbonden met een fysieke netwerkkaart, eth0 of eth1. Wanneer je de rest van je netwerk ook toegankelijk wilt hebben moet je een verbinding gaan maken tussen die netwerkkaarten. De eenvoudigste manier om dat te doen is een bridge op te zetten tussen tun en eth0.

[M.v.Veelen]

Bedankt voor je input, maar dat helpt me niet verder als ik dit via OpenVPN wil doen. Misschien dat iemand weet wat ik nog moet doen om niet alleen de NAS te kunnen bereiken, maar ook de andere devices op m'n netwerk?

[markvl]

push "dhcp-option DNS 192.168.0.1"

vervangen door

push "route 192.168.0.0 255.255.255.0"

Daarmee vertel je je client dat het 192.168.0.0/24 netwerk ook achter de tunnel zit.

[M.v.Veelen]

OK, ik heb die regel vervangen en getest, maar nog steeds kom ik niet verder dan de NAS en kan ik geen andere internet adressen bereiken. Moet er nog iets anders aangepast (of verwijderd) worden?

[ik222]

markvl schreef op dinsdag 17 maart 2015 @ 20:22:
push "dhcp-option DNS 192.168.0.1"

vervangen door

push "route 192.168.0.0 255.255.255.0"

Daarmee vertel je je client dat het 192.168.0.0/24 netwerk ook achter de tunnel zit.

Dat sowieso inderdaad alleen heb je dan nog steeds het probleem dat je clients niet weten hoe ze terug moeten naar 10.8.0.0/24 (je VPN clients).

Je zult daarnaast dus op je router (die neem ik aan de default gateway is in je LAN) een statische route aan moeten maken die verteld dat 10.8.0.0/24 te vinden is achter 192.168.0.124. Als je dat niet kan op je router kan kun je ook de NAS source NAT laten doen op het VPN verkeer (zie: https://community.openvpn.net/openvpn/wiki/NatHack). Een laatste alternatief daarvoor is nog statische routes op al je clients maar dat lijkt me niet erg handig.

[ Voor 6% gewijzigd door ik222 op 17-03-2015 20:36 ]

[M.v.Veelen]

Ik heb op de router nu dit ingesteld, maar dat helpt niet:

[ik222]

Laat eens je route tabel op een client zien wanneer je de VPN verbinding aan hebt staan (CMD --> route print op windows).

[M.v.Veelen]

Je moet me echt even helpen in Jip&Janneke taal (of stap voor stap) alsjeblieft. Ik heb een Mac.....

[ik222]

In een terminal kun je dit commando geven

code:

netstat -nr

Uitleg over hoe je een terminal kunt openen eventueel hier: https://www.youtube.com/watch?v=zw7Nd67_aFw

[ Voor 42% gewijzigd door ik222 op 17-03-2015 20:45 ]

[M.v.Veelen]

Als ik via m'n hotspot de VPN verbinding opzet krijg ik dit:

code:

Routing tables

Internet:
Destination        Gateway            Flags        Refs      Use   Netif Expire
0/1                10.8.0.1           UGSc           40        0    tun0
default            172.20.10.1        UGSc            6        0     en1
10.8/24            10.8.0.2           UGSc           46        0    tun0
10.8.0.2           10.8.0.2           UH              1        0    tun0
10.37.129/24       link#12            UC              2        0   vnic1
10.37.129.2        0:1c:42:0:0:9      UHLWIi          1       65     lo0
10.37.129.255      ff:ff:ff:ff:ff:ff  UHLWbI          0        3   vnic1
10.211.55/24       link#11            UC              2        0   vnic0
10.211.55.2        0:1c:42:0:0:8      UHLWIi          1       65     lo0
10.211.55.255      ff:ff:ff:ff:ff:ff  UHLWbI          0        3   vnic0
84.107.226.85/32   172.20.10.1        UGSc            1        0     en1
127                127.0.0.1          UCS             0        0     lo0
127.0.0.1          127.0.0.1          UH              7    31686     lo0
128.0/1            10.8.0.1           UGSc            1        0    tun0
169.254            link#4             UCS             0        0     en1
172.20.10/28       link#4             UCS             1        0     en1
172.20.10.1/32     link#4             UCS             1        0     en1
172.20.10.1        da:96:95:72:bd:64  UHLWIir         6       45     en1   1184
172.20.10.2/32     link#4             UCS             0        0     en1
172.20.10.15       ff:ff:ff:ff:ff:ff  UHLWbI          0        3     en1
192.168.0          10.8.0.1           UGSc            1        0    tun0

Internet6:
Destination                             Gateway                         Flags         Netif Expire
::1                                     ::1                             UHL             lo0
fe80::%lo0/64                           fe80::1%lo0                     UcI             lo0
fe80::1%lo0                             link#1                          UHLI            lo0
fe80::%en1/64                           link#4                          UCI             en1
fe80::7256:81ff:fe88:d1e3%en1           70:56:81:88:d1:e3               UHLI            lo0
ff01::%lo0/32                           ::1                             UmCI            lo0
ff01::%en1/32                           link#4                          UmCI            en1
ff02::%lo0/32                           ::1                             UmCI            lo0
ff02::%en1/32                           link#4                          UmCI            en1

Ik zie overigens nog wel m'n (Ziggo) IP ertussen staan, terwijl ik juist via m'n hotspot verbonden ben. Moet ik vooraf nog iets doen ipv meteen overschakelen op de hotspot? ipconfig /release (maar dan voor de Mac) ofzo?

[ Voor 3% gewijzigd door M.v.Veelen op 17-03-2015 20:51 ]

[ik222]

Dat ziet er goed uit, het Ziggo IP doet je VPN client waarschijnlijk maar dat is normaal.

Wat het nog kan zijn is dat ip forwarding niet aan staat op je NAS. Dat is namelijk wel nodig als je ook clients achter de NAS wilt kunnen bereiken.

Wat is het resultaat van onderstaand commando op je NAS?

code:

cat /proc/sys/net/ipv4/ip_forward

Als dat resultaat 0 is staat ip forwarding uit en kun je e het als volgt aanzetten:

code:

echo 1 > /proc/sys/net/ipv4/ip_forward

[ Voor 8% gewijzigd door ik222 op 17-03-2015 21:10 ]

[M.v.Veelen]

Zo te zien zit dat wel goed:

code:

root@NAS:/# cat /proc/sys/net/ipv4/ip_forward
1
root@NAS:/#

[ik222]

Oké de volgende stap is dan toch gaan kijken waar het nu fout gaat.

Kun je eens tcpdump installeren en laten lopen op bijvoorbeeld de raspberry pi terwijl je deze van buiten pingt? Dus dat is dan het volgende op de cli van de raspberry.

code:

apt-get install tcpdump
tcpdump -nli eth0 -f 'icmp'

Als je dan de pings voorbij ziet komen weet je dat het van buiten naar binnen werkt en dat je het op de terugweg moet zoeken.

Wat overigens ook een goede test is anders is om even een statische route op je raspberry te zetten. Dat kan als volgt op de cli:

code:

route add -net 10.8.0.0 netmask 255.255.255.0 gw 192.168.0.124 dev eth0

Werkt het dan wel?

[M.v.Veelen]

Ho, wacht even, ik wil niets met de Pi. Daarop werkt het wel. Ik wil het juist op de NAS laten draaien. Dus dingen installeren op de Pi wil ik niet. Daarop draaien andere zaken die ik niet in de soep wil laten draaien.... Komt misschien lullig over, maar ik denk echt dat er iets in het .conf bestand nog niet goed staat. Tenminste, dat hoop ik eigenlijk...

[ik222]

Je doet ook niks met je Pi voor de VPN verbinding in hetgeen ik hierboven schrijf. Ik wil hem juist alleen even gebruiken als apparaat aan de binnenkant van he netwer om de VPN via je NAS te testen. Ik ben dus bijvoorbeeld benieuwd of je de Pi via de VPN op je NAS kunt bereiken wanneer je hem zelf even de weg terug verteld via die statische route (zo sluit je een probleem met de statische route op de router namelijk uit). Die statische route verdwijnt overigens vanzelf ook weer bij een reboot van de Pi. Maar goed je kunt dit ook met andere apparaten in je thuisnetwerk testen alleen lijkt de Pi me een handige optie

De OpenVPN config file is het probleem niet, dat gedeelte gaat nu gewoon goed aangezien je prima een VPN verbinding hebt met een goed IP en de goede routes. Het zit hem echt in de routing na je NAS denk ik.

[ Voor 7% gewijzigd door ik222 op 17-03-2015 22:00 ]

[M.v.Veelen]

Ja, maar je wilt wel dat ik iets ga installeren op de Pi en dat zie ik niet zitten omdat die nu stabiel draait en ik er juist geen fratsen mee wil uithalen. Is er niet een andere manier om iets te testen, buiten de Pi om ? Ik wil daar echt niet aankomen, snap je?

[ufear]

*nvm* dom

[ Voor 92% gewijzigd door ufear op 17-03-2015 22:05 ]

[M.v.Veelen]

Maar die klopt dan toch? Het IP adres van de NAS is 192.168.0.124

Edit: nvrmd ik zie dat je je bericht hebt aangepast

[ Voor 30% gewijzigd door M.v.Veelen op 17-03-2015 22:07 ]

[ik222]

M.v.Veelen schreef op dinsdag 17 maart 2015 @ 22:02:
Ja, maar je wilt wel dat ik iets ga installeren op de Pi en dat zie ik niet zitten omdat die nu stabiel draait en ik er juist geen fratsen mee wil uithalen. Is er niet een andere manier om iets te testen, buiten de Pi om ? Ik wil daar echt niet aankomen, snap je?

Dat installeren is enkel een packetsniffer om te kijken of pakketje aankomen, gaat dus niets van kapot. Maar goed als je dat niet wilt zet er dan bijvoorbeeld alleen even die statische route erin, die is zelfs bij een reboot gewoon weer weg . En als je Pi dan wel via VPN bereikbaar wordt weet je dat het in je router fout gaat voor de terugweg.

En ja natuurlijk kunnen deze tests en debugging ook met een andere pc, laptop of server in je thuisnetwerk maar ik kan niet raden wat je verder nog hebt staan om te testen

[M.v.Veelen]

OK, dus als ik

route add -net 10.8.0.0 netmask 255.255.255.0 gw 192.168.0.124 dev eth0

op de Pi doe en dan een VPN verbinding via de hotspot / NAS opzet, dan eens kijken wat er gebeurt? Ga ik even doen dan.

OK: die regel ingevoerd (sudo) en daarna de VPN opgezet via de NAS en de hotspot: kan nog niet bij de RPi of andere devices. Bummer.....

[ Voor 24% gewijzigd door M.v.Veelen op 17-03-2015 22:33 ]

[ik222]

Oké dan zul je denk ik echt moeten gaan debuggen met een sniffer om te kijken waar het verkeer blijft hangen.

[johnkeates]

Het probleem is dat je ook NAT moet doen op je NAS, of je nas de hoofdrouter moet laten zijn.

Nu gaan je apparaten zich afvragen waar het verkeer voor 10.8.0.0/24 heen moet, en om dat ze het niet weten gooien ze het maar naar de default gateway, die dank denkt: ken ik niet, en het maar gewoon weggooit.

Ik weet niet precies waarom je een VPN server op een NAS wil installeren, maar als je dat echt perse wil doen heb je nodig:

- OpenVPN (duh)
- NAT
- IP Forwarding
- IP Routing

Het lijkt er op dat de meeste zaken al wel ingesteld zijn, naar NAT dus nog niet. Stel dat nog even in, en dan zit je goed. Je kan in theorie ook een extra route op je huidige gateway/router instellen maar die weet niet op welke interface je 10.8.0.0/24 zit dus dat lijkt me een beetje onbegonnen werk.

Alternatief is dat je een L2 tunnel op zet, en de router en DHCP Server van je bestaande netwerk gebruikt, en dus geen tunnel netwerk gebruikt. Dan heb je geen tun, maar een tap.

[ Voor 10% gewijzigd door johnkeates op 17-03-2015 22:40 ]

[ik222]

johnkeates schreef op dinsdag 17 maart 2015 @ 22:39:
Het probleem is dat je ook NAT moet doen op je NAS, of je nas de hoofdrouter moet laten zijn.

Nu gaan je apparaten zich afvragen waar het verkeer voor 10.8.0.0/24 heen moet, en om dat ze het niet weten gooien ze het maar naar de default gateway, die dank denkt: ken ik niet, en het maar gewoon weggooit.

Ik weet niet precies waarom je een VPN server op een NAS wil installeren, maar als je dat echt perse wil doen heb je nodig:

- OpenVPN (duh)
- NAT
- IP Forwarding
- IP Routing

Het lijkt er op dat de meeste zaken al wel ingesteld zijn, naar NAT dus nog niet. Stel dat nog even in, en dan zit je goed.

Je hebt geen NAT nodig als je een statische route naar het VPN subnet in je router of op je clients zet zoals hier nu beide gedaan is. Dan kun je verkeer over de VPN gewoon routeren wat ook nog eens een stuk netter is dan Source NAT.

En ja die route gaat gewoon werken omdat je het VPN subnet naar in dit geval 192.168.0.124 stuurt wat op zijn beurt gewoon in het directly connected subnet zit.

[ Voor 7% gewijzigd door ik222 op 17-03-2015 22:46 ]

[johnkeates]

ik222 schreef op dinsdag 17 maart 2015 @ 22:43:
[...]

Je hebt geen NAT nodig als je een statische route naar het VPN subnet in je router of op je clients zet zoals hier nu beide gedaan is. Dan kun je verkeer over de VPN gewoon routeren wat ook nog eens een stuk netter is dan Source NAT.

Okee, dan moet hij dus op alle client devices statische routes gaan inbakken, om dat het netter is voor zijn thuisnetwerkje. De kans dat hij met een consumentenmodem van de ISP zit waar je wel routes kan invoeren lijkt me erg klein.

[ Voor 10% gewijzigd door johnkeates op 17-03-2015 22:46 ]

[ik222]

johnkeates schreef op dinsdag 17 maart 2015 @ 22:45:
[...]


Okee, dan moet hij dus op alle client devices statische routers gaan inbakken, om dat het netter is voor zijn thuisnetwerkje.

Nee dat kan hij gewoon een keer op zijn router (default gateway) doen, dat gaat prima werken. Dat is ook al ingesteld als je even terug leest.

Direct een statische route op een client was alleen een test om een fout in de statische route op de router uit te sluiten.

[ Voor 4% gewijzigd door ik222 op 17-03-2015 22:49 ]

[M.v.Veelen]

Ik ben blij dat hier in ieder geval een paar kenners advies geven, maar ik ben nu even kwijt wat ik nog kan doen. Op de NAS wil ik best nog wat doen om voor elkaar te krijgen dat het gaat werken, maar dan moeten jullie beloven om het met elkaar eens te zijn, hahahaha. Nee serieus, wat zou ik nog moeten installeren / configureren op de NAS ?

Edit:

Zojuist op het werk geprobeerd via de open internetverbinding en hetzelfde resultaat: NAS is bereikbaar op 192.168.0.124, maar verder niets. Ook geen websites helaas.

[ Voor 20% gewijzigd door M.v.Veelen op 18-03-2015 07:20 ]

[M.v.Veelen]

Ik kreeg dit nog als reactie op een mail die ik had gestuurd naar iemand die een dergelijke tutorial had geschreven om OpenVPN op zijn iX2 aan de praat te krijgen en na wat heen en weer mailen kreeg ik dit:


Hi again ,

Due to some restrictions on IX2 i was not able to route all the LAN thru openvpn. My advice is to install openvpn on your PI .Use the config file i pasted below :

Let's assume that the openVPN server is 192.168.0.124 (ETH0 - the ip assigned by the router)

Note : your IP pool is very common . It's most likely that you will have conflicts . It would be better to assign new IP pool .

The missing puzzle is the following command :

code:

sudo iptables -t nat -A POSTROUTING -s 6.10.0.0/24 -o eth0 -j SNAT --to-source 192.168.0.124

Test it and if it works for you and it has to work because i did this setup on my raspberry PI and it worked then add that command in a sh file like /etc/openvpn/firewall-rules.sh give proper permission 700 and add to
/etc/network/interfaces the following

code:

iface eth0 inet dhcp
  pre-up /etc/firewall-rules.sh

Let me know if you have any questions . See the config file below :

code:

###config file 
port 1194
proto udp
dev tun

; mtu-test

server 6.10.0.0 255.255.255.0     
ifconfig 6.10.0.1 6.10.0.2
push "route 6.10.0.1 255.255.255.255"
push "route 192.168.0.0 255.255.255.0"
push "route 6.10.0.0 255.255.255.0"

push "dhcp-option DNS 8:8:8:8"
push "redirect-gateway def1"
client-to-client

dh /etc/openvpn/keys/dh1024.pem
ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/server.crt
key /etc/openvpn/keys/server.key


cipher AES-256-CBC
auth MD5
comp-lzo
tls-server

user nobody
group nogroup

keepalive 15 120


ifconfig-pool-persist /etc/openvpn/lan-ipp.txt
status /etc/openvpn/lan-status.log

log-append /etc/openvpn/lan-server.log


verb 3

daemon

##### END of file

Maar.....OpenVPN op de RPi heb ik al werkend (al kan ik daarop ook geen website benaderen merk ik), maar ik wil dit juist op de NAS werkend hebben....

[M.v.Veelen]

Ik kreeg vandaag via de mail deze reactie:


You can install on IX2 but the only issue is that you won't have access to local LAN resources because IX2 is missing iptables kernel module . It's not impossible to compile and enable but is hard to get it done . So with my config i achived to have access to all the services/shares on NAS and i can mount shares over vpn tunel. That's what i wanted most . What you said that you don't have access to websites when openvpn is started is not normal behavieur . Check if you have static routes in the router or the issue might be the IP pool you have chosen for DHCP server . To have access also to local LAN resources you need to add that line in iptables .You can do it on the install on PI .

Dus het gaat simpelweg niet werken op deze NAS....grrrr

[Ben(V)]

Ondersteund je router geen VPN?
Veel routers doen dat wel en vaak veel beter.

[M.v.Veelen]

Ik heb een Netgeard WNDR4500 en met de stock firmware wordt dat helaas niet ondersteund De DD-WRT heb ik ooit eens geprobeerd maar die was toen nog niet stabiel, en daarin zat wel VPN ondersteuning. Ik ben nu weer terug naar af: de RPi totdat ik mss toch een andere (Synology) NAS heb die VPN wel ondersteunt.

[Ben(V)]

Synology kan het prima, maar een router met VPN ondersteuning is veel goedkoper.
DD-wrt is tegenwoordig toch ook behoorlijk stabiel?

[M.v.Veelen]

Inmiddels aardig wat tijd verstreken, maar wel over naar een Synology DS414. Ik heb daarop OpenVPN geïnstalleerd en kan een VPN verbinding opzetten.

Echter.....ik heb dan geen internettoegang meer. Zodra ik de VPN verbinding verbreek dan heb ik weer internettoegang.

De inhoud van m'n .ovpn bestandje is:

code:

dev tun
tls-client
 
remote mijn.externe.ip.adres 443
 
# The "float" tells OpenVPN to accept authenticated packets from any address,
# not only the address which was specified in the --remote option.
# This is useful when you are connecting to a peer which holds a dynamic address
# such as a dial-in user or DHCP client.
# (Please refer to the manual of OpenVPN for more information.)
 
#float
 
# If redirect-gateway is enabled, the client will redirect it's
# default network gateway through the VPN.
# It means the VPN connection will firstly connect to the VPN Server
# and then to the internet.
# (Please refer to the manual of OpenVPN for more information.)
 
redirect-gateway
 
# dhcp-option DNS: To set primary domain name server address.
# Repeat this option to set secondary DNS server addresses.
 
dhcp-option DNS 192.168.0.1
 
pull
 
 
# If you want to connect by Server's IPv6 address, you should use
# "proto udp6" in UDP mode or "proto tcp6-client" in TCP mode
proto tcp-client
 
script-security 2
 
ca ca.crt
 
comp-lzo
 
reneg-sec 0
 
auth-user-pass

Het gekke is dat ik met exact dezelfde .ovpn (en dan de ca.cert er in geplakt) op mijn iPhone een VPN verbinding kan maken en dan nog wel gewoon internettoegang heb.
Nog gekker is dat ik het ooit werkend heb gehad op deze NAS en dat het dan dus geen probleem van / in de router zou moeten zijn. Ik gebruik een Mac met daarop Viscosity.

Ziet iemand iets geks of iets wat ontbreekt / anders moet?

[ThinkPad]

Werkt een

ping 8.8.8.8

wel? Het lijkt op een DNS-probleem....

Doe ook eens een

traceroute 8.8.8.8

dan kun je zien tot waar het verkeer komt.

[ Voor 39% gewijzigd door ThinkPad op 02-10-2015 09:21 ]

[M.v.Veelen]

Als ik een verbinding heb gemaakt (wat dus wél gewoon lukt), dan kan ik bij alle apparaten in mijn thuisnetwerk, behalve bij mijn router (192.168.0.1). Ga ik vervolgens pingen naar 8.8.8.8, dan krijg ik time outs, en bij een tracert naar 8.8.8.8 krijg ik alleen maar sterretjes en time outs te zien.
Het verkeer komt dus tot.....niets ?

Overigens gebruik ik Mac OS X en zag ik de volgende uitleg (let op de regels onderaan): https://www.synology.com/...gebase/tutorials/592#t4.2

Ik heb, voor zover ik weet, op de Mac nog niet eerder zoiets hoeven doen, maar kan dit de oorzaak zijn dat ik wel een verbinding kan maken, maar vervolgens geen internetverbinding heb óf dat ik wel internetverbinding heb, maar niet alle traffic door de VPN kan laten lopen?
Ik weet er te weinig van om dit tot een goed einde te brengen, dus heb wat tips& tricks nodig

[ Voor 43% gewijzigd door M.v.Veelen op 02-10-2015 15:49 ]

[ThinkPad]

Probeer het eens met een andere client, liefst ook met een ander besturingssysteem (Windows?) en kijk dan eens of je 8.8.8.8 kunt pingen, of je internet hebt (ping nu.nl), of je bij het interne IP-adres van je router kunt etc.

[ Voor 41% gewijzigd door ThinkPad op 05-10-2015 09:07 ]