Routing Problem

[Pauli]

Hi Backslash,

umgesetzt wie beschrieben bekomme ich nun wieder die Verbindung hin:

Code: Alles auswählen

[Firewall] 2020/04/14 16:42:39,648  Devicetime: 2020/04/14 16:42:39,571
Packet matched rule TAG-202-UTM_VLAN-INTRA_VLAN-VOIP
DstIP: 172.16.2.241, SrcIP: 192.168.168.100, Len: 92, DSCP: CS0/BE (0x00), ECT: 0, CE: 0
Prot.: ICMP (1), echo request, id: 0x0001, seq: 0x0043

send syslog message
send SNMP trap
packet accepted

[IP-Router] 2020/04/14 16:42:39,648  Devicetime: 2020/04/14 16:42:39,571
IP-Router Rx (LAN-1, INTRANET, RtgTag: 202): 
DstIP: 172.16.2.241, SrcIP: 192.168.168.100, Len: 92, DSCP: CS0/BE (0x00), ECT: 0, CE: 0
Prot.: ICMP (1), echo request, id: 0x0001, seq: 0x0043
Time exceeded => Discard

[IP-Router] 2020/04/14 16:42:40,667  Devicetime: 2020/04/14 16:42:40,589
IP-Router Rx (LAN-1, INTRANET, RtgTag: 202): 
DstIP: 172.16.2.241, SrcIP: 192.168.168.100, Len: 40, DSCP: CS0/BE (0x00), ECT: 0, CE: 0
Prot.: TCP (6), DstPort: 80, SrcPort: 61305, Flags: A
Seq: 1402488462, Ack: 1349486596, Win: 16425, Len: 0
Redirect to 192.168.168.249, LAN-1 Tx (INTRANET)): 
Route: 192.168.168.249, LAN-1 Tx (INTRANET): 

Wenn ich Dich richtig verstehe, sollte mit dem kommenden Update auch der IP-Router Stepp mit 'Time exceeded => Discard' verschwinden und direkt der Redirect im Intranet an die 192.168.168.249 gehen.

Ich melde das Ergebnis wenn ich mit der 0186 getestet habe.

Vielen vielen Dank, für die Bemühungen obwohl der Support mich schon entmutigt hatte.

Gruß, Pauli

PS: Noch viel schöner wäre natürlich in internes NATting bzw. Masquerading, dann würde das Redirect zu einem anderen System entfallen.

[backslash]

Hi Pauli

Du redest von der Firewall-Regel, dort habe ich als Ziel 'Alle Stationen im lokalen Netzwerk' und Netzwerk-Name 'IOT' angegeben. Soll ich jetzt ein Ziel Objekt 'Ein ganzes IP-Netzwerk mit 172.16.2.0. und 255.255.255.0 nehmen?

ja... und wenn es mehr als nur das VOICE-Netz sein soll, dann mußt du alle Netze dort abrollen.

Der Punkt ist, daß die explizite Angabe des Netzes in der Zielspalte eine zusätzliche Bedingung für das Matchen der Regel ist. Aber dadurch, daß du einen Next-Hop verwendest, der sich nicht in dem Zielnetz befindet, trifft die Bedingung nicht mehr zu...

In der Routing Tabelle lasse ich meinen Eintrag wie er war:

Löschen 172.16.2.0 255.255.255.0 201 0 192.168.168.249@0 0 nein ja

ja

Gruß
Backslash

[Pauli]

Hi,

in der neuen Version 186 habe ich nun mal einen Trace ausgeführt.

Bei ICMP (Ping) sieht es so aus:

Code: Alles auswählen

[Firewall] 2020/04/16 19:07:28,931  Devicetime: 2020/04/16 19:07:28,883
Packet matched rule TAG-202-UTM_VLAN-INTRA_VLAN-VOIP
DstIP: 172.16.2.241, SrcIP: 192.168.168.100, Len: 92, DSCP: CS0/BE (0x00), ECT: 0, CE: 0
Prot.: ICMP (1), echo request, id: 0x0001, seq: 0x0073

send syslog message
send SNMP trap
packet accepted

