Conntrack erhält falsche Weiterleitungsregeln für das ausgehende Protokoll 41

Ich versuche, Protokoll 41 (ipv6-in-ipv4) für einen HE-Tunnel durch einen WRT54G mit Tomato 1.28 weiterzuleiten. Tomato 1.28 betreibt einen 2.4-Kernel, der absolut nichts über Protokoll 41 weiß, außer dass es "ipv6" heißt. Ein 2.4er Kernel scheint auch zu bedeuten, dass conntrack nicht einfach deaktiviert werden kann: Es gibt keine "rohen" iptables-Regeln.

Ich kann Regeln einrichten, damit eingehende Pakete DNAT-Daten an den richtigen internen Host senden. Wenn der entfernte Host zuerst etwas über den Tunnel sendet, funktioniert alles einwandfrei. Pakete können durch richtiges NATing in beide Richtungen über den Tunnel fließen, und ich bekomme einen /proc/net/ip_conntrackEintrag wie folgt :

unknown 41 599 src=72.52.104.74 dst=67.180.229.14 src=10.1.0.3 dst=72.52.104.74 use=1 mark=0

Der Eintrag sagt, dass es für das unbekannte Protokoll 41 ist, hat ein Zeitlimit von 599 Sekunden mehr, wenn kein Verkehr mehr empfangen wird, und es hat ein Paar von Quell- und Zieladressen auf der initiierenden Seite (die die WAN-Seite ist) und einem anderen auf der Empfängerseite (was ist die LAN-Seite).

Wenn mein System jedoch versucht, ein Paket zuerst über den Tunnel zu senden, wird die Quelladresse nicht wie gewünscht in die Adresse des Routers übersetzt, und ich bekomme einen Conntrack-Eintrag wie folgt:

unknown 41 589 src=10.1.0.3 dst=72.52.104.74 [UNREPLIED] src=72.52.104.74 dst=10.1.0.3 use=1 mark=0

Solange mein Computer ständig versucht, den Tunnel zu verwenden, hält er diesen gefälschten conntrack-Eintrag am Leben, und ich kann die Pakete sehen, die meinen Router für das Kabelmodem verlassen, wobei die interne Quelladresse immer noch angehängt ist, wodurch sie fallengelassen werden und niemals dorthin gelangen Sie gehen.

Um meinen Tunnel zum Hochfahren zu bringen, muss ich die Tunnelschnittstelle an meinem Ende herunterfahren, das HE-Ping-Tool verwenden, um den IPv6-Verkehr zu veranlassen, die Pipe herunterzufahren, und das 10-Minuten-Timeout ist immer noch korrekt conntrack entry, bringen Sie mein Ende des Tunnels wieder hoch - und stellen Sie dann sicher, dass es 10 Minuten lang nicht leer ist. Ich kann das, aber es ist ziemlich dumm.

Im Moment habe ich meine Weiterleitungsregeln wie folgt eingerichtet:

# Send incoming ipv6-in-ipv4 packets to the correct host iptables -t nat -A PREROUTING -p 41 -s 72.52.104.74 -j DNAT --to 10.1.0.3  # Allow those packets through the firewall iptables -I FORWARD -p 41 -d 10.1.0.3 -j ACCEPT  # Things I have added to try and solve my problem, which didn't work:  # Remove the default masquerade-everything rule iptables -t nat -D POSTROUTING 10 # Masquerade only protocols other than 41. Conntrack still gets its bogus entries,  # and if I get the correct entry in it still works. iptables -t nat -A POSTROUTING -p ! 41 -j MASQUERADE 

Ich habe auch einmal versucht, eine SNAT-Regel wie folgt einzurichten:

iptables -t nat -I POSTROUTING -p 41 -s 10.1.0.3 -j SNAT --to 67.180.229.14

Aber soweit ich das beurteilen konnte, war das auch keine Hilfe.

Meine Frage ist also:

1) Hat jemand jemals das Protokoll 41 für die Weiterleitung durch einen WRT54G mit erfolgreicher Tomato erhalten? Wenn ja, welche speziellen Firewall-Regeln haben Sie verwendet?

2) Warum glaubt der Router, dass er keine Quelladressenübersetzung für das ausgehende Protokoll 41 vornehmen muss?