VPN gleiches Netz + 1 statische Route?

hege

Es gibt bei den Routen eine Metrik, welche die Priorität der Route bezeichnet.

Der Default Gateway hat normalerweise sagen wir mal Metrik 1000, während jede manuell hinzugefügte Route Metrik 100 hat. (Die über OpenVPN übermittelte hat etwa 100)

Dadurch gibt es kein Chaos.

cyberexpress

Servus!

ich fürchte, du hast die Zeichnung falsch aufgefasst. (oder ich habs immer noch nicht verstanden) :-)

Ich wähle mich vom Client PC1 (Rechts in der Zeichnung) in mein Zielnetzwerk ein, und bekomme die IP 172.20.16.10 zugewiesen. Ich verbinde mich dann via RDP zum PC1 (im Zielnetzwerk IP: 192.168.2.10).
Das war die rote Linie.

Jetzt öffne ich Word auf PC1 (Zielnetzwerk) und möchte auf den Client Drucker (Client Netzwerk, also rechts) auf die IP 192.168.2.40 drucken. (der Weg war die blaue Linie)

Kannst du mir deine Lösung, falls der Ansatz noch immer der gleiche ist, mit den IPs entsprechend beschreiben, wie das funktionieren sollte?

Die pfSense ist derzeit so eingestellt, dass die Verbindungen zu den lokalen Netzwerkgeräten verloren geht nach der VPN Einwahl, weil eben Ziel und Quelle im gleichen Netzbereich sind und ich Probleme mit dem Routing hatte, wenn ich am Ziel geräte erreichen wollte, und das System teils glaubte, die Geräte in meinem lokalen Netz finden zu können.

lg.

jahonix

Wie soll denn ein Host links einen Host von rechts durch ein Transit-Netzwerk erreichen, wenn auf beiden Seite das gleiche Netzwerk vorliegt?
In dem Fall wird der Traffic nicht durch das Gateway geschickt, weil die Auflösung lokal funktioniert (egal, ob die IP dort auch vorhanden ist oder nicht).

Zwei Möglichkeiten:
a) Du bridgest beide Seiten
b) eine Seite erhält ein anderes Subnetz und mindestens das GW kennt die Route.

c) …da war mal was, so dass OpenVPN zwei Netze gleicher Range miteinander bringen konnte. IIRC!
Suche mal danach hier im Forum.

hege

Du bringst hier etwas durcheinander.

Links = VPN / Rechts = LAN

Du wählst dich von Rechts über OpenVPN ein. Anschließend verbindest du dich über RDP auf Links und möchtest dort drucken. -> Links kann aber nicht direkt auf den Drucker rechts zugreifen, da nur rechts nach links eine Verbindung aufgebaut hat, aber nicht umgekehrt (das wäre Site2Site)
D.h. Links erreicht den Drucker rechts über RDP, damit das funktioniert muss Rechts trotz vorhanderer VPN Verbindung immer noch auf das restliche rechts-netz zugreifen müssen, und hier beginnt dein Problem.

Du hast in deiner OpenVPN Konfiguration unter "IPv4 Local Network/s" 192.168.2.0/24 stehen, dadurch kann rechts, sobald die vpn Verbindung aufgebaut ist nicht mehr auf das restliche Netz zugreifen, da du beim Verbindungsaufbau eine höherwertigere Route durch OpenVPN eingetragen wird.

Stellst du stattdessen ein "IPv4 Local Network/s" 192.168.2.10/32 und verbindest du dich über VPN, so erreichst du Links und kannst aber immer noch auf das restliche Rechts zugreifen (ausgenommen 192.168.2.10) -> Problem gelöst.

Verstanden?

jahonix

@hege:

Du bringst hier etwas durcheinander.
Links = VPN / Rechts = LAN

Damit betrachtest Du nur die Hälfte der Schilderung und somit auch nicht das Problem.

local-left 192.168.2.0/24
local-right 192.168.2.0/24
transit 172.20.16.0/24

Der RDP-Client (rechts) bekommt als Option mit, zB lokale Drucker an den RDP-Host (links) weiterzureichen.
Der Host (links) wird diesen Drucker aber nie erreichen können, da die Adresse des Druckers gleichfalls in seiner Broadcast-Domain liegt.
Als Lösung bietet sich ein Bridging beider Seiten an oder unterschiedliche Netze links und rechts. Dann kann zwischen beiden geroutet werden.
Wenn Du dem RDP-Client (rechts) eine /32 lokal gibst, dann wird er seinen lokalen Drucker selbst nicht mehr erreichen können.