[IP-Router] 2020/04/16 19:07:28,931  Devicetime: 2020/04/16 19:07:28,883
IP-Router Rx (LAN-1, INTRANET, RtgTag: 202): 
DstIP: 172.16.2.241, SrcIP: 192.168.168.100, Len: 92, DSCP: CS0/BE (0x00), ECT: 0, CE: 0
Prot.: ICMP (1), echo request, id: 0x0001, seq: 0x0073
Time exceeded => Discard

[IP-Router] 2020/04/16 19:07:28,931  Devicetime: 2020/04/16 19:07:28,884
IP-Router Rx (LAN-1, INTRANET, RtgTag: 202): 
DstIP: 172.16.2.241, SrcIP: 192.168.168.100, Len: 92, DSCP: CS0/BE (0x00), ECT: 0, CE: 0
Prot.: ICMP (1), echo request, id: 0x0001, seq: 0x0074
Time exceeded => Discard

[IP-Router] 2020/04/16 19:07:28,931  Devicetime: 2020/04/16 19:07:28,885
IP-Router Rx (LAN-1, INTRANET, RtgTag: 202): 
DstIP: 172.16.2.241, SrcIP: 192.168.168.100, Len: 92, DSCP: CS0/BE (0x00), ECT: 0, CE: 0
Prot.: ICMP (1), echo request, id: 0x0001, seq: 0x0075
Time exceeded => Discard

[IP-Router] 2020/04/16 19:07:29,939  Devicetime: 2020/04/16 19:07:29,892
IP-Router Rx (LAN-1, INTRANET, RtgTag: 202): 
DstIP: 172.16.2.241, SrcIP: 192.168.168.100, Len: 92, DSCP: CS0/BE (0x00), ECT: 0, CE: 0
Prot.: ICMP (1), echo request, id: 0x0001, seq: 0x0076
Redirect to 192.168.168.249, LAN-1 Tx (INTRANET)): 
Route: 192.168.168.249, LAN-1 Tx (INTRANET): 

Bei HTML aufrufen so:

Code: Alles auswählen

[Firewall] 2020/04/16 19:06:02,873  Devicetime: 2020/04/16 19:06:02,775
Packet matched rule TAG-202-UTM_VLAN-INTRA_VLAN-VOIP
DstIP: 172.16.2.241, SrcIP: 192.168.168.100, Len: 52, DSCP: CS0/BE (0x00), ECT: 0, CE: 0
Prot.: TCP (6), DstPort: 80, SrcPort: 51069, Flags: S
Seq: 2615672070, Ack: 0, Win: 64240, Len: 0
Option: Maximum segment size = 1460
Option: NOP
Option: Window scale = 4 (multiply  by 16)
Option: NOP
Option: NOP
Option: SACK permitted

send syslog message
send SNMP trap
packet accepted

[IP-Router] 2020/04/16 19:06:02,873  Devicetime: 2020/04/16 19:06:02,775
IP-Router Rx (LAN-1, INTRANET, RtgTag: 202): 
DstIP: 172.16.2.241, SrcIP: 192.168.168.100, Len: 52, DSCP: CS0/BE (0x00), ECT: 0, CE: 0
Prot.: TCP (6), DstPort: 80, SrcPort: 51069, Flags: S
Seq: 2615672070, Ack: 0, Win: 64240, Len: 0
Option: Maximum segment size = 1460
Option: NOP
Option: Window scale = 4 (multiply  by 16)
Option: NOP
Option: NOP
Option: SACK permitted
Redirect to 192.168.168.249, LAN-1 Tx (INTRANET)): 
Route: 192.168.168.249, LAN-1 Tx (INTRANET): 

Irgendwie passt das doch noch nicht so ganz oder? Zumal beim Ping der Tracert so aussieht:

Code: Alles auswählen

  1    <1 ms    <1 ms    <1 ms  smcbs01r.smcbs.local [192.168.168.250]
  2    <1 ms     1 ms    <1 ms  fritz.voip.smcbs.local [172.16.2.241]

ich würde dazwischen den Step zum Redirect erwarten?

Danke, Pauli

[backslash]

Hi Pauli,

