[Frage] VPN: Wie Internet-Zugang einer entfernten Box nutzen?

Wie bereits geschrieben ... die gezeigte Konfiguration setzt so viele Sachen voraus (angefangen mit der Tatsache, daß der Client auch tatsächlich die .20 verwendet, was man ja auch mit einem Paketmitschnitt und/oder den Support-Daten der 7390 erst einmal prüfen kann - von allen anderen Umständen (DHCP mit "immer dieselbe vergeben" oder statisch, usw.) weiß man bisher ja auch nichts), daß da so ziemlich überall der Wurm drin sein kann und nur eine systematische Fehlersuche wirklich erfolgsversprechend (fast fühle ich mich versucht, von "erfolgsgarantierend" zu schreiben, wenn nicht noch weitere "no-go"-Punkte ans Licht kommen) wäre.

Außerdem stand ja in #8 bereits (beim Zurückblättern habe ich #12 gerade das erste Mal zu Gesicht bekommen ... danke für die "Diagnose", meine Replik folgt später, wenn ich mehr Zeit habe, denn die steht gar nicht so im Überfluß zur Verfügung, wie in #12 gemutmaßt wird), daß man besser erst mal damit startet, tatsächlich sämtlichen Traffic der .20 durch den Tunnel zu schieben und dann kann man die Einträge immer noch "verfeinern".

Man kann beim Paketmitschnitt in der FRITZ!Box auf der "1. Internet-Verbindung" alles das sehen, was die Box tatsächlich in Richtung WAN verläßt und das muß dann ja irgendwie mit dem korrelieren, was den WAN-Stack der FRITZ!Box (das ist ja bekanntlich nicht der "normale" Linux-Stack) über die "Routing-Schnittstelle" betritt.

Wenn da auf der LAN-Seite tatsächlich Traffic mit passender Source-IP (und passendem Protokoll/Port, solange das auf TCP 80 und TCP 443 beschränkt ist ... was wäre eigentlich TCP 433 genau?) in den WAN-Stack kommt und ihn auf der anderen Seite auch unverschlüsselt wieder verläßt, stimmen die Selektoren wohl doch nicht ... aber das steht auch wieder alles (inkl. der SAs für die VPN-Verbindung) in den Support-Daten irgendwo bei der VPN-Diagnose und der Hinweis darauf steht wieder in den bereits erwähnten Threads, die ausführlich darauf eingehen, was man zur Diagnose bei Problemen alles bräuchte und was ein Fragesteller dazu selbst beitragen muß, denn nur er kommt i.d.R. an diese Protokolle und an dem notwendigen Mitschnitt.
 
  • Like
Reaktionen: teee
ich kann PeterPawn für die Vorschläge zur systemmatischen Analyse nur zustimmen;

vorab helfen ggf. folgende Klärungsfragen:
Ist auf dem PC mit IP 192.168.20.20 ein VPN-Client aktive, der einen Tunnel z.B. auf einen VPN-Provider aufbaut ?
wird auf dem PC ggf. ein Cloud-Proxy eingesetzt ?
Betriebssystem-Version des Clients ?
gibt es sonst noch Netzwerk-/Security-Zusatzsoftware auf dem Client ?
 
Wenn die Blüüüüten erblüüüüh'n!
(Mein Gott jetzt hat sie's!)

Manchmal sind's die kleinen Dinge:

...was wäre eigentlich TCP 433 genau? ...

Wir wissen nun: TCP ist der Port, über den Tippfehler über https geblockt werden.

...
FB7490_192.168.20.1:
NEU (Selector erweitert um Destination Ports):
vpn.cfg
accesslist = "permit ip any 192.168.10.0 255.255.255.0",
"permit tcp 192.168.20.20 255.255.255.255 any eq 80",
"permit tcp 192.168.20.20 255.255.255.255 any eq 433";

...

Prinzipiell war das Ansatz natürlich richtig. Vielen Dank Shirocco88!
Leider habe ich den kleinen Tippz-Fehler in dem Vorschlag übersehen.

Aber PeterPawns rhetorische Frage brachte dann den Durchbruch

accesslist = "permit ip any 192.168.20.0 255.255.255.0",
"permit ip 192.168.10.21 255.255.255.255 any eq 80",
"permit ip 192.168.10.21 255.255.255.255 any eq 443";


Nun läuft der Hase.
Ganz herzlichen Dank für eure geduldige Hilfe!
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.