Terminalserver aus tagged Lan nicht erreichbar

[checkdata]

Hallo Forum,
ich komme aus einem bestimmten Netz nicht auf einen Terminalserver beim Kunden.

Im Office haben wir einen Lancom, über den alle Verindungen zu unseren Kunden laufen und hier ist alles ok!
Lancom 1781AW > 10.10.20.1 = alles OK (Internet,VPN, RDP usw.)

Um eine bestimmte Konfiguration für einen Kunden zu testen habe ich eine Test-Umgebung geschaffen:

im Netz 10.10.20.0 steht ein zweiter Router Lancom 1711+ VPN = 10.10.20.254
an diesem hängt ein D-Link DGS 1224T switch auf welchem ich die VLAN's nach 802.1Q eingerichtet habe (VLAN-ID 2+3 Tagging auf Port 1 für Router)
Der Port 1 ist mit dem Lancom 1711 auf LAN1 verbunden.

Die Netze am Lancom 1711:
Intranet 10.10.20.254 VLAN-ID 0 TAG 0
CD-T2 10.10.2.1 255.255.255.0 10.10.2.1 VLAN-ID 2 TAG 2
CD-T3 10.10.3.1 255.255.255.0 10.10.3.1 VLAN-ID 3 TAG 3
Für beide CD-Netze ist DHCP eingerichtet und funktioniert.

VLAN Modul im 1711 ist OFF.

Die Netze CD-Tx haben Zugang zum Internet als auch zu den Server bzw. Druckern in Netz 10.10.20.0.
Dafür habe ich FW-Regeln erstellt, die via Routing Tag 65535 die Tags für die Netzte bzw. Dienste zum 10.10.20.x umleiten.

Vom Router 10.10.20.254 aus kann ich den Terminalserver bzw. auch die Drucker im Netz 10.0.50.0 beim Kunden anpingen.
D.h. dass die Route ins 10.0.50.x Netz dem 1711 bekannt ist, er steht ja auch mit einem Bein im Netz 10.10.20.0

Wenn ich jetzt aber z.B. aus dem Netz 10.10.2.x oder dem 10.10.3.x heraus eine RDP Verbindung aufbauen will, so zeigt mir der Trace "Network unreachable (No Route)"

Wie muss nun ein spezielles Routing bzw. eine FW Regel auf dem 1711 aussehen, damit der Zugriff via RDP auf den Terminalserver im Netz 10.0.50.x funktioniert?

Ich danke für eure Hilfe!!!

[backslash]

Hi checkdata,

Vom Router 10.10.20.254 aus kann ich den Terminalserver bzw. auch die Drucker im Netz 10.0.50.0 beim Kunden anpingen.
D.h. dass die Route ins 10.0.50.x Netz dem 1711 bekannt ist, er steht ja auch mit einem Bein im Netz 10.10.20.0

Wenn ich jetzt aber z.B. aus dem Netz 10.10.2.x oder dem 10.10.3.x heraus eine RDP Verbindung aufbauen will, so zeigt mir der Trace "Network unreachable (No Route)"

Wie muss nun ein spezielles Routing bzw. eine FW Regel auf dem 1711 aussehen, damit der Zugriff via RDP auf den Terminalserver im Netz 10.0.50.x funktioniert?

Ich danke für eure Hilfe!!!

solange du nur das 10.0.50.x-Netz erreichen willst, reicht es aus hier genau wie für den Drucker im 10.10.20.x-Netz eine passende Regel in der Firewall anzulegen:

Code: Alles auswählen

Name:        Allow-10-0-50-x
Routing-Tag: 65535
Aktion:      übertragen
Quelle:      Alle Stationen in den lokalen Netzen CD-T2 und CD-T3
Ziel:        Netzwerk 10.0.50.0 / 255.255.255.0
Dienste:     alle Dienste (oder auf RDP beschränkt)

Problematisch wird es nur, wenn die CD-T2 und CD-T3 auch ins Internet sollen, den dann müßtest du in der Regel als Ziel "alle Stationen" angeben und dann dürften die Netze auch ungefiltert in dein Intranet. In diesem Fall wäre es fast schon besser alle Netze ungetaggt zu betreiben und alles, was erlaubt oder verboten sein soll, explizit über Firewallregeln abzudecken

Gruß
Backslash

[checkdata]

Hallo backslash,
vielen Dank für deine Antwort.