wo ist dein Problem?
Bei den ersten der pings des Traceroute ist das LANCOM der Hop, der TTL-Exceeced meldet und das Paket somit nicht weiter routet und somit keinen Redirect schickt.
Erst mit dem vierten ping setzt das Traceroute die TTL hoch und das LANCOM muß routen und sendet somit korrekterweise auch das Redirekt.

Gruß
Backslsash

[Pauli]

Ok + Danke für die Erklärung. Die Geschichte mit dem TTL hat ich nicht so auf dem Schirm. Also passt so alles?

Ich hatte nur früher einen tracert bekommen, der so aussah und ich hätte erwartet beim ersten Aufruf sehe ich auch wieder sowetwas:

1 <1 ms <1 ms <1 ms smcbs01r.smcbs.local [192.168.168.250]
2 <1 ms 1 ms <1 ms gateway.smcbs.local [192.168.168.249]
3 <1 ms 1 ms <1 ms fritz.voip.smcbs.local [172.16.2.241]

Danach müsste der Client ja ein Redircet bekommen und direkt den richtigen Router fragen. Das passt auch wenn ich mehrer Tracert's hintereinander absetzte:

1 <1 ms 1 ms 1 ms gateway.smcbs.local [192.168.168.249]
2 <1 ms <1 ms <1 ms fritz.voip.smcbs.local [172.16.2.241]

Aber beim ersten versuch, müsste der Lancom doch die Pakete an den anderen Router weiterleiten und das müsste man doch auch sehen oder liege ich falsch?1

Danke, Pauli

[backslash]

Hi Pauli

Aber beim ersten versuch, müsste der Lancom doch die Pakete an den anderen Router weiterleiten und das müsste man doch auch sehen oder liege ich falsch?1

da liegst du falsch. Jeder Router auf ein Paket halt nur eine Fehlermeldung schicken - und das ist hier nunmal das "TTL exceeded". Erst wenn das Paket wirklich geroutet wird, kann auch das Redirekt kommen. Das macht JEDER Router so

Gruß
Backslash

[Pauli]

OK, also beim ersten Versuch routet der Lancom noch direkt und danach wird über den zweiten Router redirected?

Daher sieht der erste tracert auch nur die beiden Stepps oder?

Nur damit ich richtig verstehe und nicht blöd sterbe.

Vielen Dank für Deine Mühe, Pauli

[backslash]

Hi Pauli,

OK, also beim ersten Versuch routet der Lancom noch direkt und danach wird über den zweiten Router redirected?

da ist jetzt wieder die Frage, was du den erstem Versuch meinst....

Das Traceroute sendet pro TTL-Stufe immer 3 pings.

In der ersten Stufe routet das LANCOM *GAR NICHT*, weil die TTL ausläuft und beantwortet alle drei Pings daher mit "TTL exceeded".

Beim ersten Ping der zweiten Stufe schickt das LANCOM ein Redirect *UND* leitet das Paket weiter

Was dann passiert, hängt von der Implementierung des Traceroute ab. Wenn das Traceroute sich das "urspüngliche" Gateway (LANCOM) gemerkt hat, dann gehen auch alle nachfolgenden Pakete über das LANCOM und das LANCOM sendet für sie alle ein Redirect und leitet sie alle weiter. Wenn das Traceroute die Pakete einzeln über den internen Router seines Hosts schickt, dann schickt es bereits das zweite Ping der zweiten Stufe direkt zum richtigen Router - muß dabei dann aber die TTL wieder herabsetzen, wei sonst die Ausgabe eigentlich nicht stimmt - spätestens beim dritten angezeigten Hop.

Ein *NEUES* Traceroute sollte dann die geänderte Route kennen und das erste Paket der ersten Stufe direkt an den richtigen Router senden.

Gruß
Backslash

[Pauli]

Hi Pauli,

OK, also beim ersten Versuch routet der Lancom noch direkt und danach wird über den zweiten Router redirected?

da ist jetzt wieder die Frage, was du den erstem Versuch meinst....

Beim ersten Versuch meine ich diesen Lancom Trace:

Code: Alles auswählen

