Hallo Allerseits,
Folgendes Problem: Anbindung einer Aussenstelle ueber 2 Lancom 1711 mit VPN (beidseitig eingerichtet mit Assistenten)
VPN funktioniert soweit, ping, Terminal-Zugriff auf AS400, Drucken v. AS400 zurück nach lokalem Drucker tut.
Ein Zeiterfassungsterminal hat ein Problem: SW meldet es als offline, ein Telnet auf das Terminal bleibt nach cca 1/2 Bildschirm haengen.
Trace meldet ein Fragmentierungsproblem: Paket muss -darf aber wg. "DF"-Flag nicht - fragmentiert werden.
im Router steht (bai QOS) die Fragmentierung auf "reassemblieren"
Kann mir jemand einen Tip geben ? Vielen Dank
Bestimmte Verbindungen d. VPN gehen nicht (Fragmentierung?)
Moderator: Lancom-Systems Moderatoren
-
therministrator
- Beiträge: 30
- Registriert: 28 Jun 2007, 08:55
Hi therministrator
was ist den das für ein System, das auf einen "ICMP fragmentation needed, but DF bit set" nicht mit Reduktion der Paketgröße reagiert... (der betreffende RFC schreibt vor, daß man das DF bit nur dann setzen darf, wenn man auch auf die ICMP-Meldung reagieren kann)
Du kannst u.U. manuell die MTU für die VPN-Verbindung passend herabsetzen (Kommuniktion -> Protokolle -> MTU-Liste). Dann erzwingt das LANCOM bei TCP-Verindungen direkt beim Verbindungsaufbau kleinere Pakete, so daß es ger nicht erst zum "ICMP fragmentation needed" kommt.
Gruß
Backslash
was ist den das für ein System, das auf einen "ICMP fragmentation needed, but DF bit set" nicht mit Reduktion der Paketgröße reagiert... (der betreffende RFC schreibt vor, daß man das DF bit nur dann setzen darf, wenn man auch auf die ICMP-Meldung reagieren kann)
Du kannst u.U. manuell die MTU für die VPN-Verbindung passend herabsetzen (Kommuniktion -> Protokolle -> MTU-Liste). Dann erzwingt das LANCOM bei TCP-Verindungen direkt beim Verbindungsaufbau kleinere Pakete, so daß es ger nicht erst zum "ICMP fragmentation needed" kommt.
Gruß
Backslash
-
therministrator
- Beiträge: 30
- Registriert: 28 Jun 2007, 08:55
Hallo und danke f. die schnelle Antwort
Es ist ein Zeiterfassungsterminal, wahrscheinlich irgendwann als serielles Terminal entwickelt, jetzt ueber einen embedded Seriellen/ethernet-Adapter (Lantronix) angesprochen. Sehr wahrscheinlich, dass man sich da nicht um irgendwlche RFCs gekuemmert hat (ich kenne das von unseren Elektrotechnikern mit ihren Microcontrollern
)
Dafür spricht auch, dass das Gerät - selbst aus dem Lan !!!! - auf Pings mit Paketgroessen groesser als cca 1475 gar nicht antwortet.
Die MTU der VPN-Verbindung zu verkleinern habe ich versucht, leider ohne Erfolg. (Eigentlich logisch oder ? weil ich ja damit die Grenze ab der fragmentiert wird noch heruntersetze )
Ich habe inzwischen (zum "Glueck" ist derjenige der das installiert hat kein Security-Fan ) in das Terminal reinschauen koennen und habe gesehen dass ich auf dem Gerät die MTU setzen kann. Wenn ich die MTU auf dem Geraet irgendwo auf 1200 - 1300 setze muesste ja noch "platz" bleiben f. den ganzen Overhead und die Pakete gehen dann (hoffentlich) unfragmentiert durch, oder ????
Es ist ein Zeiterfassungsterminal, wahrscheinlich irgendwann als serielles Terminal entwickelt, jetzt ueber einen embedded Seriellen/ethernet-Adapter (Lantronix) angesprochen. Sehr wahrscheinlich, dass man sich da nicht um irgendwlche RFCs gekuemmert hat (ich kenne das von unseren Elektrotechnikern mit ihren Microcontrollern
)Dafür spricht auch, dass das Gerät - selbst aus dem Lan !!!! - auf Pings mit Paketgroessen groesser als cca 1475 gar nicht antwortet.
Die MTU der VPN-Verbindung zu verkleinern habe ich versucht, leider ohne Erfolg. (Eigentlich logisch oder ? weil ich ja damit die Grenze ab der fragmentiert wird noch heruntersetze )
Ich habe inzwischen (zum "Glueck" ist derjenige der das installiert hat kein Security-Fan
) in das Terminal reinschauen koennen und habe gesehen dass ich auf dem Gerät die MTU setzen kann. Wenn ich die MTU auf dem Geraet irgendwo auf 1200 - 1300 setze muesste ja noch "platz" bleiben f. den ganzen Overhead und die Pakete gehen dann (hoffentlich) unfragmentiert durch, oder ????Hi therministrator
Aber wenn das Teil schon den den RFC zur PMTU-Discovery nicht berücksichtigt, wieso sollte es TCP korrekt implementiert haben...
Das LANCOM selbst zieht beim VPN immer 100 Bytes von der MTU der zugrunde liegenden Internetverbindung ab (das ergibt i.A. dann eine MTU von 1400 bzw. 1392...)
Gruß
Backslash
wenn das Gerät nicht reassemblieren kann ist bei 1472 Schluß...Dafür spricht auch, dass das Gerät - selbst aus dem Lan !!!! - auf Pings mit Paketgroessen groesser als cca 1475 gar nicht antwortet.
erstaunlich...Die MTU der VPN-Verbindung zu verkleinern habe ich versucht, leider ohne Erfolg.
nicht unbedingt. das direkte herabsetzen der MTU führt dazu, daß das LANCOM beim TCP-Verbindungsaufbau in die SYN- und SYN/ACK-Pakete die MSS-Option anpaßt, bzw. eine passende einfügt. Dann darf keiner der Beteiligten größere Pakete schicken...(Eigentlich logisch oder ? weil ich ja damit die Grenze ab der fragmentiert wird noch heruntersetze )
Aber wenn das Teil schon den den RFC zur PMTU-Discovery nicht berücksichtigt, wieso sollte es TCP korrekt implementiert haben...
das sollte ausreichen - solange das Teil sich daran hält...Ich habe inzwischen (zum "Glueck" ist derjenige der das installiert hat kein Security-Fan ) in das Terminal reinschauen koennen und habe gesehen dass ich auf dem Gerät die MTU setzen kann. Wenn ich die MTU auf dem Geraet irgendwo auf 1200 - 1300 setze muesste ja noch "platz" bleiben f. den ganzen Overhead und die Pakete gehen dann (hoffentlich) unfragmentiert durch, oder ????
Das LANCOM selbst zieht beim VPN immer 100 Bytes von der MTU der zugrunde liegenden Internetverbindung ab (das ergibt i.A. dann eine MTU von 1400 bzw. 1392...)
Gruß
Backslash
-
therministrator
- Beiträge: 30
- Registriert: 28 Jun 2007, 08:55
Hallo Backslash, toll dass Du so schnell bist
OK, dann wissen wir das...
Na ja, nachdem das Geraet die Option bietet, die MTU einzustellen, weiss es vermutlich auch was das ist, und haelt sich HOFFENTLICH dran
Haben die QOS Optionen ( Fragmente reassemblieren/weiterleiten ) einen Einfluss darauf ? (bzw. was bedeuten die Einstellungen?)
BINGO genau bei 1472 war Ende der Fahnenstange. Das heisst (wahrscheinlich) Gerät reassembliert nichtwenn das Gerät nicht reassemblieren kann ist bei 1472 Schluß...
OK, dann wissen wir das...
das sollte ausreichen - solange das Teil sich daran hält...
Na ja, nachdem das Geraet die Option bietet, die MTU einzustellen, weiss es vermutlich auch was das ist, und haelt sich HOFFENTLICH dran
Haben die QOS Optionen ( Fragmente reassemblieren/weiterleiten ) einen Einfluss darauf ? (bzw. was bedeuten die Einstellungen?)
therministrator
reassemblieren: Das LANCOM reassembliert alle Fragmente zu vollständigen Paketen, bevor es diese weitersendet (und dann ggf. wieder fragmentiert)
weiterleiten: Das LANCOM kümmert sich nicht darum und sendet sie einfach so weiter wie sie empfangen wurden.
filtern: Fragmente werden einfach verworfen...
Aus Sicherheitsgründen ist entweder "reassemblieren" oder "filtern" anzuraten, da es vertschiedene Angriffsarten über fragmentierte Pakete gibt (z.B. "ping of death"), die von der Firewall nicht erkannt werden können, wenn die Pakete einfach nur weitergeleitet werden - daher ist "reassemblieren" auch die Deafult-Einstellung
Gruß
Backslash
neinHaben die QOS Optionen ( Fragmente reassemblieren/weiterleiten ) einen Einfluss darauf ?
die Einstellung gibt an, wie das LANCOM mit Fragmenten umgehen soll(bzw. was bedeuten die Einstellungen?)
reassemblieren: Das LANCOM reassembliert alle Fragmente zu vollständigen Paketen, bevor es diese weitersendet (und dann ggf. wieder fragmentiert)
weiterleiten: Das LANCOM kümmert sich nicht darum und sendet sie einfach so weiter wie sie empfangen wurden.
filtern: Fragmente werden einfach verworfen...
Aus Sicherheitsgründen ist entweder "reassemblieren" oder "filtern" anzuraten, da es vertschiedene Angriffsarten über fragmentierte Pakete gibt (z.B. "ping of death"), die von der Firewall nicht erkannt werden können, wenn die Pakete einfach nur weitergeleitet werden - daher ist "reassemblieren" auch die Deafult-Einstellung
Gruß
Backslash
-
therministrator
- Beiträge: 30
- Registriert: 28 Jun 2007, 08:55
Hallo backslash,
Nochmals vielen Dank, dank Deiner Erklaerungen sehe ich jetzt klarer.
Es ist genau so wie Du gesagt hast: Das Ding kuemmert sich keinen Deut um die ganzen Spezifikationen.
Wenn ich die MTU des Geraets auf 1250 setze, gehen die Pakete durch.
( MTU im Tunnel automatisch - also wohl irgendwo ~~ 1350 )
Setze ich dann ( zur Gegenprobe) die MTU der VPN-Verbindung z.B. auf 1000 ist das Problem wieder da (die entsprechende Meldung - muss, kann aber nicht fragmentieren - taucht dann bei Paketgroesse irgendwo <1300 auf.
DAS duerfte wohl eigentlich nicht sein !!!
D.h. deas Geraet sendet seine Pakete mit seiner MTU, ohne sich um irgendwlche Verhandlungen und Standards zu kuemmern. "Passen" sie rein gut, wenn nicht auch gut ...
Wieder was gelernt , wieder eine Menge Zeit verbraten 
Nochmals DANKE
Nochmals vielen Dank, dank Deiner Erklaerungen sehe ich jetzt klarer.
Es ist genau so wie Du gesagt hast: Das Ding kuemmert sich keinen Deut um die ganzen Spezifikationen.
Wenn ich die MTU des Geraets auf 1250 setze, gehen die Pakete durch.
( MTU im Tunnel automatisch - also wohl irgendwo ~~ 1350 )
Setze ich dann ( zur Gegenprobe) die MTU der VPN-Verbindung z.B. auf 1000 ist das Problem wieder da (die entsprechende Meldung - muss, kann aber nicht fragmentieren - taucht dann bei Paketgroesse irgendwo <1300 auf.
DAS duerfte wohl eigentlich nicht sein !!!
D.h. deas Geraet sendet seine Pakete mit seiner MTU, ohne sich um irgendwlche Verhandlungen und Standards zu kuemmern. "Passen" sie rein gut, wenn nicht auch gut ...
Wieder was gelernt
, wieder eine Menge Zeit verbraten Nochmals DANKE