Hallo zusammen,
ich hab hier einen Lancom 1821 mit Firmware 7.26 und das Problem,
das ein VPN Tunnel der von einen Server über den LANCOM aufgebaut
wird sporadisch zusammenbricht.
Teilweise so, das der Server der Meinung ist der Tunnel steht noch.
Ich hab jetzt syslog aktiviert und bekomm zu meinen Problemzeiten
folgende meldung:
PACKET_ALERT: Dst: 193.27.xx.xx:4500, Src: 192.168.31.1:4500(UDP); connection refused<000>
Teilweise mehrfach in abstand von einigen Sekunden.
Kann man Anhand der Meldung sehen, wer das "Connection refused" verursacht (LANCOM oder Gegenstellt)?
Jemand eine Idee?
Gruß
Bernd
LC1821+ sporadisch PACKET_ERROR
Moderator: Lancom-Systems Moderatoren
Hi bernd.dausch
- Die Firewall hat das Paket aus irgendeinem Grund abgelehnt
- die Maskierung hatte keinen Port mehr frei... Wie hoch ist eigentlich dein UDP-Timeout - default sind 20 Sekunden, was aber für ein NAT-T zu wenig sein könnte, da NAT-T nur alle 30 Sekunden ein Keep-Alive Paket schickt. Hier wäre ein Wert von 35 Sekunden sinnvoll - obwohl gerade bei UDP der Tiemout möglichst klein sein sollte...
Mach mal einen Firewall- und einen Maskierungs-Trace...
Den Firewall-Trace kannst du auf den Server einschränken, den Maskierungs-Trace auf Fehler, also
trace # firewall @ 192.168.31.1
trace # ip-masq @ fail
Gruß
Backslash
Mögliche Gründe wären:Ich hab jetzt syslog aktiviert und bekomm zu meinen Problemzeiten
folgende meldung:
PACKET_ALERT: Dst: 193.27.xx.xx:4500, Src: 192.168.31.1:4500(UDP); connection refused<000>
Teilweise mehrfach in abstand von einigen Sekunden.
Kann man Anhand der Meldung sehen, wer das "Connection refused" verursacht (LANCOM oder Gegenstellt)?
- Die Firewall hat das Paket aus irgendeinem Grund abgelehnt
- die Maskierung hatte keinen Port mehr frei... Wie hoch ist eigentlich dein UDP-Timeout - default sind 20 Sekunden, was aber für ein NAT-T zu wenig sein könnte, da NAT-T nur alle 30 Sekunden ein Keep-Alive Paket schickt. Hier wäre ein Wert von 35 Sekunden sinnvoll - obwohl gerade bei UDP der Tiemout möglichst klein sein sollte...
Mach mal einen Firewall- und einen Maskierungs-Trace...
Den Firewall-Trace kannst du auf den Server einschränken, den Maskierungs-Trace auf Fehler, also
trace # firewall @ 192.168.31.1
trace # ip-masq @ fail
Gruß
Backslash
-
- Beiträge: 16
- Registriert: 11 Feb 2007, 15:08