UDP über VPN - was muss in die ACL?

[CaptainDXB]

--> Das Problem ist gelöst. <--

generell sind default mäßig alle UDP Ports bis auf den 5060 freigegeben. Man braucht also nichts weiter zu tun. Das Problem war in meinem Fall ein nicht richtig funktionierende Jabber Server.

Für den Fall das jemand iChat mit Video/Audio mit Mac OS X über VPN machen will:

Auf einem Rechner hinter der FB diesen jabber Server installieren. Dann geht iChat auch mit allen features...


Hallo,

ich steh gerade etwas auf dem Schlauch. Ich möchte gerne die UDP Ports

- 5060
- 5353
- 16384 - 16403

über VPN tuneln.

In die ACL der Fritz vpncfg habe ich folgendes Eingetragen:

...
"permit udp any any eq 5060",
"permit udp any any eq 5353",
"permit udp any any range 16384 16403";
...

Auf der Gegenseite wird eine Client Verbindung mit IPsecuritas aufgebaut.
Das dumme ist - die Ports werde nicht getunnelt...

Hat jemand eine Idee warum und wie das zu lösen ist?

Danke
DXB

 

[RiverSource]

UDP über AVM VPN hat noch nie funktioniert. Benutze einfach mal die Suche.

 

[CaptainDXB]

Sorry mein Freund - nur weil sich hier im Forum mehr Fragen als Antworten zu dem Thema häufen bedeutet das nicht das es nicht geht.

UDP über VPN funktioniert prinzipiell mit der FB. Das habe ich selber bereits hinbekommen. Es gibt da nur ein kleines Problem das ich bislang nicht lösen konnte: Die Sache klappt nur als unicast wenn sie vom Client initiiert wird. Multicast geht (mit gutem Grund) erstmal nicht.

Allerdings bin ich überzeugt davon das man Ports dafür freischalten kann. Mögliche Weise gibt es mit dem SIP Port ein größeres Problem - aber die anderen müssen irgendwie gehen. Mein Interresse ist, raus zu bekommen wie das geht - da war die vpncfg ein kläglicher - und wie inzwischen zugeben muss - völlig unzureichender Anfang. Das Problem liegt mit großer Wahrscheinlichkeit nicht an der VPN Implementierung sondern an der internen Firewall und dem internen Routing der Box.

Versteh mich nicht falsch - ich will nicht unbedingt eine Bridge Funktion. Ich möchte _nur_ diese Ports in einem Netz darüber kriegen. OpenVPN scheidet bei der 7390 ja wohl erstmal aus, also muss eine andere Lösung her.

Wenn Du eine Idee hast tu sie kund oder erkläre warum Du so sicher bist das es nicht geht. Vielleicht hilft das ja einen Ansatzpunkt zu finden.

cu
DXB

 

[RiverSource]

UDP über VPN funktioniert prinzipiell mit der FB.

An der Lösung wären sicher viele Leute interessiert. Es gibt eben mehrere Berichte, dass keinerlei UDP Pakete das anderer Ende der VPN Verbindung erreichen - welche Dienste oder Ports auch immer.

Mögliche Weise gibt es mit dem SIP Port ein größeres Problem - aber die anderen müssen irgendwie gehen.

Was ist denn dann an SIP so besonderes? An der Portnummer liegt es offensichtlich nicht. D.h., AVM müsste schon eine Dienst- oder Protokollerkennung implementiert haben.

Das Problem liegt mit großer Wahrscheinlichkeit nicht an der VPN Implementierung sondern an der internen Firewall und dem internen Routing der Box.

Wohl eher nicht. In der Firewall wird nichts außergewöhnliches gesperrt.

OpenVPN scheidet bei der 7390 ja wohl erstmal aus, also muss eine andere Lösung her.

OpenVPN auf der 7390 geht. Sowohl mit Freetz als auch als Nachladelösung. Siehe: http://www.ip-phone-forum.de/showthread.php?t=214388

 

[CaptainDXB]

SIP:
Wenn die VoiP Funktion der Box genutzt wird greift sie sich u.a. den 5060 Port. Wenn man den für VPN freigibt, kann sich die Box danach nicht mehr registrieren. Kann man ausprobieren indem man in der vpncfg die 5060 mit any/any freischaltet.

FW:
Die FW blockt tatsächlich nichts besonders. Allerdings macht sie NAT. Der Effekt der bei VPN auftritt, ist der eines reverse NAT. Deshalb tippe ich als eine Ursache auf FW. Hintergrund ist vermutlich das die FW auf ein virtuelles if mit eigener IP gebunden ist (dsl) und hier eben auch NAT/PAT für VPN macht.

