Hallo Forum 
Da ich mir mittlerweile auf mein NAT - Problem zwischen einem Allnet All7902 und meinem Linksys WRT54GS keinen Reim mehr machen kann, klimpere ich das hier mal in´s Forum und hoffe, daß sich hier der eine oder andere Linux/Iptables/NAT - Guru rumtreibt und mir weiterhelfen kann ... (wahrscheinlich hab ich einfach nur ein Brett vorm Kopf und die Lösung ist total einfach ... ich komme aber nicht drauf)
Folgende Konstellation:
Der ATA ist mit der festen IP 192.168.1.45 an den Router angeschlossen. Dieser hat die LAN - IP 192.168.1.5 und ist für den Aufbau der PPPOE - Verbindung zuständig.
Wenn der ATA eine STUN - Anfrage sendet, ( an STUN.SIPGATE.NET:3478), geht diese (bedingt durch die in den meisten Firewall implementierte Defaultregel, allen ausgehenden Traffic durchzulassen), problemlos raus
Outgoing Log:
LAN IP Destination URL/IP Service/Port Number
accepted 192.168.1.45 217.10.79.2 3478 UDP
Soweit ist ja noch alles prima ... jetzt kommt aber die Antwort
Incoming Log:
denied 217.10.79.3 31668 UDP
denied 217.10.79.2 31668 UDP
denied 217.10.79.3 31668 UDP
denied 217.10.79.2 31668 UDP
Wie man sieht, versuchen 2 IP-Nummern, auf die STUN - Anfrage eine Antwort zu senden und benutzen dazu Port 31668. Das ist ja eigentlich noch kein Problem, da die Anfrage an den STUN - Server ja auf einem beliebigen lokalen Port rausgegangen sein kann. Zumindest die Antworten von IP 217.10.79.2 sollten ja eigentlich durchkommen.
Jetzt aber ein Auszug aus der ip_conntrack:
udp 17 64 src=192.168.1.45 dst=217.10.79.2 sport=31667 dport=3478 src=217.10.79.2 dst=84.187.219.154 sport=3478 dport=31667 use=1
udp 17 64 src=192.168.1.45 dst=217.10.79.3 sport=31667 dport=3478 src=217.10.79.3 dst=84.187.219.154 sport=3478 dport=31667 use=1
udp 17 64 src=192.168.1.45 dst=217.10.79.2 sport=31668 dport=3478 [UNREPLIED] src=217.10.79.2 dst=84.187.219.154 sport=3478 dport=31668 use=1
Wie man sieht, hat der ATA mehrere Anfragen an den STUN - Server gesendet (192.168.1.45:31667 fragt bei 217.10.79.3:3478 an, da der ATA nicht direkt am DSL-Modem hängt, geht die Anfrage über 84.187.219.154:31667 raus)
Würde der STUN - Server jetzt seine Antwort an die IP 84.187.219.154:31667 schicken, wäre alles prima, da laut ip_conntrack eine Anwort auf dieser IP/Port - Kombination erwartet wird.
Leider leider erfolgt die Antwort aber nicht auf Port 31667, sondern auf Port 31668, somit gilt der Eintrag in ip_conntrack nicht und die eingehende Antwort wird verworfen.
Der lokale Port, auf dem die Anfrage rausgeht (in diesem Falle 31667), bedient sich wohl nach dem Zufallsprinzip aus einem recht großen Pool von Ports (nach vielen vielen Tests glaube ich, daß dafür der Range 16000 - 38000 verwendet wird)
Nun zu meiner Frage ....
Ist dieses Verhalten bei STUN üblich (also die Tatsache, daß die Antwort auf einem anderen Port gesendet wird als dem, von dem die Frage kam) oder bin ich einfach zu blöd, den ATA bzw. Router richtig zu konfigurieren?
Kann ich evtl. durch irgendeinen Trick den ATA dazu "zwingen", für seine ausgehende Anfrage einen bestimmten lokalen Port zu verwenden, damit ich den Range von möglichen Antwortports auf einen etwas überschaubareren Bereich (der kleiner ist als der Bereich 16000 - 38000) eingrenzen kann?
Sorry, falls das eine unglaublich blöde Frage sein sollte (ist es für Netzwerkprofis wahrscheinlich ...) aber das übersteigt meine äußerst begrenzten Kenntnisse in diesem Bereich bei weitem ....
Da ich mir mittlerweile auf mein NAT - Problem zwischen einem Allnet All7902 und meinem Linksys WRT54GS keinen Reim mehr machen kann, klimpere ich das hier mal in´s Forum und hoffe, daß sich hier der eine oder andere Linux/Iptables/NAT - Guru rumtreibt und mir weiterhelfen kann ... (wahrscheinlich hab ich einfach nur ein Brett vorm Kopf und die Lösung ist total einfach ... ich komme aber nicht drauf)
Folgende Konstellation:
Der ATA ist mit der festen IP 192.168.1.45 an den Router angeschlossen. Dieser hat die LAN - IP 192.168.1.5 und ist für den Aufbau der PPPOE - Verbindung zuständig.
Wenn der ATA eine STUN - Anfrage sendet, ( an STUN.SIPGATE.NET:3478), geht diese (bedingt durch die in den meisten Firewall implementierte Defaultregel, allen ausgehenden Traffic durchzulassen), problemlos raus
Outgoing Log:
LAN IP Destination URL/IP Service/Port Number
accepted 192.168.1.45 217.10.79.2 3478 UDP
Soweit ist ja noch alles prima ... jetzt kommt aber die Antwort
Incoming Log:
denied 217.10.79.3 31668 UDP
denied 217.10.79.2 31668 UDP
denied 217.10.79.3 31668 UDP
denied 217.10.79.2 31668 UDP
Wie man sieht, versuchen 2 IP-Nummern, auf die STUN - Anfrage eine Antwort zu senden und benutzen dazu Port 31668. Das ist ja eigentlich noch kein Problem, da die Anfrage an den STUN - Server ja auf einem beliebigen lokalen Port rausgegangen sein kann. Zumindest die Antworten von IP 217.10.79.2 sollten ja eigentlich durchkommen.
Jetzt aber ein Auszug aus der ip_conntrack:
udp 17 64 src=192.168.1.45 dst=217.10.79.2 sport=31667 dport=3478 src=217.10.79.2 dst=84.187.219.154 sport=3478 dport=31667 use=1
udp 17 64 src=192.168.1.45 dst=217.10.79.3 sport=31667 dport=3478 src=217.10.79.3 dst=84.187.219.154 sport=3478 dport=31667 use=1
udp 17 64 src=192.168.1.45 dst=217.10.79.2 sport=31668 dport=3478 [UNREPLIED] src=217.10.79.2 dst=84.187.219.154 sport=3478 dport=31668 use=1
Wie man sieht, hat der ATA mehrere Anfragen an den STUN - Server gesendet (192.168.1.45:31667 fragt bei 217.10.79.3:3478 an, da der ATA nicht direkt am DSL-Modem hängt, geht die Anfrage über 84.187.219.154:31667 raus)
Würde der STUN - Server jetzt seine Antwort an die IP 84.187.219.154:31667 schicken, wäre alles prima, da laut ip_conntrack eine Anwort auf dieser IP/Port - Kombination erwartet wird.
Leider leider erfolgt die Antwort aber nicht auf Port 31667, sondern auf Port 31668, somit gilt der Eintrag in ip_conntrack nicht und die eingehende Antwort wird verworfen.
Der lokale Port, auf dem die Anfrage rausgeht (in diesem Falle 31667), bedient sich wohl nach dem Zufallsprinzip aus einem recht großen Pool von Ports (nach vielen vielen Tests glaube ich, daß dafür der Range 16000 - 38000 verwendet wird)
Nun zu meiner Frage ....
Ist dieses Verhalten bei STUN üblich (also die Tatsache, daß die Antwort auf einem anderen Port gesendet wird als dem, von dem die Frage kam) oder bin ich einfach zu blöd, den ATA bzw. Router richtig zu konfigurieren?
Kann ich evtl. durch irgendeinen Trick den ATA dazu "zwingen", für seine ausgehende Anfrage einen bestimmten lokalen Port zu verwenden, damit ich den Range von möglichen Antwortports auf einen etwas überschaubareren Bereich (der kleiner ist als der Bereich 16000 - 38000) eingrenzen kann?
Sorry, falls das eine unglaublich blöde Frage sein sollte (ist es für Netzwerkprofis wahrscheinlich ...) aber das übersteigt meine äußerst begrenzten Kenntnisse in diesem Bereich bei weitem ....