hege

@jahonix:

Der RDP-Client (rechts) bekommt als Option mit, zB lokale Drucker an den RDP-Host (links) weiterzureichen.
Der Host (links) wird diesen Drucker aber nie erreichen können,

Bei einer RDP Verbindung hat links keine direkte Verbindung zum Drucker Rechts, sondern der RDP-Client (rechts) spielt den Druckserver und reicht die Druckjobs an den Drucker im lokalen Netzwerk weiter.
Schonmal versucht einen lokalen LPT Drucker über RDP durchzureichen? Das funktioniert genauso, obwohl der LPT Drucker nicht über IP erreichbar ist.

Wie bereits mehrfach ausgeführt besteht das "Problem" lediglich darin, dass bei vorhandener VPN Verbindung der Client (rechts) nicht mehr auf sein restlichen LAN Netz zugreifen kann, da nach erfolgreichem Verbindungsaufbau der Client (rechts) das Netz 192.168.2.0/24 über VPN erreichen will und der Drucker (rechts) aber im lokalen Netz liegt.

Bitte erkläre mir wieso deiner Meinung nach bei einer 32er Route der lokale Drucker nicht mehr angesprochen werden kann?

Bitte einfach mal ausprobieren bevor du Bridging empfiehlst, welches nur jede Menge Schrotttraffic verursacht und die Leitung ev. lahm legt.

cyberexpress

Hallo Leute,

ist schon etwas länger her - eber das Problem habe ich immer noch nicht lösen können.
Ich habe die Variante mit dem "durchreichen" der Druckerverbindung via RDP schon ausprobiert. Das hat auch schon so geklappt. Allerdings musste ich dafür ziemlich viel konfigurieren, auch in den Rechten wegen dem Druckertreiber. Ich will dem User, der sich da einwählt nicht alle Rechte geben. Nun wurde ein Systemwiederherstellungspunkt ausgewählt auf dem pc und alles beginnt von vorne. Deshalb will ich das jetzt richtig machen.

Nach einer Woche Recherche und vielen Stunden probieren, habe ich jetzt meinen WRT54GL mit der Tomato Firmware als VPN Client verwenden können. Die Einwahl klappt, er bekommt eine IP und ist auch vom VPN Netz erreichbar. Der Plan war jetzt, dass ich ein Port Forwarding mache - also vom VPN Netz zum Drucker:

SRC: TCP 9100 TARGET: TCP 9100 IP: 192.168.2.240

Nun habe ich aber festgestellt, dass der Router im Netzwerk nicht mehr erreichbar ist, sobald ich den WAN Port anstecke.

Konfiguration:

WAN: DHCP -> 192.168.2.148/24 -> openVPN IP: 172.20.0.18
LAN: STATIC -> 192.168.2.250/24

Wenn ich das Kabel an WAN nicht anstecke, wird die VPN Verbindung nicht aufgebaut und der Router ist ganz normal unter der 192.168.2.250 erreichbar. Sobald die Verbindung zum VPN Server aufgebaut wird, ist er weg.

Hat jemand eine Idee, woran das liegt? Hat doch das eine mit dem anderen nichts zu tun?!

lg.

cyberexpress

hier nochmal zur Verdeutlichung

VPN.png_thumb

jahonix

Kann es sein, dass Du Dir mit dem Kabel am WAN einen lokalen Ring aufbaust?
Entweder legst Du Dein Netzwerk mit einem Broadcast-Storm lahm oder ein konfiguriertes Spanning-Tree verhindert das (und auch die gewünschte Kommunikation). Ich kann den X2000 und seine Anschlüsse nicht wirklich erkennen.

Was ist eigentlich ein "Splitter" und warum ändert Du nicht auf einer der Seiten das Subnetz, dann ist die Konfiguration ganz simpel?

cyberexpress

Hallo Jahonix,

Kann es sein, dass Du Dir mit dem Kabel am WAN einen lokalen Ring aufbaust?

WAN und LAN des WRT54GL hängen quasi zusammen an den LAN Ports des X2000. Also nehme ich an, dass es das ist, was du meinst? Ist das ein Problem?

