LANCOM 1784VA routet zweites Netz nicht

[aholzhammer]

Hi,

ich habe einen LANCOM 1784VA "übernommen", und will darauf ein zweites Netz einrichten. Allerdings bekomme ich es nicht ins Internet geroutet.

Aktuell habe ich folgende NEtze:
192.168.1.254/24 als INTRANET, Routing Tag 0 -> funktioniert
192.168.65.254/24 als TEST, Routing Tag 0 -> funktioniert nicht. Weder als DMZ noch als Intranet. NAT ist aktiv.

Internet-Anschluss ist über einen LB realisiert, wobei die zweite Leitung nicht mehr aktiv ist. Ich habe auch schon versucht, die Default-Route nur über den aktiven Anschluss zu schalten. INTRANET funktioniert weiterhin, TEST weiterhin nicht.

Die aktuelle Firmware ist drauf, die Firewall ist nicht aktiv.

Interessanterweise ist nach einem Reboot ein Ping nach draussen möglich, danach nicht mehr.

Mir fehlt gerade so der Ansatzpunkt. Woran kann das liegen?

Danke
Andreas

[hyperjojo]

hallo,

poste mal deine IP-Netzwerke-Tabelle, Routingtabelle sowie Firewalltabelle. IPv6 ist nicht im Spiel?

Gruß hyperjojo

[aholzhammer]

Hi,

Firmware ist 10.32.0176RU9.

IP-Netzwerke:

netze.JPG

Routing Tabelle:

Routing.JPG

Firewall:

firewall.JPG

LAN1 ist an ETH2 und ETH3
LAN3 ist an ETH4
ETH2 und ETH4 gehen an denselben Switch, ETH3 an ein separates Gerät.

Clients im INTRANET können:
- ins Internet
- das Default GW 192.168.1.254 anpingen
- das Default-GW für TEST (192.168.65.254) anpingen
- keine Clients in TEST anpingen

Client in TEST können:
- NICHT ins Internet
- das Default-GW 192.168.65.254 anpingen
- das Default-GW für INTRANET (192.168.1.254) anpingen
- keine Clients in INTRANET anpingen

Erwartet wäre:
TEST und INTRANET können miteinander kommunizieren und ins Internet.
Der Zugriff zwischen beiden Netzen wird später eingeschränkt

Vielen Dank für jeden Hinweis!
Andreas

[Jirka]

Firewall:

Die Standard-Firewall-Regel WINS nicht da?
Die hier zu sehende Content-Filter-Regel ist nur Werbung und kann auch gelöscht werden, ist aber auch nicht aktiv, kann also auch bleiben, wie man möchte.

ETH2 und ETH4 gehen an denselben Switch

Managed oder unmanaged?

Viele Grüße,
Jirka

[aholzhammer]

Die Standard-Firewall-Regel WINS nicht da?
Die hier zu sehende Content-Filter-Regel ist nur Werbung und kann auch gelöscht werden, ist aber auch nicht aktiv, kann also auch bleiben, wie man möchte.

Nein, das ist die einzige Regel.

Managed oder unmanaged?

Managed, Spanning Tree ist aktiv auf dem Switch. Wenn der Port blockiert würde, wäre vermutlich auch das Gateway nicht ansprechbar.
Leider kann ich das nicht anders lösen, weil am anderen Ende der Client an einem unmanaged Switch hängt. VLAN ist also erstmal keine Option.

Ich habe:
LANCOM <-2x-> Managed Switch <-> Managed Switch <-> Unmanaged Switch <-2x-> Je ein Client INTRANET und TEST.

[Jirka]

Die Netze INTRANET und TEST sind dann also ohne DHCP-Server?

Und auf dem ersten managed Switch hinter dem LANCOM sind die Ports, in die die Kabel vom LANCOM kommen, also nicht isoliert?

Dann funktioniert das so nicht.

Weise TEST LAN-1 zu und entferne das Kabel von ETH-4 zum Switch. Damit könnte natürlich jeder Client ins jeweils andere LAN ausbrechen, aber das ist ja anscheinend so gewünscht (verschiedene Netze am unmanaged Switch).

Viele Grüße,
Jirka

[aholzhammer]

Die Netze INTRANET und TEST sind dann also ohne DHCP-Server?

Und auf dem ersten managed Switch hinter dem LANCOM sind die Ports, in die die Kabel vom LANCOM kommen, also nicht isoliert?

Dann funktioniert das so nicht.

Weise TEST LAN-1 zu und entferne das Kabel von ETH-4 zum Switch. Damit könnte natürlich jeder Client ins jeweils andere LAN ausbrechen, aber das ist ja anscheinend so gewünscht (verschiedene Netze am unmanaged Switch).

Viele Grüße,
Jirka

Super, vielen Dank! Das war die Lösung.

