Welkom op het

KPN Forum

Recent online

VPN op raspberry op mijn netwerk bereikbaar maken vanaf buiten


Ik probeer een VPN (op een raspberry) op mijn netwerk bereikbaar te maken vanaf buiten.
Hiervoor wil ik zowel UDP poort 1194 en TCP poort 22 doorzetten naar intern IP 192.168.2.155

Intern werkt alles, alleen kan ik extern niet benaderen.

Port forwarding is ingesteld, DMZ staat uit, UPnP staat uit, IPv6 staat uit. In het overzicht bij de netwerkinstellingen zie ik dat de Port Fowarding erin staat.

33 Reacties

Reputatie 7
Badge +27
Wat gebeurt er als je extern benadert

Robin
als ik doe telnet [extern ip] 22
dan duurt het even en krijg ik Trying [extern ip]...
telnet: Unable to connect to remote host: Resource temporarily unavailable


als ik doe telnet 192.168.2.155 22
dan krijg ik instant Trying 192.168.2.155...
Connected to 192.168.2.155.
Escape character is '^]'.
SSH-2.0-OpenSSH_7.4p1 Raspbian-10+deb9u2
Reputatie 3
Badge
@Tvsambeek Ik zie niet direct wat er fout zou kunnen zijn aan de screenshots. Ik neem aan dat je (ook) in ieder geval de telnet connectie vanaf een ander publiek IPv4 adres dan vanuit 192.168.2.0/24 hebt getest ?
Het lijkt dus een prbleem met porforwarding, powercycle al geprobeert neem ik aan?
Je kan VPN in eerste instantie wel even buiten beschouwing laten (en uitzetten), dan kan e.v.t. aangepaste routing op de RPi niet de zaak verstoren.
E.v.t. met wireshark op je LAN kijken of er ueberhaupt wel IP paketten met destination 192.168.2.155 binnen komen. Ik zie opvallend veel 'portforwarding werkt niet' berichten op dit forum, kan mijn perceptie zijn, maar misschien is er toch iets aan de hand met de betreffende modemrouter/firmwareversie.
Reputatie 7
tmoesel schreef:

Ik zie opvallend veel 'portforwarding werkt niet' berichten op dit forum, kan mijn perceptie zijn, maar misschien is er toch iets aan de hand met de betreffende modemrouter/firmwareversie.

Ik gebruik precies dezelfde router en heb geen enkel probleem met port-forwarding en ik heb er toch heel wat staan om mijn NAS functionaliteit te kunnen benaderen, VPN verbinding met mijn netwerk thuis op te zetten of om beelden van mijn bewakingscamera's te bekijken.
Reputatie 7
Badge +27
Hoi,

Is dit de V10 in combinatie met 4g Buitengebied?

Heb je het extern IP dat bij de V10 onder Status - WAN IP staat?

Robin
@RobinFlikkema nee, geen 4G... het is 100mbit glasvezel, ja ik heb het IP, als je het wil testen, zal ik het via een PB sturen?
@tmoesel ik snap de helft van wat je zegt niet. als ik de Pi uitzet kan ik zowieso toch niks benaderen? Powercycle al geprobeerd ja, inmiddels is de modem ook al 2x naar factory reset geweest en opnieuw ingesteld, dat maakt ook geen verschil
@wjb dan heb je geluk... google het maar eens, zijn heel veel problemen met port forwarding met de V10
Reputatie 7
Tvsambeek schreef:

@wjb dan heb je geluk... google het maar eens, zijn heel veel problemen met port forwarding met de V10

Toch zijn er helemaal geen problemen met port-forwarding i.c.m. een V10, ik forward alles wat los en vast zit uitgezonderd TCP poort 8085.
Ik ondervind daarbij geen enkel probleem.
wjb schreef:

Toch zijn er helemaal geen problemen met port-forwarding i.c.m. een V10, ik forward alles wat los en vast zit uitgezonderd TCP poort 8085.
Ik ondervind daarbij geen enkel probleem.