Entweder legst Du Dein Netzwerk mit einem Broadcast-Storm lahm oder ein konfiguriertes Spanning-Tree verhindert das (und auch die gewünschte Kommunikation). Ich kann den X2000 und seine Anschlüsse nicht wirklich erkennen.

Welche weiteren Informationen brauchst du, um mehr darüber sagen zu können? der X2000 verbindet mich ins Internet. Der WRT54GL hängt einfach nur im Netz für den Test.

Was ist eigentlich ein "Splitter" und warum ändert Du nicht auf einer der Seiten das Subnetz, dann ist die Konfiguration ganz simpel?

Ein Splitter splittet die Frequenzen zwischen Telefon und Internet auf. Bei DSL ist das doch üblich?
Das mit dem Subnetz bringt mich nur einen halben Meter weiter. Ich kann mir die Netzwerke, von denen sich andere VPN Clients einwählen nicht aussuchen. Da schien mir die Sache mit dem Router die sauberste Lösung, wenn es dann mal funktionieren würde :-)

Habe ich einen Denkfehler?!

Habe gerade etwas anderes versucht: Habe den WRT54GL komplett vom Netzwerk genommen. WAN Steckt jetzt am LAN vom X2000 und mein Notebook ist direkt mit dem WRT54GL am LAN Port verbunden. Sobald der Stecker im WAN ist, ist der WRT54GL am LAN nicht mehr erreichbar. Dafür muss es doch eine Lösung geben? Im jetztigen Fall sind WAN und LAN in keinem Fall verbunden!

lg.

JeGr

WAN und LAN des WRT54GL hängen quasi zusammen an den LAN Ports des X2000. Also nehme ich an, dass es das ist, was du meinst? Ist das ein Problem?

Ja. Ist es. Zwei Ports am gleichen Switch mit gleichen IP Ranges funktionieren nicht, weil das Gerät nur über eines sprechen kann, nicht über beide, da er nicht weiß welcher Port Vorrang hat. Zudem baust du dann noch einen Ring auf, was gar nicht geht und normalerweise dazu führt, dass eine entsprechende Erkennung einen der Ports Not-abschaltet.

Und ja ein SPlitter trennt Telefon und DSL. Bei altem DSL zumindest, richtig. Aber welches Gerät baut dann die Internetverbindung auf? Denn an einen Splitter einen Switch zu hängen macht eigentlich nur in ganz wenigen Szenarien Sinn.

cyberexpress

Servus,

ich kann doch zwei verschiedene Netzwerke an einen Switch hängen? (ohne DHCP war das bei mir noch nie ein Problem?)
In meinem letzten Szenario habe ich den Fall nicht mehr.

Notebook -> WRT54GL(LAN) -> WRT54GL(WAN) -> X2000(LAN) -> X2000(WAN) -> Splitter …..

Also der X2000 macht die Einwahl. Und auf dem WRT54GL wird die VPN Verbindung zu einem Server aufgebaut.
Auch wenn ich jetzt keinen Ring mehr habe und auch nicht mehr beide Ports an einem Switch habe, ist die LAN Adresse des WRT54GL nicht mehr erreichbar, sobald das Gerät eine VPN Verbindung erfolgreich aufgebaut hat. Wenn ich das LAN Kabel zum Notebook ab und wieder anstecke, ist der Router wieder kurz erreichbar. Beim Anstecken wird die VPN Verbindung getrennt und dann gleich wieder aufgebaut, dann ist der Router wieder nicht erreichbar.

Redirect internet traffic is der Haken raus. Willst du es dir mal live ansehen? (Skype & Teamviewer?)
-> für die anderen, werde ich natürlich das Resultat hier posten!

lg.

JeGr

Nochmal: Wenn du auf WAN und LAN Seite das gleiche IP Subnetz benutzt wird das nicht funktionieren!

Zitat:

WAN: DHCP -> 192.168.2.148/24 -> openVPN IP: 172.20.0.18
LAN: STATIC -> 192.168.2.250/24

–> beide Netzteile sind im gleichen /24 Netz 192.168.2.x --> das darf nicht sein.

cyberexpress

Servus,

ja - da ist wohl was wahres dran :-)
Jetzt ist er zumindest mal im VPN Netz und im LAN erreichbar. Das NAT will nur noch nicht. Bin mit iptables nicht noch nicht ganz auf Kurs:

Hier der Output von ifconfig:

br0 Link encap:Ethernet HWaddr 20:AA:4B:22:7E:1E
inet addr:192.168.1.250 Bcast:192.168.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:3723 errors:0 dropped:0 overruns:0 frame:0
TX packets:1399 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:638159 (623.2 KiB) TX bytes:678375 (662.4 KiB)

eth0 Link encap:Ethernet HWaddr 20:AA:4B:22:7E:1E
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:6966 errors:0 dropped:0 overruns:0 frame:0
TX packets:1815 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1419031 (1.3 MiB) TX bytes:739037 (721.7 KiB)
Interrupt:4 Base address:0x1000

eth1 Link encap:Ethernet HWaddr 20:AA:4B:22:7E:20
UP BROADCAST RUNNING ALLMULTI MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
Interrupt:13 Base address:0x5000

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MULTICAST MTU:16436 Metric:1
RX packets:22 errors:0 dropped:0 overruns:0 frame:0
TX packets:22 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:1622 (1.5 KiB) TX bytes:1622 (1.5 KiB)

tun11 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:172.20.0.18 P-t-P:172.20.0.17 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:62 errors:0 dropped:0 overruns:0 frame:0
TX packets:64 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:3848 (3.7 KiB) TX bytes:3984 (3.8 KiB)

vlan0 Link encap:Ethernet HWaddr 20:AA:4B:22:7E:1E
UP BROADCAST RUNNING ALLMULTI MULTICAST MTU:1500 Metric:1
RX packets:3726 errors:0 dropped:0 overruns:0 frame:0
TX packets:1399 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:653593 (638.2 KiB) TX bytes:683971 (667.9 KiB)

vlan1 Link encap:Ethernet HWaddr 20:AA:4B:22:7E:1F
inet addr:192.168.2.121 Bcast:192.168.2.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:3240 errors:0 dropped:0 overruns:0 frame:0
TX packets:416 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:640050 (625.0 KiB) TX bytes:55066 (53.7 KiB)

iptables -L gibt folgendes aus:

Chain INPUT (policy DROP)
target prot opt source destination
ACCEPT all – anywhere anywhere
DROP all -- anywhere 192.168.2.121
DROP all -- anywhere anywhere state INVALID
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
ACCEPT all -- anywhere anywhere
ACCEPT all -- anywhere anywhere
ACCEPT icmp -- anywhere anywhere limit: avg 1/sec burst 5
ACCEPT udp -- anywhere anywhere udp dpts:33434:33534 limit: avg 5/sec burst 5
ACCEPT udp -- anywhere anywhere udp spt:bootps dpt:bootpc

Chain FORWARD (policy DROP)
target prot opt source destination
ACCEPT all -- anywhere anywhere
ACCEPT all -- anywhere anywhere

Chain OUTPUT (policy ACCEPT)
target prot opt source destination

Chain upnp (0 references)
target prot opt source destination

Chain wanin (0 references)
target prot opt source destination
ACCEPT tcp -- 172.20.0.18 192.168.1.240 tcp dpt:laserjet
ACCEPT tcp -- 172.20.0.18 192.168.1.240 tcp dpt:www

Chain wanout (0 references)
target prot opt source destination

In der Anlage habe ich meine derzeitigen NAT Regeln angehängt. Aber ich kann da auch keinen VPN Adapter auswählen. :-(

![Bildschirmfoto 2014-12-27 um 18.42.33.png](/public/imported_attachments/1/Bildschirmfoto 2014-12-27 um 18.42.33.png)
![Bildschirmfoto 2014-12-27 um 18.42.33.png_thumb](/public/imported_attachments/1/Bildschirmfoto 2014-12-27 um 18.42.33.png_thumb)

JeGr

IPTables? Screenshot? Huh? Was hat das da denn mit pfSense zu tun? verwirrt

cyberexpress

Hallo,

ja - hast du natürlich recht :-) Dachte man könnte das vielleicht noch als angrenzendes Gebiet betrachten. Ich habe es mittlerweile gelöst. Für die Allgemeinheit wie Versprochen:

iptables -t nat -I PREROUTING -i tun11 -p tcp –dport 9100 -j DNAT --to-destination 192.168.1.240

Das war die Lösung. Alles was vom VPN Netz an Port 9100 sendet, wird an 192.168.1.240 weitergeleitet.
Die Konfiguration unter Portforwarding in der Tomatofirmware hat keinen Einfluss darauf! Habe diese wieder gelöscht

liebe Grüße und Danke für die Unterstützung bei den anderen Fragen!