[IP-Router] 2020/04/17 17:08:04,485  Devicetime: 2020/04/17 17:08:04,364
IP-Router Rx (LAN-1, INTRANET, RtgTag: 202): 
DstIP: 172.16.2.241, SrcIP: 192.168.168.100, Len: 92, DSCP: CS0/BE (0x00), ECT: 0, CE: 0
Prot.: ICMP (1), echo request, id: 0x0001, seq: 0x0097
Time exceeded => Discard

[IP-Router] 2020/04/17 17:08:04,485  Devicetime: 2020/04/17 17:08:04,366
IP-Router Rx (LAN-1, INTRANET, RtgTag: 202): 
DstIP: 172.16.2.241, SrcIP: 192.168.168.100, Len: 92, DSCP: CS0/BE (0x00), ECT: 0, CE: 0
Prot.: ICMP (1), echo request, id: 0x0001, seq: 0x0098
Time exceeded => Discard

[IP-Router] 2020/04/17 17:08:04,485  Devicetime: 2020/04/17 17:08:04,367
IP-Router Rx (LAN-1, INTRANET, RtgTag: 202): 
DstIP: 172.16.2.241, SrcIP: 192.168.168.100, Len: 92, DSCP: CS0/BE (0x00), ECT: 0, CE: 0
Prot.: ICMP (1), echo request, id: 0x0001, seq: 0x0099
Time exceeded => Discard

[IP-Router] 2020/04/17 17:08:05,490  Devicetime: 2020/04/17 17:08:05,373
IP-Router Rx (LAN-1, INTRANET, RtgTag: 202): 
DstIP: 172.16.2.241, SrcIP: 192.168.168.100, Len: 92, DSCP: CS0/BE (0x00), ECT: 0, CE: 0
Prot.: ICMP (1), echo request, id: 0x0001, seq: 0x009a
Redirect to 192.168.168.249, LAN-1 Tx (INTRANET)): 
Route: 192.168.168.249, LAN-1 Tx (INTRANET): 

und diesen dazugehörigen tracert unter Windows:

1 <1 ms <1 ms <1 ms smcbs01r.smcbs.local [192.168.168.250]
2 1 ms 1 ms 1 ms fritz.voip.smcbs.local [172.16.2.241]

hier hätte ich eben eine Zeile dazwischen erwartet die auf das Gateway mit der 249 geht?

Mache ich unter Windows mehrer tracerts schnell hintereinander bekomme ich dies, was ja zu Deiner letzten Aussage passt (sobald ich aber ein paar Sekunden warte bekomme ich wieder dieAusgabe oben):

1 <1 ms <1 ms <1 ms gateway.smcbs.local [192.168.168.249]
2 1 ms <1 ms <1 ms fritz.voip.smcbs.local [172.16.2.241]

Vielen Dank für Deine Hilfe und die Infos damit ich verstehe was hier abgeht.
Pauli

[backslash]

Hi Pauli,

und diesen dazugehörigen tracert unter Windows:

1 <1 ms <1 ms <1 ms smcbs01r.smcbs.local [192.168.168.250]
2 1 ms 1 ms 1 ms fritz.voip.smcbs.local [172.16.2.241]

hier hätte ich eben eine Zeile dazwischen erwartet die auf das Gateway mit der 249 geht?

das wirst du nicht sehen, weil nach dem Gateway mit der .249 nach dem Redirect *KEINEN* Hop entfernt ist (also direkt der erste Hop nach deinem PC ist) und somit auch kein TTL exceeded schickt. Denn die TTL wird vom Traceroute ist in dem Moment schon 2 und das Paket geht einen Hop weiter.

OK genaugenommen müßte Traceroute für das erste Paket der zweiten Runde tetsächlich die .249 ausgeben, für das zweite und dritte aber kommt das TTL-Exceeded von der 2.241.
Da im tracert aber nur eine Adresse pro Hop ausgegeben wird, gibt Microsoft hier offenbar die häufigste Adresse aus - ist halt so.


Gruß
Backslash

[Pauli]

OK+ Danke, dann glaube ich es verstanden zu haben und somit ist mein Problem gelöst und der Redirect funktioniert nun auch in der 10.40 wieder. Wesentlich war die FW Regel nicht an das Lancom Netz, sondern das Subnetz zu binden.

Gruß, Pauli