Ein weiters damit verbundenes Problem ist, das der VPN Zugang vermutlich über ein weiteres internes Netz geht. Multicast/Broadcast wird grundsätzlich erstmal nicht über verschiedne Netze geroutet. Es sieht zwar so aus als wenn der Client eine Adresse im gleichen Netz hat, nur stimmt das leider nicht ganz. Es ist ein zweites Netz mit dem gleichen Adressraum vermutlich hinter der FW, die vermutlich auch hier NAT macht. Allerdings kann die Box multicast routing. Die Frage ist nur wie man es dafür einschaltet und ob sich die FW dafür umgehen läst...

7390 OpenVPN: Wusste ich noch nicht das es hier schon soweit fortgeschritten ist. Schau ich mir auf jeden Fall an.

Ich versuche jetzt erstmal das interne routing der Box besser zu verstehen und melde mich wenn ich neue Erkenntnisse habe. Vielleicht hat ja jemand auch noch mehr Ideen - genauer Kenntnisse die er hier preisgeben will

 

[RiverSource]

SIP:
Wenn die VoiP Funktion der Box genutzt wird greift sie sich u.a. den 5060 Port. Wenn man den für VPN freigibt, kann sich die Box danach nicht mehr registrieren. Kann man ausprobieren indem man in der vpncfg die 5060 mit any/any freischaltet.

Und wieso klappt es dann mit OpenVPN?

Hintergrund ist vermutlich das die FW auf ein virtuelles if mit eigener IP gebunden ist (dsl) und hier eben auch NAT/PAT für VPN macht.

Nein, über VPN wird eben kein NAT gemacht. Ein Roadwarrior VPN Client bekommt eine IP aus dem Subnetz der Fritzbox, und bei LAN-LAN Verbindungen wird "richtig" geroutet: Im entfernten Subnetz kommen die IP-Pakete mit der eigenen Adresse an. Zigfach nachzulesen in den Threads "Warum kann ich auf meine Windows Freigaben nicht zugreifen?" Antwort: "Weil die Firewall die Zugriffe aus dem fremden Subnetz blockt".

Es sieht zwar so aus als wenn der Client eine Adresse im gleichen Netz hat, nur stimmt das leider nicht ganz. Es ist ein zweites Netz mit dem gleichen Adressraum vermutlich hinter der FW, die vermutlich auch hier NAT macht.

Was? Ein "zweites Netz mit dem gleichen Adressraum"? Das würde ein totales Routing-Chaos geben. Nee, theoretisch völlig unmöglich.

Allerdings kann die Box multicast routing. Die Frage ist nur wie man es dafür einschaltet und ob sich die FW dafür umgehen läst...

Sie kann Multicast-Streams, die über ein dediziertes VLAN bzw. über einen dedizierten ATM PVC von ihrem WAN Interface an ihre lokalen Ports verteilen. Ob sie ein vollwertiger Multicas-Router ist, wage ich zu bezweifeln.

Multicast über VPN könnte problematisch sein. Multicasts arbeiten ja mit spezifischen MAC-Adressen (Broadcast-MACs). Ob man das so ohne weiteres auf VPN abbilden kann? Es gibt ja kein virtuelles Interface für die AVM VPN Lösung, die machen es ja wie IPSec in Linux und fischen die Pakete irgendwie anders aus dem Datenstrom raus.
Und außerdem muss der Stream durch den Uplink der DSL Verbindung. Da ist nicht viel Platz.
Und Multicast Streams werden über UDP übertragen. Und das geht nicht über AVm VPN.

 

[CaptainDXB]

Wieso kappt es mit OpenVPN:

Mit openVPN klappt es auch nur im bridge mode. Außerdem terminiert der Tunnel im Gegensatz zur AVM Variante hinter der firewall. Anders geht es auch nicht weil AVM seine Firewall + eine Art IPtables und noch einiges anderes, in eine nette monolytische Blackbox gepackt hat. Die Konfiguration dieser Blackbox wird u.a. über die ar7.cfg erledigt. Allerdings scheint es noch andere Dateien zu geben die hier mitspielen - die ich allerdings noch nicht identifiziert habe.

zu 2 & 3:

Das gibt kein Chaos und ist nicht einmal wirklich ungewöhnlich:

Netz 1 (eth0): 192.168.178.0 -> NAT ->internes transfer Netz 169.254.0.0 -> VPN Server -> tunnel über das internet ->Client 192.168.178.201

Ruf einfach mal auf dem Telnet der Box ifconfig auf... Ich hatte das 169'er Netz im post eines anderen Users erst für einen Fehler gehalten. Ist es aber nicht. Die FB hat diverse interne Netze die zum Teil auf virtuellen Interfaces terminieren.

Multicast über VPN:

Dem Tunnel / IPsec ist Multicast erstmal egal solange es sich um IP handelt. UDP liegt im OSI Model oberhalb von IP und funktioniert damit. Das Problem ist, was hinter bzw. vor dem Tunnel passiert. Also was die FB bzw. der Client damit macht. Darüber hinaus sperrt es auch die Firewall. Wenn Du mal einen Blick in die ar7.cfg wirfst, siehst Du, das die Firewall die Multicast Adressen blockt - warum auch immer.