Dat jij geen problemen hebt wil natuurlijk zeggen dat er geen problemen zijn. gezien alle forum posts zullen er veel mensen het niet met je eens zijn, mijzelf inclusief.
Reputatie 7
Kijk dan vooral naar jouw eigen apparaat, want ik ben er vrijwel 100% van overtuigd dat het probleem daar veroorzaakt wordt.
Kijk vooral goed naar firewall instellingen op het apparaat dat benaderd wordt.
Met de Experia box zijn alle UDP en TCP poorten probleemloos te forwarden uitgezonderd TCP poort 8085.
Reputatie 3
Badge
@Tvsambeek
Ik bedoel: alleen in eerste instantie de OpenVPN service uit te zetten, niet de hele RPi. Afhankelijk van hoe de OpenVPN configuratie er uit ziet, zou het dan wel kunnen werken (commando ip route zou daar hints over kunnen geven).
Maar ook als je de RPi uitzet, zou portforwarding voor ssh kunnen werken, is afhankelijk van hoe de V10 daar intern mee omgaat. Ik heb zelf geen V10, misschien kan iemand anders daar uit ervaring iets over zeggen.

Waarom probeer je trouwens een ssh service met telnet te benaderen?
tmoesel schreef:

Waarom probeer je trouwens een ssh service met telnet te benaderen?



Puur om te zien of ie de Pi kan bereiken, om uit te sluiten dat er niet iets anders aan de hand is.
ik heb via https://www.yougetsignal.com/tools/open-ports/ getest en die zegt ook dat zowel 22 als 1194 gesloten zijn
Reputatie 3
Badge
Tvsambeek schreef:

tmoesel schreef:

Waarom probeer je trouwens een ssh service met telnet te benaderen?


Puur om te zien of ie de Pi kan bereiken, om uit te sluiten dat er niet iets anders aan de hand is.


OK dacht ik ook al.
Is er een verschil als je in de V10 DHCP binding voor de RPi op 192.168.2.155 instelt en dan dus ook de RPi via DHCP z'n ip adres laat verkrijgen?
maakt helaas geen verschil 😞
Reputatie 7
Onderstaand het resultaat van een port-forwarding van TCP poort 22 op onze V10 naar een Synology NAS.

Op de Synology NAS staat de firewall open voor TCP poort 22 en is de SSH service ingeschakeld.
Reputatie 4
Heb je geen firewall op de PI staan? mogelijk blokkeert deze inkomende verbindingen vanaf buitenaf? Hier werkt SSH en OpenVPN namelijk ook via de V10 en eigen router.
Reputatie 3
Badge
tmoesel schreef:

Maar ook als je de RPi uitzet, zou portforwarding voor ssh kunnen werken, is afhankelijk van hoe de V10 daar intern mee omgaat. Ik heb zelf geen V10, misschien kan iemand anders daar uit ervaring iets over zeggen.


Vergeet deze uitspraak maar, alleen als je met embedded software ontwikkeltools en/of andere complexe monitoring hardware het interne gedrag van de V10 kan analyseren zou dit kunnen helpen om inzicht te verschaffen.
King007 schreef:

Heb je geen firewall op de PI staan? mogelijk blokkeert deze inkomende verbindingen vanaf buitenaf? Hier werkt SSH en OpenVPN namelijk ook via de V10 en eigen router.


Zo ver ik kan zien staat de firewall op de VPN uit.

wjb schreef:

Onderstaand het resultaat van een port-forwarding van TCP poort 22 op onze V10 naar een Synology NAS.


Ik snap niet zo goed wat je nou steeds wil zeggen. Dat het bij jou werkt is geweldig. Bij mij werkt het alleen niet. Het feit dat het bij jou werkt wil niet zeggen dat het daarom dus altijd probleemloos bij anderen zal werken.
Reputatie 7
Tvsambeek schreef:

wjb schreef:

Onderstaand het resultaat van een port-forwarding van TCP poort 22 op onze V10 naar een Synology NAS.


Ik snap niet zo goed wat je nou steeds wil zeggen. Dat het bij jou werkt is geweldig. Bij mij werkt het alleen niet. Het feit dat het bij jou werkt wil niet zeggen dat het daarom dus altijd probleemloos bij anderen zal werken.

