Ich hatte schon länger die Vermutung, dass irgendwas an den Firewall-Settings meines NETGEAR-Routers DG834GTB nicht ganz in Ordnung ist, da seit dem letzten Firmware-Upgrade auf Version 1.02.14 eine Reihe verschiedener Ports nach außen nicht freigegeben wurden, bzw. ganz seltsames Verhalten zu beobachten war. Dies äußerte sich z.B. darin, dass ich auf eine Reihe üblicher Messenger-Ports outbound nicht mehr connecten konnte, ich diese aber inbound freigeben konnte, ich zu anderen zwar UDP-Pakete schicken konnte, aber keine Antwort auf TCP-Connects bekam und was man sich sonst an seltsamen Verhalten vorstellen kann.
Nach dem gestern auf Grund dieses Verhaltens eine internet-Gaming-Session ins Wasser gefallen war, hab ich mich einmal umgeschaut, ob es irgendwo eine Beschreibung zum Zugriff auf die Router-Konsole gibt. Den daraufhin gefundenen Artikel mit ausführlichen Beschreibungen hab ich auch sofort in Angriff genommen, was sehr interessante Details zu Tage förderte. So z.B. folgendes Detail bzgl. der verbauten CPU:
# cat /proc/cpuinfo
system type : 96348GW-10
processor : 0
cpu model : BCM6348 V0.7
BogoMIPS : 255.59
wait instruction : no
microsecond timers : yes
tlb_entries : 32
extra interrupt vector : yes
hardware watchpoint : no
VCED exceptions : not available
VCEI exceptions : not available
Aber das war es weniger, was ich wissen wollte; wenn doch es interessant zu wissen ist, dass eine CPU im Entwicklungsstadium in diesem kleinen Kästchen verbaut ist 😉 Wichtiger war aber vielmehr, was in der Firewall-Konfiguration verbockt wurde:
# cat /tmp/nvram|grep fw
fw_nat=1
fw_block=0
fw_block_keyword=
fw_block_trust_enable=0
fw_block_trust=
fw_services_def=Any(ALL):any:1-65535Any(TCP):tcp:1-65535Any(UDP):udp:1-65535...
fw_services=...
fw_in_rules=...
fw_out_rules=
fw_dmz_enable=0
fw_dmz=
fw_spi=1
fw_response_ping=0
fw_schedule=1111111:0:0-24:0
fw_time_zone=+1a
fw_remote=1
fw_remote_type=1
fw_remote_range_start=0.0.0.0
fw_remote_range_end=0.0.0.0
fw_remote_single=127.0.0.1
fw_remote_port=65536
fw_import=0
Ich hab aus den Settings mal ein paar unwichtige 😛 Informationen entfernt. Das sind lediglich die auf meinem Router freigegebenen Dienste. Allgemein ausgedrückt ist meine Policy Ausgehend alles offen, eingehend nur freigegebene Dienste erlaubt. Verwundert hat mich in diesem Zusammenhang die Einstellung fw_import, die man besser als „Firewall IM-Port“ lesen sollte, statt als einzelnes Wort, aber die Vermutung hatte ich spätestens nach etwas Testen mit dem Webinterface.
Interessant war nun, dass unabhängig von der Einstellung der Einstellung fw_import immer folgende IP-Chain auftauchte:
# iptables --list REAIM_IN
Chain REAIM_IN (1 references)
target prot opt source destination
ACCEPT tcp -- anywhere anywhere tcp dpts:1863:1864
ACCEPT tcp -- anywhere anywhere tcp dpt:5566
ACCEPT tcp -- anywhere anywhere tcp dpt:5190
ACCEPT tcp -- anywhere anywhere tcp dpt:4443
ACCEPT tcp -- anywhere anywhere tcp dpts:40000:40099
ACCEPT tcp -- anywhere anywhere tcp dpt:1864
ACCEPT tcp -- anywhere anywhere tcp dpt:5566
ACCEPT tcp -- anywhere anywhere tcp dpt:5190
ACCEPT tcp -- anywhere anywhere tcp dpt:4443
ACCEPT udp -- anywhere anywhere udp dpts:40000:41000
was eigentlich in Bezug auf die INPUT-Chain (DROP-Policy) heißen müsste, dass diese Ports explizit geöffnet werden – für alle Interfaces. Naja, wurden sie aber nicht, was ein kurzer Blick mit tracetcp beweist:
# tracetcp login.icq.com:5190 -n
Tracing route to 64.12.200.89 on port 5190
Over a maximum of 30 hops.
1 Destination Reached in 1 ms. Port closed on 64.12.200.89
Trace Complete.
Wobei selbst dieser Trace in sich bereits sehr seltsam ist, da der erste Hop mein Router und nicht der Server von AOL ist …
Auch das manuelle Entfernen dieser Chain brachte keine Besserung. Also mal ein wenig bei NetGEAR auf der Seite umgeschaut und siehe da: Es gibt ein Firmware-Upgrade 1.02.15. Dieses installiert und seither dieses Problem los. Dafür auch das Setting fw_import …
Bliebe abschließend noch zu erwähnen, dass die Connection jetzt funktioniert:
# tracetcp login.icq.com:5190 -n
Tracing route to 64.12.161.185 on port 5190
Over a maximum of 30 hops.
1 3 ms 2 ms 2 ms 192.168.0.1
2 9 ms 8 ms 9 ms 87.186.224.22
3 9 ms 9 ms 9 ms 87.186.255.134
4 106 ms 105 ms 106 ms 62.156.131.162
5 108 ms 108 ms 108 ms 66.185.136.13
6 109 ms 110 ms 108 ms 66.185.138.250
7 110 ms 108 ms 108 ms 66.185.135.58
8 111 ms 108 ms 109 ms 172.20.149.106
9 Destination Reached in 111 ms. Connection established to 64.12.161.185
Trace Complete.
Bis zum nächsten Problem 😉