Hast du dazu noch etwas Hintergrund, wieso sich der Router so verhält? Nachdem das alles eine Broadcast-Domäne ist, müsste der Router die Clients ja auf LAN-1 und LAN-3 sehen. Sonst wären ja auch nicht beide Gateways anpingbar. Oder übersehe ich da was?

Das man ins andere LAN ausbrechen kann ist klar, in dem Fall aber nicht zu vermeiden.

Danke!
Andreas

[aholzhammer]

Leider nur die halbe Wahrheit. Ping-Pakete werden zwischen den Netzen geroutet, TDP oder UDP scheinbar nicht?

Ich habe einen Trace erstellt, da sieht man ganz klar für die ICMP-Pakete kommen antworten, für TCP (https) und UDP (snmp) nicht:

[IP-Router] 2020/07/14 17:18:59,390 Devicetime: 2020/07/14 17:19:00,330
IP-Router Rx (LAN-1, TEST, RtgTag: 0):
DstIP: 192.168.1.102, SrcIP: 192.168.65.22, Len: 1517, DSCP: CS0/BE (0x00), ECT: 0, CE: 0
Prot.: ICMP (1), echo request, id: 0x0001, seq: 0x0406
Route: LAN-1 Tx (INTRANET):

[IP-Router] 2020/07/14 17:18:59,390 Devicetime: 2020/07/14 17:19:00,332
IP-Router Rx (LAN-1, INTRANET, RtgTag: 0):
DstIP: 192.168.65.22, SrcIP: 192.168.1.102, Len: 1517, DSCP: CS0/BE (0x00), ECT: 0, CE: 0
Prot.: ICMP (1), echo reply, id: 0x0001, seq: 0x0406
Route: LAN-1 Tx (TEST):

-> ICMP hat funktioniert

[IP-Router] 2020/07/14 17:19:00,176 Devicetime: 2020/07/14 17:19:01,125
IP-Router Rx (LAN-1, TEST, RtgTag: 0):
DstIP: 192.168.1.102, SrcIP: 192.168.65.22, Len: 105, DSCP: CS0/BE (0x00), ECT: 0, CE: 0
Prot.: UDP (17), DstPort: 161, SrcPort: 51221
Route: LAN-1 Tx (INTRANET):


[IP-Router] 2020/07/14 17:19:10,972 Devicetime: 2020/07/14 17:19:11,916
IP-Router Rx (LAN-1, TEST, RtgTag: 0):
DstIP: 192.168.1.102, SrcIP: 192.168.65.22, Len: 105, DSCP: CS0/BE (0x00), ECT: 0, CE: 0
Prot.: UDP (17), DstPort: 161, SrcPort: 51221
Route: LAN-1 Tx (INTRANET):

[IP-Router] 2020/07/14 17:19:12,703 Devicetime: 2020/07/14 17:19:13,646
IP-Router Rx (LAN-1, TEST, RtgTag: 0):
DstIP: 192.168.1.102, SrcIP: 192.168.65.22, Len: 52, DSCP: CS0/BE (0x00), ECT: 0, CE: 0
Prot.: TCP (6), DstPort: 80, SrcPort: 49602, Flags: S
Seq: 3535348004, Ack: 0, Win: 65520, Len: 0
Option: Maximum segment size = 1260
Option: NOP
Option: Window scale = 8 (multiply by 256)
Option: NOP
Option: NOP
Option: SACK permitted
Route: LAN-1 Tx (INTRANET):

[IP-Router] 2020/07/14 17:19:12,979 Devicetime: 2020/07/14 17:19:13,911
IP-Router Rx (LAN-1, TEST, RtgTag: 0):
DstIP: 192.168.1.102, SrcIP: 192.168.65.22, Len: 52, DSCP: CS0/BE (0x00), ECT: 0, CE: 0
Prot.: TCP (6), DstPort: 80, SrcPort: 49605, Flags: S
Seq: 3949692067, Ack: 0, Win: 65520, Len: 0
Option: Maximum segment size = 1260
Option: NOP
Option: Window scale = 8 (multiply by 256)
Option: NOP
Option: NOP
Option: SACK permitted
Route: LAN-1 Tx (INTRANET):

Was macht das Gerät denn da Komisches? Ist da Proxy-ARP im Spiel, aber das müsste doch ICMP auch betreffen?

Danke
Andreas

[Jirka]

Was macht das Gerät denn da Komisches?

Nach diesem Trace hier zu urteilen, macht das Gerät zumindest das, was es soll, nämlich die Pakete zu routen.
Allerdings ist mit diesem Trace auch noch nicht eindeutig nachgewiesen, dass die Pakete korrekt den LANCOM verlassen, dazu bräuchte es noch den Ethernet-Trace als eindeutigen Beweis. Aber es ist anzunehmen, dass dem so ist.
Wenn Dein Endgerät auf die Pakete nicht reagiert, dann müsstest Du eher da mal nach der Ursache schauen. Was ist denn die 192.168.1.102 für ein Gerät?