Wat ik wil zeggen is dat de V10 je echt geen strobreed in de weg zal leggen om dergelijke port-forwardings operationeel te krijgen. In vrijwel alle gevallen blijkt de oorzaak van het niet functioneren van port-forwardings toch echt in het eigen apparaat gezocht te moeten worden.
Er wordt een hoop gefoeterd op de V10, deze zou helemaal dichtgetimmerd zijn echter niets is minder waar.
Ik zou toch echt eens goed naar de firewall van de Raspberry Pi kijken, persoonlijk denk ik dat daar standaard ingesteld staat dat inkomende verbindingen komende vanaf de gateway (Experia Box) geblokkeerd worden. Dat zou ik persoonlijk ook een zeer goede default instelling vinden.

Draai je het standaard Raspian OS of draai je een andere Linux distro en zo ja, welke dan?
Reputatie 4
Tvsambeek schreef:

Zo ver ik kan zien staat de firewall op de VPN uit.



Ik heb het niet over de firewall op de VPN maar op je PI. Ik heb namelijk sterk de indruk dat deze verbindingen blokkeert. Ik heb SSH richting mijn PI ook openstaan en werkt prima. Net als openvpn.

Zoals @wjb al vroeg, welke software draai je op de PI? Wil je eens iptables -L -n uitvoeren? krijg je dan output?
root@burri-vpn:~# service iptables stop
Failed to stop iptables.service: Unit iptables.service not loaded.

Linux burri-vpn 4.9.59+ #1047 Sun Oct 29 11:47:10 GMT 2017 armv6l GNU/Linux

Ik moet eerlijk zeggen dat ik de raspberry niet heb opgezet, mijn broer heeft dat gedaan wiens werk dit is ... (ik ben er minder bekend mee)
Reputatie 4
Tvsambeek schreef:

root@burri-vpn:~# service iptables stop
Failed to stop iptables.service: Unit iptables.service not loaded.

Linux burri-vpn 4.9.59+ #1047 Sun Oct 29 11:47:10 GMT 2017 armv6l GNU/Linux

Ik moet eerlijk zeggen dat ik de raspberry niet heb opgezet, mijn broer heeft dat gedaan wiens werk dit is ... (ik ben er minder bekend mee)



Maar als het jouw broers werk is, waarom stelt hij het dan niet even goed voor je in?
omdat hij heeft geprobeerd alles in te stellen maa de portforwarding niet wil
alles aan de Pi / VPN lijkt gewoon goed en hij het verder ook niet weet. vandaar mijn vraag hier

(en misschien is ie wel heel slecht in zn werk, ik weet het niet 😂 )
King007 schreef:

Wil je eens iptables -L -n uitvoeren? krijg je dan output?


Chain INPUT (policy DROP)
target prot opt source destination
ufw-before-logging-input all -- 0.0.0.0/0 0.0.0.0/0
ufw-before-input all -- 0.0.0.0/0 0.0.0.0/0
ufw-after-input all -- 0.0.0.0/0 0.0.0.0/0
ufw-after-logging-input all -- 0.0.0.0/0 0.0.0.0/0
ufw-reject-input all -- 0.0.0.0/0 0.0.0.0/0
ufw-track-input all -- 0.0.0.0/0 0.0.0.0/0

Chain FORWARD (policy DROP)
target prot opt source destination
ufw-before-logging-forward all -- 0.0.0.0/0 0.0.0.0/0
ufw-before-forward all -- 0.0.0.0/0 0.0.0.0/0
ufw-after-forward all -- 0.0.0.0/0 0.0.0.0/0
ufw-after-logging-forward all -- 0.0.0.0/0 0.0.0.0/0
ufw-reject-forward all -- 0.0.0.0/0 0.0.0.0/0
ufw-track-forward all -- 0.0.0.0/0 0.0.0.0/0