Die FW-Regel habe ich - nach dem was ich von dir gelernt hatte - ganau so auf dem 1711 angelegt.

Jedoch keine Verbindung.

Ich habe dann noch explizit eine Route auf dem 1711 > 10.0.50.0 255.255.255.0 10.10.20.1
zu gefügt.
Bei einem Client >tracert 10.0.50.x auf den Terminalserver komme ich über die 10.10.2.1 zur 10.10.20.1 und Schluss.

Ich habe beim tracen im 1781 festgestellt, dass die Route für den anfragenden Client z.B 10.10.2.106 auch im 10.10.20.1 Router mit Port 3389 erscheint.

Router Trace auf 10.10.20.1 (LC 1781aw)
DstIP: 10.0.50.22, SrcIP: 10.10.2.106, Len: 52, DSCP/TOS: 0x00
Prot.: TCP (6), DstPort: 3389, SrcPort: 49345, Flags: S
Seq: 3546384632, Ack: 0, Win: 8192, Len: 0
Option: Maximum segment size = 1460
Option: NOP
Option: Window scale = 8 (multiply by 256)
Option: NOP
Option: NOP
Option: SACK permitted
Route: WAN Tx (xxxx)

Es kommt aber keine Session zu stande.

Ich danke dir.

PS: Der Vollständigkeit halber habe ich die FW-Regeln vom 1711 als Image angehängt.

[backslash]

Hi Checkdata,

Router Trace auf 10.10.20.1 (LC 1781aw)
DstIP: 10.0.50.22, SrcIP: 10.10.2.106, Len: 52, DSCP/TOS: 0x00
Prot.: TCP (6), DstPort: 3389, SrcPort: 49345, Flags: S
Seq: 3546384632, Ack: 0, Win: 8192, Len: 0
Option: Maximum segment size = 1460
Option: NOP
Option: Window scale = 8 (multiply by 256)
Option: NOP
Option: NOP
Option: SACK permitted
Route: WAN Tx (xxxx)

das zeigt doch schonmal, daß die Firewall-Regeln im 1711 passen, denn sonst würde das Paket nicht ins WAN geroutet.
Da es raus geht und offenbar keine Antwort kommt, geht das Paket auf der weiteren Strecke verloren. Ich vermute mal "xxxx" ist eine VPN-Strecke. Für die mußt du natürlich passende VPN-Regeln erstellen, sonst blockt sie die Pakete ab. Das kannst du mit einem VPN-Packet-Trace prüfen...

Damit das VPN die Pakete nicht blockt müßtest du im 1781AW folgende VPN-Regel in der Firewall erstellen:

Code: Alles auswählen

Name:     ALLOW-CD-T1-CD-T2

[ ] diese Regel ist für die Firewall aktiv
[x] diese Regel wird zur Erzeugung von VPN-Regeln herangezogen

Quelle:  IP-Netzwerke 10.10.2.1/255.255.255.0, 10.10.3.1 255.255.255.0
Ziel:    Gegenstelle xxxx
Dienste: alle Dienste

und natürlich müssen auf der Gegenseite auch passende Routen für die Nete 10.10.2.x und 10.10.3.x existieren - und die jeweiligen Rechner müssen Verbindungen aus fremden Netzen annehmen.

Gruß
Backslash

[checkdata]

Hallo backslash,
ich bekomme noch keine Verbindung zum Terminalserver auf der Gegenseite, da mir in diesem Zuammenhang noch ein anderer Fehler aufgefallen ist.

Normalerweise habe ich eine stabile und fehlerfreie Verbindung zur Gegenstelle beim Kunden.

[VPN-Status] 2015/03/20 10:51:23,538 Devicetime: 2015/03/20 10:51:54,268
IKE info: Phase-2 [responder] done with 2 SAS for peer LC3 rule ipsec-3-LC3-pr0-l0-r0
IKE info: rule:' ipsec 10.10.20.0/255.255.255.0 <-> 10.0.1.0/255.255.255.0 '
IKE info: SA ESP [0x6166ef0f] alg AES keylength 256 +hmac HMAC_SHA outgoing
IKE info: SA ESP [0x6c4cdad9] alg AES keylength 256 +hmac HMAC_SHA incoming
IKE info: life soft( 25920 sec/1800000 kb) hard (28800 sec/2000000 kb)
IKE info: tunnel between src: MEINE dst: KUNDE

