ASUS RT-N18U mit VPN Client hinter Fritzbox - Portforwarding
Hallo Leute,
habe einen ASUS RT-N18U auf dessen WAN Schnittstelle mit meiner Fritzbox (brauche ich für Telefonie/FAX/Smarthome etc.) an der LAN Schnittstelle angebunden und am ASUS dann das LAN mit allen Geräten konfiguriert. VPN Client auf dem ASUS eingerichtet und alle Netzwerk Geräte gehen nun per VPN Tunnel ins Internet ... eigentlich alles prima, aber ich kommen nun leider nicht von aussen in mein LAN (möchte eine Router Kaskade mit 2 Routern aufbauen, da der ASUS mit dem AP Modus den VPN Server deaktiviert). Möchte eigentlich per OpenVPN auf mein internes Netz zugreifen (VPN Server ist ja am Asus an Board) - funktioniert aber leider nicht. Habe auf der Fritzbox (LAN 192.168.177.1) die externen Ports (z. b. 1194 etc.) an die IP des ASUS (WAN IP 192.168.177.3) freigegeben. Ebenfalls habe ich mal testweise die Firewall am ASUS deaktiviert und auch das WAN Port Forwarding auf dem ASUS eingerichtet). Leider komme ich nicht von aussen in mein Netzwerk. Habe beim ASUS Support angerufen und diese haben mir mitgeteilt, dass dieses so gar nicht geht, da sich angeblich die Fritzbox sperrt ... Kann aber nicht sein oder? Denke eher dass es mit dem NAT zu tun hat ... habe auch das NAT schon auf dem ASUS (LAN IP 192.168.178.1) deaktiviert und auf der Fritte eine statische Route eingetragen ... leider auch ohne Erfolg ....
Fritzbox macht Portforward auf 192.168.177.3 (UDP 1194), der ASUS VPN Server hat die WAN IP 192.168.177.3 und soll dann ins Netz 192.168.178.0 (LAN Adressen des ASUS und alle anderen Clients) weiterleiten ... WAN - NAT Passthrough ist auf dem ASUS auch aktiv.
Auf beiden Routern ist DHCP Server für die unterschiedlichen Netze aktiviert (kann dieses ev. Probleme machen)?
Hier mal die Alternative 2, welche ich verwenden möchte ....
Kopplung von 2 Routern
Könnte natürlich den ASUS auch als AP konfigurieren (mit der gleichen Netzadresse wie die Fritzbox) und das Fritz VPN verwenden ... aber nur als Notlösung ... möchte schon 2 unterschiedliche Netze haben, da ich beide Router auch mit unterschiedlichen WLAN's betreiben möchte (Gastnetz und Heimnetz) ....
Für Tipps und Hilf wäre ich Euch sehr dankbar ....
habe einen ASUS RT-N18U auf dessen WAN Schnittstelle mit meiner Fritzbox (brauche ich für Telefonie/FAX/Smarthome etc.) an der LAN Schnittstelle angebunden und am ASUS dann das LAN mit allen Geräten konfiguriert. VPN Client auf dem ASUS eingerichtet und alle Netzwerk Geräte gehen nun per VPN Tunnel ins Internet ... eigentlich alles prima, aber ich kommen nun leider nicht von aussen in mein LAN (möchte eine Router Kaskade mit 2 Routern aufbauen, da der ASUS mit dem AP Modus den VPN Server deaktiviert). Möchte eigentlich per OpenVPN auf mein internes Netz zugreifen (VPN Server ist ja am Asus an Board) - funktioniert aber leider nicht. Habe auf der Fritzbox (LAN 192.168.177.1) die externen Ports (z. b. 1194 etc.) an die IP des ASUS (WAN IP 192.168.177.3) freigegeben. Ebenfalls habe ich mal testweise die Firewall am ASUS deaktiviert und auch das WAN Port Forwarding auf dem ASUS eingerichtet). Leider komme ich nicht von aussen in mein Netzwerk. Habe beim ASUS Support angerufen und diese haben mir mitgeteilt, dass dieses so gar nicht geht, da sich angeblich die Fritzbox sperrt ... Kann aber nicht sein oder? Denke eher dass es mit dem NAT zu tun hat ... habe auch das NAT schon auf dem ASUS (LAN IP 192.168.178.1) deaktiviert und auf der Fritte eine statische Route eingetragen ... leider auch ohne Erfolg ....
Fritzbox macht Portforward auf 192.168.177.3 (UDP 1194), der ASUS VPN Server hat die WAN IP 192.168.177.3 und soll dann ins Netz 192.168.178.0 (LAN Adressen des ASUS und alle anderen Clients) weiterleiten ... WAN - NAT Passthrough ist auf dem ASUS auch aktiv.
Auf beiden Routern ist DHCP Server für die unterschiedlichen Netze aktiviert (kann dieses ev. Probleme machen)?
Hier mal die Alternative 2, welche ich verwenden möchte ....
Kopplung von 2 Routern
Könnte natürlich den ASUS auch als AP konfigurieren (mit der gleichen Netzadresse wie die Fritzbox) und das Fritz VPN verwenden ... aber nur als Notlösung ... möchte schon 2 unterschiedliche Netze haben, da ich beide Router auch mit unterschiedlichen WLAN's betreiben möchte (Gastnetz und Heimnetz) ....
Für Tipps und Hilf wäre ich Euch sehr dankbar ....
Kommentieren
Teilen
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 336395
Url: https://administrator.de/forum/asus-rt-n18u-mit-vpn-client-hinter-fritzbox-portforwarding-336395.html
Ausgedruckt am: 26.04.2025 um 05:04 Uhr
21 Kommentare
Neuester Kommentar
Hallo,
Und was sagt der Wireshark?
Oder auf der uns unbekannten Fritte ein Paketmitschnitt machen (sofern dein Frittenmodell es kann). Kann dein ASUS auch Paketmitschnitt, sonst an dessen WAN mitschnüffeln (Switch mit Portmirror). Dann schauen wo deine Anfragen deines OpenVPN bleiben. Vielleicht sperrt ja einer der derzeit verwendeten ISPs. (du testest doch von ausserhalb deines LANs, oder?
Gruß,
Peter
Und was sagt der Wireshark?
Oder auf der uns unbekannten Fritte ein Paketmitschnitt machen (sofern dein Frittenmodell es kann). Kann dein ASUS auch Paketmitschnitt, sonst an dessen WAN mitschnüffeln (Switch mit Portmirror). Dann schauen wo deine Anfragen deines OpenVPN bleiben. Vielleicht sperrt ja einer der derzeit verwendeten ISPs. (du testest doch von ausserhalb deines LANs, oder?
Gruß,
Peter
Habe eine Fritzbox 7360SL V1, wo meine SIP Geräte und Smarthome laufen. Das Problem ist, dass eben nicht nur der VPN Server nicht funktioniert, sondern keine Portweiterleitungen (z.b. 8080 für ASUS Weboberfläche) aus dem Internet über die Fritz zum ASUS und dann zu den Clients funktionieren, obwohl ich auf der Fritte auf die WAN IP des ASUS forwarde und auf dem ASUS auch das WAN Forwarding eingetragen habe ... Fritzbox und Asus bieten leider keinen Paketmitschnitt .... somit werde ich mal versuchen ob der Whireshark was findet ... Habe es mit mehrere Internetquellen versucht (kann also nicht am ISP liegen) ...
Hallo,
Ähhh, falsch. http://www.wehavemorefun.de/fritzbox/Paketmitschnitt. Allerdings Providergestellter Kabelboxen z.B. die 6490 von UnityMedia können es nicht.
Gruß,
Peter
Ähhh, falsch. http://www.wehavemorefun.de/fritzbox/Paketmitschnitt. Allerdings Providergestellter Kabelboxen z.B. die 6490 von UnityMedia können es nicht.
Gruß,
Peter
Ahhhh mercy .... nun habe ich es auch gefunden und die Internetschnittstelle mal ausgewertet und mit dem Wireshark ausgewertet: MessageType: P_CONTROL_HARD_RESET_CLIENT_V2 - denke somit, dass das TLS Handshake nicht funktioniert .... werde mal eine andere einfach Portweiterleitung testen ....
Der Ausdruck deines OpenVPN Client Logs sollte auch noch weitere Details dazu haben !!
Du solltest den Client erstmal direkt im lokalen Netzwerk 192.168.177.0 testen wenn du es nicht eh schon machst.
Das OpenVPN Client Log hat dann ale Details warum ein Tunnelaufbau scheitert !
Details dazu auch hier:
OpenVPN Server installieren auf pfSense Firewall, Mikrotik. DD-WRT oder GL.inet Router
Du solltest den Client erstmal direkt im lokalen Netzwerk 192.168.177.0 testen wenn du es nicht eh schon machst.
Das OpenVPN Client Log hat dann ale Details warum ein Tunnelaufbau scheitert !
Details dazu auch hier:
OpenVPN Server installieren auf pfSense Firewall, Mikrotik. DD-WRT oder GL.inet Router
Der Aufbau aus dem lokalen LAN mittels VPN Client funktioniert wunderbar (sowohl aus dem .177er als auch aus dem .178er Netz ... Was aber nicht klappt ist ein einfaches Portforwarding (aus dem Internet über die Fritzbox zum Asus und somit ins LAN der Clients) .... Habe sowohl auf der Fritzbox das Forwarding auf die WAN IP des Asus als auch das Forwarding auf der WAN Schnittstelle des ASUS eingetragen .....
Hier ein kleiner Auszug von extern:
2017-04-28 15:06:44 EVENT: RESOLVE
2017-04-28 15:06:44 Contacting xx.xx.xxx.xx:1194 via UDP
2017-04-28 15:06:44 EVENT: WAIT
2017-04-28 15:06:44 SetTunnelSocket returned 1
2017-04-28 15:06:44 Connecting to [cpl5jafdxxxxxxqke7k7fp.myfritz.net]:1194 (xx.xx.xxx.xx) via UDPv4
2017-04-28 15:06:44 NET Internet:ReachableViaWiFi/-R t------
2017-04-28 15:06:54 Server poll timeout, trying next remote entry...
2017-04-28 15:06:54 EVENT: RECONNECTING
2017-04-28 15:06:54 EVENT: RESOLVE
2017-04-28 15:06:54 Contacting xx.xx.xxx.xx:1194 via UDP
2017-04-28 15:06:54 EVENT: WAIT
2017-04-28 15:06:54 SetTunnelSocket returned 1
2017-04-28 15:06:54 Connecting to [cpl5jafdxxxxxxqke7k7fp.myfritz.net]:1194 (xx.xx.xxx.xx) via UDPv4
Hier ein kleiner Auszug von extern:
2017-04-28 15:06:44 EVENT: RESOLVE
2017-04-28 15:06:44 Contacting xx.xx.xxx.xx:1194 via UDP
2017-04-28 15:06:44 EVENT: WAIT
2017-04-28 15:06:44 SetTunnelSocket returned 1
2017-04-28 15:06:44 Connecting to [cpl5jafdxxxxxxqke7k7fp.myfritz.net]:1194 (xx.xx.xxx.xx) via UDPv4
2017-04-28 15:06:44 NET Internet:ReachableViaWiFi/-R t------
2017-04-28 15:06:54 Server poll timeout, trying next remote entry...
2017-04-28 15:06:54 EVENT: RECONNECTING
2017-04-28 15:06:54 EVENT: RESOLVE
2017-04-28 15:06:54 Contacting xx.xx.xxx.xx:1194 via UDP
2017-04-28 15:06:54 EVENT: WAIT
2017-04-28 15:06:54 SetTunnelSocket returned 1
2017-04-28 15:06:54 Connecting to [cpl5jafdxxxxxxqke7k7fp.myfritz.net]:1194 (xx.xx.xxx.xx) via UDPv4
Das sieht dann aber gut aus. Das zeigt das OVPN dann rennt.
Dann liegt der Fehler bei lokalen Firewalls oder sowas...
Dann liegt der Fehler bei lokalen Firewalls oder sowas...
Das seltsame ist, wenn ich die NAT Funktion auf dem Asus ausschalte, dann klappt der VPN Zugriff genau einmal .... und beim nächsten Mal nicht mehr .... habe die Firewall auch dem ASUS im Moment mal deaktiviert und auch auf der Fritzbox "Exposed Host" auf die IP des Asus geschaltet ... bringt ebenfalls nichts .... ich denke es liegt viel mehr an der Netzwerkadressübersetzung ... Aber eine Route wurde ja auf der Fritzbox gesetzt .... (wenn NAT auf dem ASUS ausgeschalten ist) ....
Das mit dem NAT und ASUS hatten wir hier neulich schon mal. Dabei kam dann raus das das NAT gar nicht wirklich abschaltbar ist und dort vermutlich ein Firmware Bug existiert.
Dafür spricht auch dein Verhalten...
Das müsste man aber mal genau mit einem Wireshark Trace ansehen wenn NAT einmal an ist und wenn es aus ist.
Dafür spricht auch dein Verhalten...
Das müsste man aber mal genau mit einem Wireshark Trace ansehen wenn NAT einmal an ist und wenn es aus ist.
Hallo,
Was sagt der Mitschnitt deines LAN Ports wo dein ASUS dranpappt?
Dem OpenVPN Server andere Ports vergeben?
https://www.tutonaut.de/anleitung-myfritz-konto-als-dyndns-ersatz-nutzen ...
Gruß,
Peter
Zitat von @marshall75000:
Habe sowohl auf der Fritzbox das Forwarding auf die WAN IP des Asus als auch das Forwarding auf der WAN Schnittstelle des ASUS eingetragen .....
Das ist Blödsinn. Du brauchst nur ein Portforwarding in der Fritte auf die WAN IP deines ASUS. Du verwendest dort doch eine Statische manuell eingetragene IP, oder?Habe sowohl auf der Fritzbox das Forwarding auf die WAN IP des Asus als auch das Forwarding auf der WAN Schnittstelle des ASUS eingetragen .....
Hier ein kleiner Auszug von extern:
Extern von was?Was sagt der Mitschnitt deines LAN Ports wo dein ASUS dranpappt?
2017-04-28 15:06:44 Contacting xx.xx.xxx.xx:1194 via UDP
Hast du UDP 1194 freigegeben oder TCPIP?Dem OpenVPN Server andere Ports vergeben?
https://www.tutonaut.de/anleitung-myfritz-konto-als-dyndns-ersatz-nutzen ...
Gruß,
Peter
Das könnte leicht möglich sein ...
Ja, die WAN IP des ASUS ist statisch mit 192.168.177.3 inkl. Mask, Gateway und DNS eingetragen ... (Fritte hat 192.168.177.1). LAN IP des ASUS ist 192.168.178.1). Der Auszug war aus dem Log eines OpenVPN Client von extern, welcher eben keine Verbindung zum ASUS VPN aufbauen kann.
Es ist UDP 1194 freigegeben und auch keine anderen Ports auf dem VPN Server eingetragen ...
Kann es vielleicht sein, dass die Fritte eine andere IP braucht (z.b. 10.xxx.xxx.xxx)? Wobei ich nach wie vor glaube, dass es am NAT liegt ....
Es ist UDP 1194 freigegeben und auch keine anderen Ports auf dem VPN Server eingetragen ...
Kann es vielleicht sein, dass die Fritte eine andere IP braucht (z.b. 10.xxx.xxx.xxx)? Wobei ich nach wie vor glaube, dass es am NAT liegt ....
Hallo,
Nur Fakten zählen, nicht glauben.
Was sagt das LOG des ASUS? Der schreibt doch sicherlich was an dessen WAN geblockt wird, oder?
Ist dein OpenVPN am WAN Port oder am LAN Port gebunden?
Deine IPs deines OpenVPN sind nicht zufällig die ausm LAN oder WAN?
Stell also erstmal fest ob die Fritte oder ASUS dich hindert... Wireshark sagt es dir was auf den TransferNetz (Quasi DMZ) zwischen deiner Fritte und ASUS passiert. Fritte IP 192.168.177.1 - SN 255.255.255.0 und deiner ASUS WAN IP 192.168.177.3 - SN 255.255.255.0 - GW 192.168.177.1 ist vollkommen OK... Das gleiche gilt auch schon mal für eine Fritte...
Bedenke die Fritte macht den Paketmitschnitt PRO ETHx Port - also den richtigen wählen.
Dort solltest du sehen ob deine OpenVPN Anfragen zum Asus gehen und ob von dort etwas zurückkommt. Wenn nichts zurückkommt - am ASUS suchen, evtl Werkseinstellung und manuell neu anfangen...
Gruß,
Peter
Zitat von @marshall75000:
Kann es vielleicht sein, dass die Fritte eine andere IP braucht (z.b. 10.xxx.xxx.xxx)?
Nein, warum, nutzt dein VPN etwas dessen IPs...Kann es vielleicht sein, dass die Fritte eine andere IP braucht (z.b. 10.xxx.xxx.xxx)?
Wobei ich nach wie vor glaube, dass es am NAT liegt ....
Paketmitschnitt des LAN Ports deiner Fritte sagt mehr als dein "glaube" Nur Fakten zählen, nicht glauben.Was sagt das LOG des ASUS? Der schreibt doch sicherlich was an dessen WAN geblockt wird, oder?
Ist dein OpenVPN am WAN Port oder am LAN Port gebunden?
Deine IPs deines OpenVPN sind nicht zufällig die ausm LAN oder WAN?
Stell also erstmal fest ob die Fritte oder ASUS dich hindert... Wireshark sagt es dir was auf den TransferNetz (Quasi DMZ) zwischen deiner Fritte und ASUS passiert. Fritte IP 192.168.177.1 - SN 255.255.255.0 und deiner ASUS WAN IP 192.168.177.3 - SN 255.255.255.0 - GW 192.168.177.1 ist vollkommen OK... Das gleiche gilt auch schon mal für eine Fritte...
Bedenke die Fritte macht den Paketmitschnitt PRO ETHx Port - also den richtigen wählen.
Dort solltest du sehen ob deine OpenVPN Anfragen zum Asus gehen und ob von dort etwas zurückkommt. Wenn nichts zurückkommt - am ASUS suchen, evtl Werkseinstellung und manuell neu anfangen...
Gruß,
Peter
Ok, habe bis dato leider noch nicht sehr viel mit Wireshark gearbeitet ... haben nun aber mal die LAN2 Schnittstelle an der Fritzbox mitgeschnitten (mit einem Remotezugriff von extern (80.150.146.179) einmal über RDP Port 5550 und das andere mal über OpenVPN UDP 1194. Vielleicht kann sich mal jemand die Daten in den Wireshark ziehen und mir sagen ob es zu erkennen ist? Auf dem ASUS selbst kann ich leider nichts mitschneiden. Wie man das per Wireshark erledigt weiss ich leider ebenfalls nicht ....
OpenVPN_UDP_Port_1194_von_extern.pcap
MS_remoteDesktop_Port_5550_von_extern.pcap
OpenVPN_UDP_Port_1194_von_extern.pcap
MS_remoteDesktop_Port_5550_von_extern.pcap
Wie man das per Wireshark erledigt weiss ich leider ebenfalls nicht ....
Einfach indem du den Port über ein Wireshark mit einem Bridged Interface "durchschleifst":https://www.heise.de/ct/artikel/Ethernet-Bridge-als-Sniffer-Quelle-22148 ...
Netzwerk Management Server mit Raspberry Pi
Alternativ mit Port Mirroring auf dem Switch sofern dein Switch das supportet. Damit kann man den gesamten Traffic eines Switchports (den den du mitlesen willst) auf einen anderen, freien Port spiegeln wo man einen Wireshark anklemmt.
Kannst du in dem o.a. Trace UDP 1194 Pakete sehen mit der öffentlichen Absender IP ??
Exportiere doch so ein Paket (sofern es im Trace vorhanden ist) mal als ASCII Text File aus diesem Trace und poste den hier dann erspart uns das das Downloaden wohlmöglich Viren- und Trojaner verseuchter Sniffer Dateien
Habe nun mal den LAN Port der Fritzbox Mitgeschnitten. Es zeigt zwar an, dann von der externen IP eine Verbindung mit 192.168.177.3 und UDP Port 1194 aufgebaut werden soll, aber warum das nicht klappt, zeigt mit leider der Mitschnitt nicht. Auf dem Asus kann ich leider keine solchen Mitschnitt auf dessen LAN Schnittstelle machen. Und extra einen Server mit 2 Netzwerkkarten als Bridge einzurichten, ist mir echt zu viel ...
Hier das Protokoll:
Frame 40: 56 bytes on wire (448 bits), 56 bytes captured (448 bits)
Encapsulation type: Ethernet (1)
Arrival Time: Apr 28, 2017 20:07:27.554629000 Mitteleuropäische Sommerzeit
[Time shift for this packet: 0.000000000 seconds]
Epoch Time: 1493402847.554629000 seconds
[Time delta from previous captured frame: 0.095904000 seconds]
[Time delta from previous displayed frame: 2.400501000 seconds]
[Time since reference or first frame: 19.382334000 seconds]
Frame Number: 40
Frame Length: 56 bytes (448 bits)
Capture Length: 56 bytes (448 bits)
[Frame is marked: True]
[Frame is ignored: False]
[Protocols in frame: eth:ethertype:ip:udp:openvpn]
[Coloring Rule Name: UDP]
[Coloring Rule String: udp]
Ethernet II, Src: Avm_b1:77:32 (24:65:11:b1:77:32), Dst: AsustekC_64:16:a4 (d0:17:c2:64:16:a4)
Destination: AsustekC_64:16:a4 (d0:17:c2:64:16:a4)
Address: AsustekC_64:16:a4 (d0:17:c2:64:16:a4)
.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
Source: Avm_b1:77:32 (24:65:11:b1:77:32)
Address: Avm_b1:77:32 (24:65:11:b1:77:32)
.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
Type: IPv4 (0x0800)
Internet Protocol Version 4, Src: 80.150.146.179, Dst: 192.168.177.3
0100 .... = Version: 4
.... 0101 = Header Length: 20 bytes (5)
Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
Total Length: 42
Identification: 0x4824 (18468)
Flags: 0x00
Fragment offset: 0
Time to live: 122
Protocol: UDP (17)
Header checksum: 0xa3a9 [validation disabled]
[Header checksum status: Unverified]
Source: 80.150.146.179
Destination: 192.168.177.3
[Source GeoIP: Unknown]
[Destination GeoIP: Unknown]
User Datagram Protocol, Src Port: 64339, Dst Port: 1194
Source Port: 64339
Destination Port: 1194
Length: 22
Checksum: 0xa0e1 [unverified]
[Checksum Status: Unverified]
[Stream index: 5]
OpenVPN Protocol
Type: 0x38 [opcode/key_id]
0011 1... = Opcode: P_CONTROL_HARD_RESET_CLIENT_V2 (0x07)
.... .000 = Key ID: 0
Session ID: 7757577087919225540
Message Packet-ID Array Length: 0
Message Packet-ID: 0
Hier das Protokoll:
Frame 40: 56 bytes on wire (448 bits), 56 bytes captured (448 bits)
Encapsulation type: Ethernet (1)
Arrival Time: Apr 28, 2017 20:07:27.554629000 Mitteleuropäische Sommerzeit
[Time shift for this packet: 0.000000000 seconds]
Epoch Time: 1493402847.554629000 seconds
[Time delta from previous captured frame: 0.095904000 seconds]
[Time delta from previous displayed frame: 2.400501000 seconds]
[Time since reference or first frame: 19.382334000 seconds]
Frame Number: 40
Frame Length: 56 bytes (448 bits)
Capture Length: 56 bytes (448 bits)
[Frame is marked: True]
[Frame is ignored: False]
[Protocols in frame: eth:ethertype:ip:udp:openvpn]
[Coloring Rule Name: UDP]
[Coloring Rule String: udp]
Ethernet II, Src: Avm_b1:77:32 (24:65:11:b1:77:32), Dst: AsustekC_64:16:a4 (d0:17:c2:64:16:a4)
Destination: AsustekC_64:16:a4 (d0:17:c2:64:16:a4)
Address: AsustekC_64:16:a4 (d0:17:c2:64:16:a4)
.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
Source: Avm_b1:77:32 (24:65:11:b1:77:32)
Address: Avm_b1:77:32 (24:65:11:b1:77:32)
.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
Type: IPv4 (0x0800)
Internet Protocol Version 4, Src: 80.150.146.179, Dst: 192.168.177.3
0100 .... = Version: 4
.... 0101 = Header Length: 20 bytes (5)
Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
Total Length: 42
Identification: 0x4824 (18468)
Flags: 0x00
Fragment offset: 0
Time to live: 122
Protocol: UDP (17)
Header checksum: 0xa3a9 [validation disabled]
[Header checksum status: Unverified]
Source: 80.150.146.179
Destination: 192.168.177.3
[Source GeoIP: Unknown]
[Destination GeoIP: Unknown]
User Datagram Protocol, Src Port: 64339, Dst Port: 1194
Source Port: 64339
Destination Port: 1194
Length: 22
Checksum: 0xa0e1 [unverified]
[Checksum Status: Unverified]
[Stream index: 5]
OpenVPN Protocol
Type: 0x38 [opcode/key_id]
0011 1... = Opcode: P_CONTROL_HARD_RESET_CLIENT_V2 (0x07)
.... .000 = Key ID: 0
Session ID: 7757577087919225540
Message Packet-ID Array Length: 0
Message Packet-ID: 0
Hallo Leute,
habe nun eine für mich passende Lösung gefunden. Ich erstelle einfach die VPN Verbindung auf die Fritzbox und habe dort zwei "Push Route" eingetragen (zum .177er und .178er Netz) und gelange somit auch in mein Client Netzwerk. Weshalb allerdings das Portforwarding nicht geht erschließt sich mir leider immer noch nicht, aber auf der anderen Seite ist es auch ganz beruhigend zu wissen, dass man ohne VPN nicht in das .178er Netz kommt
) Somit nochmals besten Dank an alle welche mir Tipps und Hinweise gegeben haben.
habe nun eine für mich passende Lösung gefunden. Ich erstelle einfach die VPN Verbindung auf die Fritzbox und habe dort zwei "Push Route" eingetragen (zum .177er und .178er Netz) und gelange somit auch in mein Client Netzwerk. Weshalb allerdings das Portforwarding nicht geht erschließt sich mir leider immer noch nicht, aber auf der anderen Seite ist es auch ganz beruhigend zu wissen, dass man ohne VPN nicht in das .178er Netz kommt
) Somit nochmals besten Dank an alle welche mir Tipps und Hinweise gegeben haben.
Hallo,
Gruß,
Peter
Zitat von @marshall75000:
Weshalb allerdings das Portforwarding nicht geht erschließt sich mir leider immer noch nicht
Das funktioniert sehr wohl auf einer Fritzbox. Du darfst aber nichts mit VPN Konfiguriert haben - egal ob Aktiviert oder deaktiviert. Es darf nichts konfiguriert sein was irgendwie mit VPN zu tun hat, dann behält die Fritte nicht die Ports für sich selbst, sondern leitet die Brav weiter wenn du es ihr sagst.Weshalb allerdings das Portforwarding nicht geht erschließt sich mir leider immer noch nicht
Gruß,
Peter
Was das Paket anbetrifft ist das auf alle Fälle ein OpenVPN Frame (UDP 1194) das kommt also an.
Das Port Forwarding auf der FB klappt also fehlerlos, ansonsten wäre das Paket ja wohl kaum nicht mit der Ziel IP ASUS weitergeleitet worden:
Layer 2 Macs: Src: Avm_b1:77:32 (24:65:11:b1:77:32), Dst: AsustekC_64:16:a4 (d0:17:c2:64:16:a4)
Layer 3 IPs: Src: 80.150.146.179, Dst: 192.168.177.3
Layer 4 Ports: UDP, Src Port: 64339, Dst Port: 1194
Die 80er IP kommt aus dem Netz der DTAG
Das sieht also alles sehr gut aus und funktioniert wie es soll.
Fragt sich wo du jetzt hier ein Problem hast ??!!
Kollege Pjordorf verwechselt jetzt hier sicher die IPsec VPN Funktion der FritzBox selber die du ja gar nicht nutzt. OpenVPN mit UDP 1194 forwardet die FritzBox natürlich vollkommen problemlos, da sie selber keinerlei OpenVPN Support hat !
Works as designed !!
Das Port Forwarding auf der FB klappt also fehlerlos, ansonsten wäre das Paket ja wohl kaum nicht mit der Ziel IP ASUS weitergeleitet worden:
Layer 2 Macs: Src: Avm_b1:77:32 (24:65:11:b1:77:32), Dst: AsustekC_64:16:a4 (d0:17:c2:64:16:a4)
Layer 3 IPs: Src: 80.150.146.179, Dst: 192.168.177.3
Layer 4 Ports: UDP, Src Port: 64339, Dst Port: 1194
Die 80er IP kommt aus dem Netz der DTAG
Das sieht also alles sehr gut aus und funktioniert wie es soll.
Fragt sich wo du jetzt hier ein Problem hast ??!!
Kollege Pjordorf verwechselt jetzt hier sicher die IPsec VPN Funktion der FritzBox selber die du ja gar nicht nutzt. OpenVPN mit UDP 1194 forwardet die FritzBox natürlich vollkommen problemlos, da sie selber keinerlei OpenVPN Support hat !
Works as designed !!
Hallo,
Ne, nicht. Das war eine eher allgemeine aussage von mir. Das die Boxen kein OpenVPN können ist mir klar, ebenso wie mir klar ist das der TO jetzt kein IPSec Server hinter der Fritte betreiben kann solange wie eben für der Fritte irgendwelche VPN Einstellungen eingetragen sind, ob aktiv oder nicht. Es reicht manchmal nicht nur etwas zu deaktivieren bzw. nicht zu nutzen.
Gruß,
Peter
Ne, nicht. Das war eine eher allgemeine aussage von mir. Das die Boxen kein OpenVPN können ist mir klar, ebenso wie mir klar ist das der TO jetzt kein IPSec Server hinter der Fritte betreiben kann solange wie eben für der Fritte irgendwelche VPN Einstellungen eingetragen sind, ob aktiv oder nicht. Es reicht manchmal nicht nur etwas zu deaktivieren bzw. nicht zu nutzen.
Works as designed !!
Si. Zumindest bei dem einen Paket welches der TO am 02.05. mitgeschnitten und uns gezeigt hat. Da stellt sich die Frage was sein ASUS RT-N18U dann damit gemacht hat Gruß,
Peter
Da stellt sich die Frage was sein ASUS RT-N18U dann damit gemacht hat
Das ist zweifelsohne richtg !!Da wäre dann das Log des Routers oder der CLI Output hilfreich. Aber gehen wir mal davon aus das sich dann ein OpenVPN Tunnel sauber etwabliert.
Übrigens kann man das natürlich auch alles am OpenVPN Client Logg sehen