Chain OUTPUT (policy ACCEPT)
target prot opt source destination
ufw-before-logging-output all -- 0.0.0.0/0 0.0.0.0/0
ufw-before-output all -- 0.0.0.0/0 0.0.0.0/0
ufw-after-output all -- 0.0.0.0/0 0.0.0.0/0
ufw-after-logging-output all -- 0.0.0.0/0 0.0.0.0/0
ufw-reject-output all -- 0.0.0.0/0 0.0.0.0/0
ufw-track-output all -- 0.0.0.0/0 0.0.0.0/0

Chain ufw-after-forward (1 references)
target prot opt source destination

Chain ufw-after-input (1 references)
target prot opt source destination
ufw-skip-to-policy-input udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:137
ufw-skip-to-policy-input udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:138
ufw-skip-to-policy-input tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:139
ufw-skip-to-policy-input tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:445
ufw-skip-to-policy-input udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:67
ufw-skip-to-policy-input udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:68
ufw-skip-to-policy-input all -- 0.0.0.0/0 0.0.0.0/0 ADDRTYPE match dst-type BROADCAST

Chain ufw-after-logging-forward (1 references)
target prot opt source destination
LOG all -- 0.0.0.0/0 0.0.0.0/0 limit: avg 3/min burst 10 LOG flags 0 level 4 prefix "[UFW BLOCK] "

Chain ufw-after-logging-input (1 references)
target prot opt source destination
LOG all -- 0.0.0.0/0 0.0.0.0/0 limit: avg 3/min burst 10 LOG flags 0 level 4 prefix "[UFW BLOCK] "

Chain ufw-after-logging-output (1 references)
target prot opt source destination

Chain ufw-after-output (1 references)
target prot opt source destination

Chain ufw-before-forward (1 references)
target prot opt source destination
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED
ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 icmptype 3
ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 icmptype 4
ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 icmptype 11
ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 icmptype 12
ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 icmptype 8
ufw-user-forward all -- 0.0.0.0/0 0.0.0.0/0

Chain ufw-before-input (1 references)
target prot opt source destination
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED
ufw-logging-deny all -- 0.0.0.0/0 0.0.0.0/0 ctstate INVALID
DROP all -- 0.0.0.0/0 0.0.0.0/0 ctstate INVALID
ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 icmptype 3
ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 icmptype 4
ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 icmptype 11
ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 icmptype 12
ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 icmptype 8
ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp spt:67 dpt:68
ufw-not-local all -- 0.0.0.0/0 0.0.0.0/0
ACCEPT udp -- 0.0.0.0/0 224.0.0.251 udp dpt:5353
ACCEPT udp -- 0.0.0.0/0 239.255.255.250 udp dpt:1900
ufw-user-input all -- 0.0.0.0/0 0.0.0.0/0

Chain ufw-before-logging-forward (1 references)
target prot opt source destination

Chain ufw-before-logging-input (1 references)
target prot opt source destination

Chain ufw-before-logging-output (1 references)
target prot opt source destination

Chain ufw-before-output (1 references)
target prot opt source destination
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED
ufw-user-output all -- 0.0.0.0/0 0.0.0.0/0

Chain ufw-logging-allow (0 references)
target prot opt source destination
LOG all -- 0.0.0.0/0 0.0.0.0/0 limit: avg 3/min burst 10 LOG flags 0 level 4 prefix "[UFW ALLOW] "

Chain ufw-logging-deny (2 references)
target prot opt source destination
RETURN all -- 0.0.0.0/0 0.0.0.0/0 ctstate INVALID limit: avg 3/min burst 10
LOG all -- 0.0.0.0/0 0.0.0.0/0 limit: avg 3/min burst 10 LOG flags 0 level 4 prefix "[UFW BLOCK] "

Chain ufw-not-local (1 references)
target prot opt source destination
RETURN all -- 0.0.0.0/0 0.0.0.0/0 ADDRTYPE match dst-type LOCAL
RETURN all -- 0.0.0.0/0 0.0.0.0/0 ADDRTYPE match dst-type MULTICAST
RETURN all -- 0.0.0.0/0 0.0.0.0/0 ADDRTYPE match dst-type BROADCAST
ufw-logging-deny all -- 0.0.0.0/0 0.0.0.0/0 limit: avg 3/min burst 10
DROP all -- 0.0.0.0/0 0.0.0.0/0

