@voipd:
Das mit der Anmeldung habe ich versucht zu erklären. Zu dem Zeitpunkt, wo es um die Entscheidung "Login erforderlich oder nicht" geht, liegt die Information, über welches Interface ein Paket kam, gar nicht mehr vor. Zwar wird dieses Interface tatsächlich am Beginn im Paket vermerkt (für den PA, dafür ändert AVM sogar die sk_buff-Struktur im Kernel), aber zum Zeitpunkt der Abfrage beim ctlmgr liegt nur noch die IP-Adresse des Rechners vor, von dem das Login ausgehen soll. Ob das jetzt intern oder extern ist, wird bei AVM schon fast traditionell anhand der Frage entschieden, welches Interface dasjenige ist, über das eine bestimmte Adresse (in diesem Falle eben die Adresse der neuen Sitzung) erreichbar ist. Daß AVM die IP-Adresse an dieser Stelle heranzieht, ist doch aber weder neu noch besonders verwunderlich ... diese IP-Adresse wird ja sogar einer GUI-Sitzung explizit zugewiesen - wenn man eine SID mit der falschen IP-Adresse verwenden will, wirft die Box alle existierenden Sitzungen weg (von dieser IP-Adresse). Auch daß im Routing noch der Zugriff auf die komplette sk_buff-Struktur möglich ist, ist doch unbestritten - da könnte also tatsächlich noch die Absenderadresse herangezogen werden, aber warum sollte man das machen, wenn es nur um das Routing eines IP-Pakets geht? Was verspricht man sich davon?
Die Schlußfolgerungen im zweiten Absatz lehne ich immer noch ab ... aber ehe ich mich jetzt mit Dir darum streite, was "im Tunnel" heißen soll und was jetzt vor und nach dem OpenVPN ist, sollten wir uns vielleicht darauf einigen, das aus der Sicht von Interfaces zu betrachten und dann gibt es ganz klare Abgrenzungen. Ein Paket, was vom System an das "Pseudo-Netzwerkgerät" tun0 übermittelt wird, ist von diesem Zeitpunkt an beim OpenVPN-Code angekommen. Dieser erzeugt dann seinerseits die gekapselten Pakete (EDIT:
und sendet die aber eben nicht über tun0 wieder aus, sondern gibt sie seinerseits ans Routing ab doch, eigentlich macht er das genau so, denn das, was das OpenVPN seinerseits nach "tun0" schreibt, landet eben wieder im Linux-Kernel - war blöd und mißverständlich formuliert) und dann werden diese Pakete anhand ihrer Zieladresse an das nächste zuständige Interface übermittelt. Das läßt sich ziemlich einfach testen, denn so ein OpenVPN-Peer kann durchaus auch über "dev lan" erreichbar sein und das funktioniert dann auch.
Wenn Du jetzt einen Mitschnitt der FRITZ!Box von "dev lan" vorweisen könntest, bei dem diese Pakete mit Source-Adresse 192.168.71.44 auch nicht auftauchen, dann würde ich Dir vielleicht sogar zustimmen ... aber Du selbst hast bei den alten Screenshots im zweiten Bild gezeigt (auch wenn der inzwischen fehlt), daß die Pakete auf "dev lan" der FRITZ!Box ja sehr wohl ankommen (das ist dann schon "im System" der FRITZ!Box, wenn es protokolliert werden kann), egal von welcher Source-Adresse sie stammen.
Der nächste Schritt im logischen Ablauf ist es nun eben festzustellen, ob diese Pakete vom Routing-Code an das "dev tun0" übermittelt werden. Findet das nicht statt, ist es irgendetwas im FRITZ!OS, was das verhindert .. ansonsten kann das OpenVPN damit eben nichts anfangen. Auch wenn Du durchaus recht hast, daß man im OpenVPN-Protokoll eben nur erkennen kann, ob ein Paket gesendet/empfangen wird und nicht seinen Inhalt (genau das hatte ich ja schon geschrieben), ist eben schon diese Information ein Anhaltspunkt, wo es klemmt.
Den Teil mit der Versionsnummer hast Du - entgegen dem, was Du da schreibst - auch erst nachträglich ergänzt in #1, vorher stand da nur etwas von "letzter Beta" und auch da gibt es lt. AVM die 06.06 als "letzte Version" seit ca. 1 Monat - hätte es tatsächlich deutlich dort gestanden, hätte ich es auch ohne "Fettdruck" gefunden.
Das, was da auf der Routingschnittstelle zu sehen ist, sind auch nicht Deine überlangen Pakete, das ist mit einiger Wahrscheinlichkeit eben eine falsche MTU auf dem Weg zur Gegenstelle - ob die beiden Pakete (1500 + 88 Byte) nun zusammengehören oder nicht, hast Du meines Wissen auch nicht bestätigt oder bestritten.
Ich bin mir nicht so richtig sicher, ob Du den Mechanismus mit der internen Fragmentierung beim OpenVPN durchschaut hast ... vielleicht siehst Du ja noch einmal nach den Parametern "link_mtu", "tun_mtu" und "fragment" und dem Zusammenhang zwischen diesen Werten.
Eben durch den Umkehrschluss, dass Paket die mit .71.44 abgesendet werden dort nicht auftauchen. Siehe oben.
Dieser Umkehrschluß "verrät" Dir aber eben noch nicht, ob die Pakete nicht auf tun0 und damit zum OpenVPN gelangen oder ob das OpenVPN für diese Pakete keinen UDP-Traffic zu irgendeinem Peer erzeugt hat.
Du vertrittst nach wie vor die Überzeugung (der Beweis steht eben noch aus), daß es ersteres ist ... das ist aber bisher durch nichts belegt.
Was passiert denn, wenn Du mit der 192.168.71.44 als Absender ein normales Ping an eine Adresse ausführst, die sich nicht hinter tun0 verbirgt? Dabei würde das Paket dann vom Routing nicht an tun0, sondern direkt an "dev dsl" übergeben (eine Antwort kriegst Du natürlich trotzdem nicht, weil die wieder in den Tunnel geht, selbst wenn sie auf der FRITZ!Box ankommen sollte).
Wenn so ein Paket dort tatsächlich auch nicht auftauchen sollte, könnte man wieder den PA verdächtigen, daß er wirklich an der Absenderadresse etwas auszusetzen hat.
Wenn es erst auf der 1. Internetschnittstelle nicht auftaucht (aber vorher auf der Routingschnittstelle noch sichtbar ist), dann könnte das Connection-Tracking sich daran stören, daß die Absenderadresse dieses Pakets nicht im LAN ist ... glaube ich aber eigentlich auch nicht dran, das beträfe dann auch jeden VPN-(User-)Client beim AVM-IPSec oder jede entfernte Adresse bei LAN-LAN-Kopplungen - dort gibt es ja auch kein internes NAT.
So einen Test hast Du aber meines Wissens bisher genauso wenig ausgeführt (oder Du hast das Ergebnis weggelassen oder nachträglich ergänzt und ich habe es nicht gelesen) wie Du den Vorschlag umgesetzt hast, eine Route für 192.168.71.0/24 in der FRITZ!Box anzulegen, damit Du wenigstens vorübergehend mal die Fehlermeldungen in Form von ICMP-Paketen auch tatsächlich erhältst ... vermutlich wirst Du diese Route später ohnehin irgendwann mal brauchen und stören dürfte sie auch nicht, wenn das bisher von Dir Geschriebene alles korrekt war. Du willst ja die 192.168.20.103 erreichen, da stört eine Route für 192.168.71.0/24 nach "dev lan" ja irgendwie nicht.
Stattdessen machst Du diesen "Blödsinn" (ich muß es so nennen) mit knapp 64K in irgendwelchen Paketen (die schon der sendende PC fragmentieren muß und die nicht etwa das OpenVPN bereits wieder zusammensetzt) und die tatsächlichen "Basics" (Tunnel-Einstellungen, insb. zur MTU) hast Du auch auf ausdrückliche Nachfrage nicht beantwortet.
Wieso Du einen Test für einen Beweis hältst, der auch bei der Verwendung von 192.168.70.44 als Absenderadresse nicht funktioniert (oder antwortet da die 192.168.20.103 etwa richtig bei "-l 65000"?), verstehe ich immer noch nicht ... Du leitest aus dem Fehlen der vom OpenVPN verpackten Pakete auf "dev dsl" (die bei Verwendung von 192.168.70.44 vorhanden sind) die Schlußfolgerung ab, daß das OpenVPN diese Pakete gar nicht erst erhält.
Das ist für mich noch lange nicht ausgemacht ... es kann eben immer noch genauso gut sein, daß das OpenVPN diese Pakete nicht will - genauso gut
kann es sein, daß Du tatsächlich recht hast (und die Pakete nicht nach tun0 gehen, wobei ich dann immer noch nicht verstehe, woran das liegen sollte), bei 50:50 ist diese Chance durchaus vorhanden.
Aber die verwendete Methodik beim Testen gibt das - zumindest bisher und anhand der von Dir veröffentlichten Ergebnisse - noch nicht her (wenn ich nicht irgendwelche Ergänzungen übersehen haben sollte, das macht nebenbei bemerkt auch wenig Spaß, sich immer wieder die vorherigen Beiträge erneut durchlesen zu müssen und dann aus dem Gedächtnis die Unterschiede zu rekapitulieren).
Dieser "Filter", den Du da vermutest, würde jedenfalls auch bei anderen Netzwerk-Konfigurationen (eben z.B. auch einer LAN-LAN-Kopplung zweier FRITZ!Boxen, bei der die eine FRITZ!Box über die Internetverbindung der anderen arbeiten soll - natürlich nicht für den IPSec-Traffic) ja im Wege sein ... wenn die lokale FRITZ!Box die 192.168.178.0/24 verwendet und die entfernte die 192.168.177.0/24, dann sieht ja jedes Paket aus dem entfernten Netz für die lokale FRITZ!Box wie "aus einem anderen Netz" aus und auch da funktioniert das Connection-Tracking, wie man erstens anhand der Funktion so einer Konstruktion und zweitens anhand der Einträge im procfs überprüfen kann.
Ich habe aber keine 7240 und verstehe auch nicht, warum man irgendeine alte Beta-Version benutzen muß oder will ... bei der 06.06 der 7270v3 funktioniert das mit dem CT jedenfalls definitiv auch dann, wenn ein Paket für eine ausgehende Verbindung eine nicht-lokale Absenderadresse hat.
)
