Duo2 Paketverluste über VPN - egal welches Image

    Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

    • Duo2 Paketverluste über VPN - egal welches Image

      Moin moin zusammen,

      nach einigen Jahren wollte ich meine Solo in den Ruhestand schicken und habe mit eine neue Duo2 gegönnt. Ich habe das VTI 13 Image installiert und eine Grundkonfiguration gemacht (DVB-S, ein wenig am Skin, das Übliche). TV geht, alles gut. Nun nutze ich auch Ressourcen über ein VPN, das ich über eine Sophos UTM aufbaue (bei mir VDSL 50, andere Seite Kabel 100), die hinter einer Fritz Box steckt. Auf der Fritz Box zeigt eine statische Route in das VPN-Netz auf die Sophos.

      Nach einigen Sekunden ist die Ressource im VPN-Netz nicht mehr verfügbar. Ich logge mich per SSH ein um das zu prüfen. Pinge ich eine interne IP ist alles gut (keine Paketverluste, Latenz bei 0ms). Pinge ich eine IP im Internet (z.B. Google DNS), ist auch alles gut. Pinge ich eine IP im VPN-Netz, gehen zwei Pings durch, der Rest geht verloren. Das Spiel kann ich mit allen erreichbaren IPs im VPN-Netz spielen. Zwei Pings gehen durch, dann ist vorbei und die IPs sind auch nicht mehr erreichbar - bis ich das Netzwerk auf der Duo2 neu starte.

      Es liegt definitiv nicht am Switch, Router oder VPN. Die Solo läuft, meine Dreambox 500HD läuft, mit meinem iPad kann ich dauerhaft eine RDP-Verbindung über das VPN öffnen und von allen möglichen Geräten zu diversen IPs kann ich kreuz und quer durchs VPN pingen.

      Was habe ich schon versucht:

      - VTI 11 Image
      - VTI 13 Image
      - Aktuelles, oiginales VU+ Image
      - Anderer Switch
      - Anderes Netzwerkkabel
      - Interface von 1Gbit auf 100Mbit gezwungen (eher eine Verzweiflungstat)
      - Feste IP anstatt DHCP (auch eher aus Verzweiflung)
      - Anderes Gateway (statische Route von Fritz Box zum VPN-Gateway umgangen)

      Hat einer von euch irgendeine Idee hierzu oder hat daon schon mal gehört? Ich habe noch keinen Netzwerksniffer ausgepackt und mal einen Dump gemacht. Das wäre der nächste Schritt... Die Firewall sagt auf jeden Fall auf den ersten Blick nichts dazu. Es wird nichts geblockt.

      :wall1: ;( :crazy2:

      Gruß
      Torben
    • Moin,

      gute Idee, das war es aber leider nicht. Hatte Flood Protection nicht an, auf beiden Seiten (weder UDP oder TCP, noch ICMP).

      Hab heute Morgen mal nen TCPDump auf beiden Firewalls gestartet und eine IP gepingt. Die Pakete gehen wunderbar durch. Nach zwei erfolgreichen Pingpakete sehe ich nur noch ARP-Anfragen der Duo2. Im ARP-Cache der Duo2 wird dann ein Eintrag mit "Incomplete" angelegt. Ab da bricht dann auch der Ping ab. Wenn ich es richtig gelesen habe, bedeutet "incomplete" in dem Fall eher "deleted", da keine Antwort auf die ARP-Anfrage kam. Demnach dürfte es theoretisch nicht stören, dass es den Eintrag gibt. Ich kann den Eintrag auch nicht löschen. Sobald ich einen gültigen Eintrag lösche, steht der ebenfalls als "incomplete" in der Liste und wir erneuert, sobald eine ARP-Anfrage beantwortet wird. Aber auf eine Antwort aus einem gerouteten Netz kann die Box verdammt lange warten....

      Dump der Firewall sieht so aus (192.168.3.106 ist die Duo2 und 192.168.0.12 mein Zil im VPN):

      08:57:32.845462 IP (tos 0x0, ttl 64, id 17186, offset 0, flags [DF], proto ICMP (1), length 84)
      192.168.3.106 > 192.168.0.12: ICMP echo request, id 47107, seq 0, length 64
      08:57:32.887922 IP (tos 0x0, ttl 64, id 51975, offset 0, flags [none], proto ICMP (1), length 84)
      192.168.0.12 > 192.168.3.106: ICMP echo reply, id 47107, seq 0, length 64
      08:57:33.845564 IP (tos 0x0, ttl 64, id 17187, offset 0, flags [DF], proto ICMP (1), length 84)
      192.168.3.106 > 192.168.0.12: ICMP echo request, id 47107, seq 1, length 64
      08:57:33.891363 IP (tos 0x0, ttl 63, id 52173, offset 0, flags [none], proto ICMP (1), length 84)
      192.168.0.12 > 192.168.3.106: ICMP echo reply, id 47107, seq 1, length 64
      08:57:34.845646 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.0.12 tell 192.168.3.106, length 46
      08:57:34.845679 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.0.12 tell 192.168.3.106, length 46
      08:57:35.846935 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.0.12 tell 192.168.3.106, length 46
      08:57:35.846963 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.0.12 tell 192.168.3.106, length 46
      08:57:36.848938 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.0.12 tell 192.168.3.106, length 46
      08:57:36.848966 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.0.12 tell 192.168.3.106, length 46
      08:57:37.848961 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.3.20 tell 192.168.3.106, length 46

      Und so sieht die ARP-Tabelle auf der Duo2 aus:

      arp -n
      ? (192.168.0.8) at <incomplete> on eth0
      ? (192.168.3.20) at 80:ee:73:b1:1c:a2 [ether] on eth0
      ? (192.168.0.13) at <incomplete> on eth0
      ? (192.168.0.12) at <incomplete> on eth0
      ? (192.168.0.10) at <incomplete> on eth0
      ? (192.168.3.1) at 34:31:c4:6f:03:09 [ether] on eth0
      ? (192.168.3.130) at 64:27:37:7d:fb:c8 [ether] on eth0
    • So, mal ein Update dazu... Während ich mich im Garten am Unkraut abreagiert habe, habe ich noch mal nachgedacht... Ich habe es nun mit einem Workaround am Laufen:

      - Der Sophos eine weitere IP gegeben
      - Eine DNAT-Regel erstellt, die sämtlichen Anfragen an diese IP an die Ziel-IP weiterleitet
      - In der Duo2 die neue IP der Firewall als Ressource angegeben

      Ich kann stabil pingen (an der Latenz sehe ich, dass ich wirklich das Ziel im VPN pinge) und ebenfalls seit einigen Minuten stabil einen Film gucken, den ich im VPN-Netz liegen habe...

      Vielleicht hab ich da ja wirklich einen Bug gefunden? Das Talent habe ich für sowas :happy4: ;_(