Chain ufw-reject-forward (1 references)
target prot opt source destination

Chain ufw-reject-input (1 references)
target prot opt source destination

Chain ufw-reject-output (1 references)
target prot opt source destination

Chain ufw-skip-to-policy-forward (0 references)
target prot opt source destination
DROP all -- 0.0.0.0/0 0.0.0.0/0

Chain ufw-skip-to-policy-input (7 references)
target prot opt source destination
DROP all -- 0.0.0.0/0 0.0.0.0/0

Chain ufw-skip-to-policy-output (0 references)
target prot opt source destination
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0

Chain ufw-track-forward (1 references)
target prot opt source destination

Chain ufw-track-input (1 references)
target prot opt source destination

Chain ufw-track-output (1 references)
target prot opt source destination
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 ctstate NEW
ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 ctstate NEW

Chain ufw-user-forward (1 references)
target prot opt source destination

Chain ufw-user-input (1 references)
target prot opt source destination
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:22
ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:22
ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:1194

Chain ufw-user-limit (0 references)
target prot opt source destination
LOG all -- 0.0.0.0/0 0.0.0.0/0 limit: avg 3/min burst 5 LOG flags 0 level 4 prefix "[UFW LIMIT BLOCK] "
REJECT all -- 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable

Chain ufw-user-limit-accept (0 references)
target prot opt source destination
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0

Chain ufw-user-logging-forward (0 references)
target prot opt source destination

Chain ufw-user-logging-input (0 references)
target prot opt source destination

Chain ufw-user-logging-output (0 references)
target prot opt source destination

Chain ufw-user-output (1 references)
target prot opt source destination
ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:1194
wjb schreef:

Wat ik wil zeggen is dat de V10 je echt geen strobreed in de weg zal leggen om dergelijke port-forwardings operationeel te krijgen.


Ik realiseer me ten volle dat dat zou zou moeten zijn, neemt niet weg dat het niet altijd zo is.
wjb schreef:

In vrijwel alle gevallen blijkt de oorzaak van het niet functioneren van port-forwardings toch echt in het eigen apparaat gezocht te moeten worden.


Ook dat kan zomaar kloppen
wjb schreef:

Er wordt een hoop gefoeterd op de V10, deze zou helemaal dichtgetimmerd zijn echter niets is minder waar.


Ik heb volgens mij nergens iets zoals dit gezegd. Ik heb enkel gesteld dat eea niet werkt en gevraagd om hulp. Dat de V10 een dichtgetimmerd k$#@ ding is lijkt me duidelijk, neemt niet weg dat dit gewoon zou moeten werken.
wjb schreef:

Ik zou toch echt eens goed naar de firewall van de Raspberry Pi kijken, persoonlijk denk ik dat daar standaard ingesteld staat dat inkomende verbindingen komende vanaf de gateway (Experia Box) geblokkeerd worden. Dat zou ik persoonlijk ook een zeer goede default instelling vinden.


Zo ver ik weet staan alle firewalls op de Pi (en VPN) uit. Als de inkomende verbindingen vanaf de gateway geblokt zouden worden, dan zou het intern ook niet werken, en dat doet het wel.
(Daarmee is het niet 100% uitgesloten dat alles in de Pi goed staat, maar deze oorzaak lijkt me onwaarschijnlijk)
wjb schreef:

Draai je het standaard Raspian OS of draai je een andere Linux distro en zo ja, welke dan?


Zoals eerder aangegeven weet ik dat niet exact. Dit is de info die ik zo ver heb:
Raspbian-10+deb9u2
Linux burri-vpn 4.9.59+ #1047 Sun Oct 29 11:47:10 GMT 2017 armv6l GNU/Linux
PRETTY_NAME="Raspbian GNU/Linux 9 (stretch)"
NAME="Raspbian GNU/Linux"
VERSION_ID="9"
VERSION="9 (stretch)"
ID=raspbian
ID_LIKE=debian

Reageer