Hier zeigt der Trace auch keine weiteren Meldungen.

Es kommt aber immer mal wieder zur Verbindung mit Fehler bzw. werden bei der folgenden Konstellation mal Fehler im Monitor angezeigt, mal nicht.
MEINE
[VPN-Status] 2015/03/20 11:41:47,618 Devicetime: 2015/03/20 11:42:18,400
IKE info: Phase-2 failed for peer LC3: no rule matches the phase-2 ids 0.0.0.0/0.0.0.0 <-> 10.10.20.0/255.255.255.0
IKE log: 114218.400939 Default message_negotiate_sa: no compatible proposal found
IKE log: 114218.401015 Default dropped message from KUNDE port 500 due to notification type NO_PROPOSAL_CHOSEN

KUNDE
[VPN-Status] 2015/03/20 12:35:03,376 Devicetime: 2015/03/20 12:35:32,955
IKE info: Phase-2 [responder] done with 2 SAS for peer CD-LC4 rule ipsec-2-CD-LC4-pr0-l0-r0
IKE info: rule:' ipsec 10.0.0.0/255.0.0.0 <-> 10.10.20.0/255.255.255.0 '
IKE info: SA ESP [0x9a2f6f6f] alg AES keylength 256 +hmac HMAC_SHA outgoing
IKE info: SA ESP [0xfb806699] alg AES keylength 256 +hmac HMAC_SHA incoming
IKE info: life soft( 25920 sec/1800000 kb) hard (28800 sec/2000000 kb)
IKE info: tunnel between src: KUNDE dst: MEINE

Bei dieser Konstellation werden aber weiterhin "policy manager error" bzw." Error: IPSEC-R-No-rule-matched-IDs (0x3201)" im Trace angezeigt - der Monitor zeigt aber z.Z. keine Fehler für diese VPN Verbingen - auf beiden Seiten!

Ich gehe nun davon aus, das ich mir eine Redundanz auf dem LC3 beim Kunden geschaffen habe -
wahrscheinlich im Routing --- hmm, oder doch FW?

Ich suche nun meinen Denkfehler:
Der LC3 beim Kunden regelt zum Einen das dortige Netz (welches ich umstellen will) und es laufen alle Verbindung von anderen Niederlassungen über diesen Router. Zudem stellt er eine wichtige VPN Verbind zu einem DB Anbieter, den alle Nutzen.
Kunden Netz: 10.0.x.x

FW LC3:
VPN-Regel > VPN-LC3-LC4 beliebig 10.10.20.0 / 255.255.255.0 (ich muss in alle Netze)
VPN-Regel > DD-LC4 192.168.x.0/255.255.255.0 10.10.20.0 / 255.255.255.0
VPN-Regel > LC4-DD 10.10.20.0/255.255.255.0 192.168.x.0/255.255.255.0

FW LC4:
VPN-Regel > VPN-LC4-LC3 Beliebig 10.0.1.0 / 255.255.255.0
- und für die Testerei
VPN-Regel > ip-Netzwerke CD-T2+T3 > Gegenstelle LC3

Das jeweilige Routing habe ich ls Image angehängt.

Ich hoffe du hast alle nötigen Infos, um mir hier einen Tip zu geben!?

Ich danke für Deine Unterstützung

[backslash]

Hi checkdata

Es kommt aber immer mal wieder zur Verbindung mit Fehler bzw. werden bei der folgenden Konstellation mal Fehler im Monitor angezeigt, mal nicht.
MEINE
[VPN-Status] 2015/03/20 11:41:47,618 Devicetime: 2015/03/20 11:42:18,400
IKE info: Phase-2 failed for peer LC3: no rule matches the phase-2 ids 0.0.0.0/0.0.0.0 <-> 10.10.20.0/255.255.255.0
IKE log: 114218.400939 Default message_negotiate_sa: no compatible proposal found
IKE log: 114218.401015 Default dropped message from KUNDE port 500 due to notification type NO_PROPOSAL_CHOSEN

Da stimmen die VPN-Netzbeziehungen nicht. Hier fordert die Gegenseite daß die Default-Route auf dem VPN-Tunnel liegen soll.

Schuld ist vermutlich diese Regel für die es kein Gegenstück auf der anderen Seite gibt:

FW LC3:
VPN-Regel > VPN-LC3-LC4 beliebig 10.10.20.0 / 255.255.255.0 (ich muss in alle Netze)

