Support ( gelöst ) Zugriff von FB7590 auf Netzwerk & openVPN Server des ASUS RT-AX56U

[datamen]

Ausgangslage:

• FB7590 realisiert des DSL Zugang IP: 192.168.178.1
• ASUS Router hängt am LAN der FB750 mit IP: 192.168.178.2 baut aber eigenes Netzwerk 192.168.50.xxx auf.

Wie kann ich, wenn ich im LAN/WLAN der FB7590 bin, auf den ASUS Router (und Geräte an diesem) zugreifen, ohne mich ins LAN/WLAN desselben zu begeben?

Bin ich im LAN/WLAN des ASUS Routers (meine IP dann: 192.168.50.177) kann ich problemlos auf alle Geräte im IP Bereich 192.168.178.xxx zugreifen. Umgekehrt nicht

 

[Gelöschtes Mitglied 572719]

Haben die eigenen Subnetze einen Grund?
Wenn ja, dann die Routen bei den Geräten entsprechend setzen.

 

[datamen]

Auf den Gedanken mit den Routen bin ich auch schon gestoßen. Der ASUS RT-AX56U muss diese Route ins 192.168.178.xxx - Netz selbstständig gesetzt haben. Denn bin ich mit ihm per LAN/WLAN verbunden kann ich ja perfekt auf das 178.xxx-Netz der FB7590 zugreifen.

Nur wie ich jetzt die Route in der FB7590 setze damit ich aus dem 178.xxx-Netz auf das 50.xxx-Netz zugreifen kann ... das erschließt sich mir nicht.

Haben die eigenen Subnetze einen Grund?

Der ASUS RT-AX56U aktzeptiert es nicht, wenn am WAN-Zugang/Eingang und in "seinem" LAN/WLAN die selben Netze verwendet werden. Die WAN-IP bekommt er von der FB7590 per DHCP oder man gibt sie fest vor. (192.168.178.2)

Das LAN/WLAN "hinter ihm" legt er dann in ein anderes Netz. (192.168.50.xxx) - Wobei die "50" variabel nur nicht = 178 sein kann/darf.

 

[Osprey]

Der Asus ist am WAN Anschluss verbunden? Wegen NAT des Asus kommst du nicht ins LAN des Asus.

 

[datamen]

OK .. das habe ich auch schon irgendwo in den Weiten des www gelesen.

NAT ausschalten am WAN-Anschluß?

Du musst Regestriert sein, um das angehängte Bild zusehen.

 

[Osprey]

Entweder das oder an LAN Port statt WAN Port anschließen und an beiden Routern die 192.168.178." haben. Dazu muss aber der DHCP Server des Asus deaktiviert werden.

 

[datamen]

NAT am WAN-Port des ASUS deaktivieren hat auch nichts gebracht . Bliebe wohl wirklich nur die Variante den LAN1 am ASUS zu benutzen und den DHCP Server auf dem ASUS zu deaktivieren.

Eigentlich war das nicht Sinn und Zweck der Sache. Denn alle Geräte die mit dem ASUS per LAN/WLAN verbunden sind (im ASUS eigenen Netz 50.xxx) sollten per VPN ins Internet gehen.

Wenn ich jetzt LAN1 statt WAN als DSL-Input am ASUS verwende und DHCP ausschalte ... dann müsste ich auf den WLAN-Clients bei einem Wechsel vom FB7590-WLAN auf das ASUS-WLAN ja immer den Standard-Gateway auf die IP vom ASUS ändern, damit sie per VPN ins Netz gehen.

Oder ich lebe damit nur als ASUS-Client in das FB750-Netzwerk zu kommen und nicht umgekehrt.

 

[PingX]

ich habs bei mir so gelöst:
Asus WAN NAT aus
Asus IPV4 Firewall aus (zum Testen)
Route von Fritzbox ZUM Asus:
also in der Fritte folgende IPV4 Route anlegen:

192.168.2.0 255.255.255.0 192.168.178.xxx xx = IP vom Asus am WAN (zur FritzBox)

 

[datamen]

@PingX ... Danke! Habe es gerade selbst geschafft ... und zwar genau so wie du es beschrieben hast.

Jetzt muss ich bloß noch mal gucken wie ich den openVPN Server auf dem ASUS RT-AX56U von außen (unterwegs) erreiche. Nur eine Portweiterleitung in der FB7590 zum ASUS openVPN Port scheint nicht zu reichen.

 

[PingX]

du gehts schon von außen via FritzVPN (MyFritz) rein, oder - nur das soll sicher sein?

 

[datamen]

Nein! Ich wollte von außen via openVPN-Tool auf dem Notebook "durch" die FB7590 zum ASUS VPN openVPN Server.

openVPN Port ist auf der FB7590 geöffnet und weitergeleitet zum ASUS openVPN Server.

Spoiler: openVPN Log wenn ich die interne IP des ASUS nehme:

2021-01-22 15:58:07 WARNING: Compression for receiving enabled. Compression has been used in the past to break encryption. Sent packets are not compressed unless "allow-compression yes" is also set.
2021-01-22 15:58:07 DEPRECATED OPTION: --cipher set to 'AES-128-CBC' but missing in --data-ciphers (AES-256-GCM:AES-128-GCM). Future OpenVPN version will ignore --cipher for cipher negotiations. Add 'AES-128-CBC' to --data-ciphers or change --cipher 'AES-128-CBC' to --data-ciphers-fallback 'AES-128-CBC' to silence this warning.
2021-01-22 15:58:07 OpenVPN 2.5.0 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Oct 28 2020
2021-01-22 15:58:07 Windows version 10.0 (Windows 10 or greater) 64bit
2021-01-22 15:58:07 library versions: OpenSSL 1.1.1h  22 Sep 2020, LZO 2.10
Enter Management Password:
2021-01-22 15:58:13 TCP/UDP: Preserving recently used remote address: [AF_INET]192.168.178.2:54321
2021-01-22 15:58:13 UDP link local: (not bound)
2021-01-22 15:58:13 UDP link remote: [AF_INET]192.168.178.2:54321
2021-01-22 15:58:13 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
2021-01-22 15:58:13 [RT-AX56U] Peer Connection Initiated with [AF_INET]192.168.178.2:54321
2021-01-22 15:58:14 open_tun
2021-01-22 15:58:14 tap-windows6 device [OpenVPN TAP-Windows6] opened
2021-01-22 15:58:14 Notified TAP-Windows driver to set a DHCP IP/netmask of 10.8.0.6/255.255.255.252 on interface {E4AD8E6A-7C9A-4AC6-A430-FBC190D07EE9} [DHCP-serv: 10.8.0.5, lease-time: 31536000]
2021-01-22 15:58:14 Successful ARP Flush on interface [58] {E4AD8E6A-7C9A-4AC6-A430-FBC190D07EE9}
2021-01-22 15:58:14 IPv4 MTU set to 1500 on interface 58 using service
2021-01-22 15:58:19 Initialization Sequence Completed

Spoiler: openVPN Log wenn ich die ext. dydns nehme:

2021-01-22 16:02:41 WARNING: Compression for receiving enabled. Compression has been used in the past to break encryption. Sent packets are not compressed unless "allow-compression yes" is also set.
2021-01-22 16:02:41 DEPRECATED OPTION: --cipher set to 'AES-128-CBC' but missing in --data-ciphers (AES-256-GCM:AES-128-GCM). Future OpenVPN version will ignore --cipher for cipher negotiations. Add 'AES-128-CBC' to --data-ciphers or change --cipher 'AES-128-CBC' to --data-ciphers-fallback 'AES-128-CBC' to silence this warning.
2021-01-22 16:02:41 OpenVPN 2.5.0 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Oct 28 2020
2021-01-22 16:02:41 Windows version 10.0 (Windows 10 or greater) 64bit
2021-01-22 16:02:41 library versions: OpenSSL 1.1.1h  22 Sep 2020, LZO 2.10
Enter Management Password:
2021-01-22 16:02:50 TCP/UDP: Preserving recently used remote address: [AF_INET]55.543.133.173:54321
2021-01-22 16:02:50 UDP link local: (not bound)
2021-01-22 16:02:50 UDP link remote: [AF_INET]55.543.133.173:54321
2021-01-22 16:03:20 [UNDEF] Inactivity timeout (--ping-restart), restarting
2021-01-22 16:03:20 SIGUSR1[soft,ping-restart] received, process restarting
2021-01-22 16:03:25 TCP/UDP: Preserving recently used remote address: [AF_INET]55.543.133.173:54321
2021-01-22 16:03:25 UDP link local: (not bound)
2021-01-22 16:03:25 UDP link remote: [AF_INET]55.543.133.173:54321
2021-01-22 16:03:55 [UNDEF] Inactivity timeout (--ping-restart), restarting
2021-01-22 16:03:55 SIGUSR1[soft,ping-restart] received, process restarting
2021-01-22 16:04:00 TCP/UDP: Preserving recently used remote address: [AF_INET]55.543.133.173:54321
2021-01-22 16:04:00 UDP link local: (not bound)
2021-01-22 16:04:00 UDP link remote: [AF_INET]55.543.133.173:54321

IP Adresse ist nicht echt

 

[PingX]

Ah da hab ich was verwechselt, ich hab am Asus nur einen VPN-Client am laufen...

 

[datamen]

Hab's jetzt aufgegeben mit dem openVPN Server auf dem ASUS und stattdessen einen openVPN Server auf dem raspberry Pi aufgesetzt.

 

[Gelöschtes Mitglied 572719]

Warum eigentlich nicht gleich so, bzw. den IPSEC von der Fritte genutzt?

 

[datamen]

Weil ich dachte ... auf dem ASUS ist "die Arbeit" (openVPN Server) schon fertig verhanden .... und der Router kann "die Arbeit" übernehmen.

... nur habe ich es "um's Verrecken" nicht hinbekommen, dass der ASUS am WAN Port die Portweiterleitung von der FB7590 annimmt.

Mit dem rpi klappt es hingegen hervorragend.