Veraltete conntrack Information nach Entfernung von NAT

Gestern Nacht hatte ich ein Problem, was mich beinahe in den Wahnsinn getrieben hätte…

Zu Hause habe ich einen OpenVPN Client, mit dem ich einen bridged Tunnel zu einer VM (vm02) in ein Rechenzentrum aufbaue. Diese VM hatte bis gestern keine eigene öffentlich IP. Auf der Firewall, die vor dieser VM ist habe ich ein NAT mit iptables konfiguriert, damit der OpenVPN Dienst über die IP einer anderen VM (vm01) verfügbar ist. Es wurde nur der OpenVPN Port ge-NAT-ed.

Nun habe ich vm01 abgeschaltet (wurde nicht mehr benötigt) und habe die öffentliche IP dieser VM der vm02 gegeben. In meinem iptables Script habe ich auch das NAT entfernt. Allerdings wurde die Verbindung meines OpenVPN Client (T-Home Anschluß mit 79er IP) weiterhin an die vm02 ge-NAT-ed.

Ich hatte dazu auch gestern Abend diverse Sachen durchprobiert, vielleicht hat ja irgendwer, irgendwann mal das gleich “Problem” Erstmal, anzeigen lassen kann man sich die Verbindung auf der Firewall mit cat /proc/net/ip_conntrack. Bei mir sah das in etwa so aus:

root@fw:~# cat /proc/net/ip_conntrack
[...]
udp      17 178 src=79.240.248.170 dst=203.125.178.211 sport=1194 dport=1194 packets=853 bytes=361394 [...] [ASSURED] mark=0 secmark=0 use=2
[...]

Die IP 79.240.248.170 (fiktiv) ist mein T-Home Anschluß, die IP 203.125.178.211 die öffentliche IP (ebenfalls fiktiv), unter der mein OpenVPN Server per NAT erreichbar war.

Ein Neustart der OpenVPN Dienste (auf dem Server, als auch auf dem Client) blieben ohne Erfolg. Also habe ich mit iptables eine Rule geschrieben, die alle Verbindungen von 79.240.248.170 DROPed, jedoch ohne Erfolg, conntrack hat sich weiterhin die Verbindung gemerkt. Im Netz habe ich auf die schnelle auch nichts gefunden - ich muss zugeben, dass ich irgendwann auch mal keine Lust mehr hatte. Also meinen Router ins Netz neu einwählen lassen, neue öffentliche T-Home IP bekommen und das Problem hatte sich erledigt.

Heute hatte ich dann aber zu Recherchen mehr Zeit. Die ellegante Variante wäre gewesen, dass ich mit den conntrack-tools (apt-get install conntrack) gearbeitet hätte. Erst die richtige Verbindung herausfiltern…

root@fw:~# conntrack -L -s 79.240.248.170 -d 203.125.178.211
# -L - list
# -s - source address
# -d - destination address
udp      17 178 src=79.240.248.170 dst=203.125.178.211 sport=1194 dport=1194 packets=853 bytes=361394 [...] [ASSURED] mark=0 secmark=0 use=2

… und dann löschen…

root@fw:~# conntrack -D -s 79.240.248.170 -d 203.125.178.211
# -D - delete
# ...

Tja, so einfach wäre es gewesen…