cu
DXB

 

[RiverSource]

Mit openVPN klappt es auch nur im bridge mode.

Nein, stimmt nicht.

Die Konfiguration dieser Blackbox wird u.a. über die ar7.cfg erledigt. Allerdings scheint es noch andere Dateien zu geben die hier mitspielen - die ich allerdings noch nicht identifiziert habe.

Dann sieh dir doch mal das AVM Firewall Paket aus Freetz an. Die können es ja offensichtlich.

Das gibt kein Chaos und ist nicht einmal wirklich ungewöhnlich:

Netz 1 (eth0): 192.168.178.0 -> NAT ->internes transfer Netz 169.254.0.0 -> VPN Server -> tunnel über das internet ->Client 192.168.178.201

Das ist was völlig anderes, als du oben beschrieben hast:

Es ist ein zweites Netz mit dem gleichen Adressraum vermutlich hinter der FW

Und APIPA Adressen wird mit Sicherheit auch niemand dafür verwenden.

Ein Transfernetz ist nichts ungewöhnliches, das ist richtig. Das macht auch OpenVPN so. Aber NAT dafür zu machen, auf die Idee kommt mit Sicherheit keiner. Das würde ja unmittelbar dazu führen, dass Sachen wie SMB etc. nicht mehr funktionieren. Es wird als reines Transportnetz verwendet.

Ruf einfach mal auf dem Telnet der Box ifconfig auf... Ich hatte das 169'er Netz im post eines anderen Users erst für einen Fehler gehalten. Ist es aber nicht. Die FB hat diverse interne Netze die zum Teil auf virtuellen Interfaces terminieren.

QUATSCH! Die 169.254.1.1 ist die Notfall-Adresse der Fritzbox, wenn DHCP etc. nicht mehr funktionert. Dann stellt sich ein PC nämlich automatisch eine Adresse aus dem Raum ein, und man kann noch wieder zugreifen. Hast du eigentlich je einen Blick ins Handbuch deiner Fritzbox geworfen?

Dem Tunnel / IPsec ist Multicast erstmal egal solange es sich um IP handelt.

Nicht unbedingt. Er muss spezielle Broadcast Mechanismen unterstützen, sonst kann er die Multicast Pakete nicht transportieren.

Wenn Du mal einen Blick in die ar7.cfg wirfst, siehst Du, das die Firewall die Multicast Adressen blockt - warum auch immer.

Wenn du in deinem Netz mit Multicast rumspielst, willst du wohl kaum, dass die Daten ins Internet gepustet werden, oder?

 

[CaptainDXB]

Es geht nicht über eine gute Diskussion, denn Sie führt zu besserem Verständniss

Bridge Mode / Router Mode eine Zusammenfassung:

http://www.moonblinkwifi.com/routervsbridge.cfm

Dort siehst du das wesentliche Merkmal des Router Modes: Er trennt Netze. Ergo: Router Mode funzt für dieses Szenario nicht richtig.

Vielleicht sollte ich erklären was ich mit den Ports will. Ich möchte u.a. Bonjour darüber kriegen. Das funktioniert wie NetBios - Du schickst ein UDP Packet auf die Broadcast Adresse vom Netz und bist drauf angewiesen das die anderen Rechner es sehen.

Wenn Du dir sicher bist das Deine Konfig läuft mach doch einfach mal einen Ping auf die Broadcast Adresse. Du wirst sehen - es funktioniert nicht. Ein Ping auf den Rechner geht aber schon (wenigstens vom Client zum Server).

Das AVM Firewall Packet:

http://www.ip-phone-forum.de/showthread.php?t=159802

Hier lesen wir: "Leider greifen die Regeln nur für das dsl interface.
Somit lassen sich diese also nicht auf andere Interfaces z.B. zwischen OpenVPN Tunneln (tun0, tun1,...) anwenden. Wer das benötigt, muss doch auf iptabels zurückgreifen..."

=> Sie schaffen es leider nicht.

Transfer Netze:

Tut mir leid wenn ich mich unverständlich ausgedrückt habe.

APIAP Adressen:
Kann schon sein, das eine der IP's die auch für das Recovery verwendet werden kann. Fakt ist jedenfalls das sie es als internes Netz benutzen. Wollte ich auch nicht glauben da eher ungewöhnlich. Ist aber geroutet und funktioniert.

IPsec / Tunnel:

Wenn Du auf ESP anspielst ja. Aber das macht die FB ja - ist also nicht das Problem. Außerdem krieg ich ja UDP Packete rüber. Nur eben nicht gebroadcastet und nicht auf Port 5060. Multicast auf den Multicastports geht ebenfalls nicht. Beides ist im Fall der FB kein IPsec Problem.

cu
DXB