Hier mußt du im Gerät, das im 10.10.20.0-Netz steht (also im Router MEINE), eine Default-Route auf den VPN-Tunnel binden. Bist du sicher, daß du das willst?
Denk lieber nochmal etwas über die Netze nach und wer welche erreichen soll

Gruß
Backslash

[checkdata]

Hi Backslash,
ich will mich hier nochmals Bedanken für die wertvolle Arbeit die Du im Forum leistest!!!

Also:
Ich habe die Regel vom LC3:
VPN-Regel > VPN-LC3-LC4 beliebig 10.10.20.0 / 255.255.255.0 (ich muss in alle Netze)
geändert auf:
VPN-Regel > VPN-LC3-LC4 beliebig CD-LC4 (ich muss in alle Netze vom und hinter dem LC3)

Den LC4:
VPN-Regel > VPN-LC4-LC3 beliebig LC3 (ich muss in alle Netze des Kunden)
Und z.Z. treten keine Fehler auf.

Ich kontrolliere alle Netze des Kunden und muss von daher überall hin.
Natürlich soll der Rückgriff in mein 10.10.20.x Netz nicht ohne weiteres möglich sein.

Der LC3 bildet das Bindeglied zwischen allen Netzen.

Du schreibst:
"Denk lieber nochmal etwas über die Netze nach und wer welche erreichen soll"

Welches Problem habe ich übersehen?

Gruß
checkdata

[backslash]

Hi checkdata

ich will mich hier nochmals Bedanken für die wertvolle Arbeit die Du im Forum leistest!!!

nehme ich gerne an...

Und z.Z. treten keine Fehler auf.

d.h. es läuft jetzt alles, wie es soll?

Du schreibst:
"Denk lieber nochmal etwas über die Netze nach und wer welche erreichen soll"

damit bezog ich mich darauf, daß du bei dem damaligen VPN-Regelwerk auch irgendwo eine Default-Route in den Tunnel hättest setzen müssen - sowas wird zwar gerne bei VPN-Clients gemacht, damit für den Road-Warrior ein Internetzugriff nicht möglich ist, solange der Tunnel besteht (und somit eine böse Website keine Daten aus dem Firmennetz abgreifen kann), sollte aber in LAN-LAN-Koppluingen eher nicht auftauchen...

Gruß
Backslash

[checkdata]

Hi Backslash,
... nein leider nicht sauber.

Ich habe mir nochmals alle LAN-LAN Kopplungen vorgenommen und gem. der Lancom Doku
LANCOM Support Knowledgebase Dokument-Nr. 1007.2811.4511.RHOO überprüft bzw. geändert.

trotzdem bekomme ich nach einiger Zeit wieder Fehler:
Die Zentrale ist der LC3 - über diesen habe ich z.B. eine Kopplung LC4 - LC3 - LC1.

Am LC4 bekomme ich dann nach einiger Zeit den Fehler:
Kein übereinstimmendes Proposal gefunden (Aktiver Verbindungsaufbau, IPSec) [0x3102]

Am LC3 den Fehler:
Keine Regel für ID's gefunden - unbekannte Verbindung oder fehlerhafte ID (z.B. IP-Netzwerkdefinition) (Passiver Verbindungsaufbau, IPSec) [0x3201]

Am LC1:
Kein übereinstimmendes Proposal gefunden (Aktiver Verbindungsaufbau, IKE) [0x2103]

Dazu kommt für mich die Frage:
über den LC4 kontrolliere ich die Netzwerke bzw. über den Lancom Monitor sehe ich die Router.
Irgendwann aber verliere ich den Kontakt zum LC1 und muss mir diesen erst wieder durch eine separate VPN Verbindung holen.
Nach Beendigung der VPN-Verbindung bleibt der Connect über den LC3 dann bestehen.
Was läuft hier falsch?

Wo ich hier gerade am schreiben bin drängt sich mir noch die offene Frage auf:
In dem Dok "LANCOM Support Knowledgebase Dokument-Nr. 1007.2811.4511.RHOO"
beschreibt ihr ja eine LAN-LAN-LAN Kopplung.

Warum wird aber dort in der Zentrale eine eine FW-Regel auf Basis der Netze und nicht der (VPN)Verbindungen gemacht?

Ich danke Dir für Deine Antworten.