Viele Grüße,
Jirka

[aholzhammer]

Hi,
die 192.168.1.102 ist ein Drucker. Der antwortet auch auf ICMP, d.h. das grundsätzliche Routing ist ok.

Wenn ich "Entfernte Stationen über Proxy-Arp einbinden" abschalte, dann ist der Drucker auch per HTTP und Pot 9100 erreichbar. Liegt also doch daran.

Aber: Dann funktioniert der Zugriff von den Homeoffice-VPNs nicht mehr Die bekommen eine IP aus dem 192.168.1.0/24 Netz und sind ohne Proxy ARP natürlich nicht erreichbar.

Also entweder/oder. Oder kann ich als VPN-Netz ein beliebiges Netz nehmen?

Danke
Andreas

[Jirka]

Wie sieht denn Deine (IPv4-)Routing-Tabelle aus?

[aholzhammer]

Routing-Tabelle ist wie im Beitrag 3. Die Firewall ist nicht aktiv.

Ich bin mir relativ sicher, dass das an der Proxy-Arp Einstellung und dem Setup in einem LAN hängt.

Aktuell ist das Setup so:
192.168.1.0/24 an LAN1
192.168.65.0/24 an LAN1
Mit "Entfernte Stationen über Proxy-Arp einbinden" funktioniert Ping, aber sonst kein Dienst. Ich vermute, dass der Lancom schon die ICMP Antwort schickt, sonst kann ich mir das nicht erklären.
Ohne "Entfernte Stationen über Proxy-Arp einbinden" funktioniert das Routing wie erwartet.
Frage 1: Was bezeichnet der Lancom als "Entfernte Stationen"? Das sollte für Geräte im LAN doch nicht ziehen?

Dann habe ich noch VPN-User, die Adressen aus 192.168.1.0/24 bekommen. Die haben nur Zugriff auf die internen Systeme in 192.168.1.0/24, wenn "Entfernte Stationen über Proxy-Arp einbinden" aktiv ist. Das ist auch logisch, weil die internen Geräte glauben, der Zugriff kommt aus dem LAN. Also muss der Lancom Proxy-Arp spielen.

Da habe ich also einen Konflikt. Ich könnte aber die VPNs in ein separates Netzwerk legen, das müsste doch gehen?

Danke
Andreas

[Jirka]

Routing-Tabelle ist wie im Beitrag 3.

Oh, sorry, hatte ich inzwischen schon wieder vergessen, dass die da oben angegeben wurde.
Ich hatte vermutet, dass evt. IP-Adressen aus dem lokalen LAN in der Routing-Tabelle aufgeführt sind, was man auch machen kann, wenn man VPN-Clients eine feste IP-Adresse zuweisen will. Aber das ist hier nicht der Fall.

Frage 1: Was bezeichnet der Lancom als "Entfernte Stationen"? Das sollte für Geräte im LAN doch nicht ziehen?

Korrekt. Entfernte Stationen sind Stationen, die eben nicht im lokalen LAN sind, sondern die z. B. über eine VPN-Client-Verbindung angebunden sind, für die der LANCOM sich aber so ausgibt als sei er das, da er das dann so weiter leiten kann an die Station. Wenn nach der IP-Adresse im lokalen LAN gefragt wird, sagt der LANCOM-Router also per ARP, dass er das ist. Das funktioniert soweit auch zuverlässig und ist ja nun auch kein neues Feature.

Das ist auch logisch, weil die internen Geräte glauben, der Zugriff kommt aus dem LAN. Also muss der Lancom Proxy-Arp spielen.

Genau.

Da habe ich also einen Konflikt.

Eher ein Problem. Weil normal müsste das doch funktionieren. Ich verstehe es jetzt gerade auch irgendwie nicht so ganz, wo es da hängt und warum. Ich wüsste nicht, warum es in dieser Konstellation, die zugegebenermaßen in der Praxis nicht so oft vorkommt, aber die ja wohl zulässig sein sollte, jetzt nicht funktioniert.

Du kannst natürlich für die VPN-Clients ein anderes Netz aufsetzen, klar, aber das sehe ich jetzt dann eher als Workaround als als Problemlösung.

Viele Grüße,
Jirka

[aholzhammer]

Du kannst natürlich für die VPN-Clients ein anderes Netz aufsetzen, klar, aber das sehe ich jetzt dann eher als Workaround als als Problemlösung.

Genau das habe ich versucht, und habe weiter seltsame Dinge. Ich habe nur einen neuen VPN-Pool angelegt. Der VPN-Verbindungsaufbau klappt, ich bekomme eine IP und kann einzelne interne Services per HTTPS erreichen. Ping an einen Server geht auch, nur RDP erst nach ca. 3 Minuten. Vorher ist der Port angeblich nicht erreichbar.

So langsam glaube ich, mit dem Gerät stimmt was nicht.

Andreas