Fritzbox mit VoIP hinter pfSense-Router

[rMarkus]

Hallo,

ich möchte wieder meine Fritzbox hinter einem FreeBSD-Router (WRAP mit pfSense) betreiben.

Bis vor einiger Zeit hatte ich das mmal funktionstüchtig mit FreeBSD und ein paar UDP-Portforwards zum Laufen gebracht.

Seit dem nun wieder pfSense mit gleichem in der Oberfläche "zusammengeklicktem" Regelwerk in Betrieb habe, kann sich die Fritzbox nicht mehr bei dem VoIP-Dienst von GMX (sipbalance0.schlund.de) verbinden.

Seltsamer Weise funktioniert mein zweiter Account iptel.org sogar ohne Portforward sofort, während der GMX-Account selbst nach einem brutalen Portforward von Port 1024 bis 65535 (UDP) nicht funktioniert.

Was kann man da machen?

 

[rMarkus]

Seltsam:

Gestern habe ich die Firewalldistribution von pfSense auf M0n0wall getauscht und schon kann sich die Fritzbox registrieren bei GMX.

Nach den folgenden Portforwards wie in der Anleitung von GMX scheint man sogar telefonieren zu können:

UDP Port: 5070 - 5079
UDP Port: 30000 - 30019

Der Unterschied zwichen pfSense und M0n0wall ist doch nur FreeBSD 6.1 vs. FreeBSD 4.11 und pf vs. ipfw.

Die ganze Sache ist etwas wunderlich, kann sich Jemand das erklären?

 

[Hubert]

Also, es gibt auf jeden Fall ein typisches Problem im Zusammenhang mit pf + N:1-Source-NAT + VoIP: pf übersetzt neben der Source-IP immer auch den Source-Port (und zwar wird ein zufälliger Port gewählt). Das macht VoIP kaputt. Auch bei Verwendung eines STUN-Servers bekommt der STUN-Server eine falsche Information. Das Problem läßt sich beheben, indem die Option "static-port" bei der entsprechenden NAT-Regel verwendet wird.

Nebenbemerkung 1: Andere NAT-Lösungen ändern im Fall N:1-Source-NAT den Source-Port standardmäßig nicht, sondern nur im Kollisionsfall, wenn also das Trippel ursprünglich Ziel-IP, ursprünglicher Ziel-Port und übersetzte Source-IP nicht eindeutig wäre.

Nebenbemerkung 2: Portforwarding ist bei VoIP im Prinzip nicht notwendig, solange die Clients/Geräte ihre Mappings offen halten. Da muss man dann höchstens die Keep-Alive-Intervalle der Clients/Geräte und die Idle-Timeouts der NAT-Mappings anpassen.

 

[rMarkus]

Hubert: Danke für die gute Erklärung.

Im Betrieb mit ipfw stellte sich heraus, dass ich über GMX-VoIP nicht angerufen werden kann.

Folgendes steht im Log von IPfw:

#
Jul 22 15:12:42 heimdall ipmon[83]: 15:12:42.325752 ng0 @0:17 b 212.227.15.197 -> 192.168.32.8 PR udp len 20 (753) (frag 39199:733@744) IN
#
Jul 22 15:12:43 heimdall ipmon[83]: 15:12:43.150857 ng0 @0:17 b 212.227.15.197 -> 192.168.32.8 PR udp len 20 (753) (frag 39200:733@744) IN
#
Jul 22 15:12:45 heimdall ipmon[83]: 15:12:45.171098 ng0 @0:17 b 212.227.15.197 -> 192.168.32.8 PR udp len 20 (753) (frag 39201:733@744) IN
#
Jul 22 15:12:49 heimdall ipmon[83]: 15:12:49.210997 ng0 @0:17 b 212.227.15.197 -> 192.168.32.8 PR udp len 20 (753) (frag 39202:733@744) IN
#
Jul 22 15:12:53 heimdall ipmon[83]: 15:12:53.260309 ng0 @0:17 b 212.227.15.197 -> 192.168.32.8 PR udp len 20 (753) (frag 39203:733@744) IN
#
Jul 22 15:13:11 heimdall ipmon[83]: 15:13:11.094785 ng0 @0:17 b 144.133.12.43,30291 -> 80.132.160.206,1026 PR udp len 20 401 IN

80.132.160.206 -> Meine Internet-IP
192.168.32.8 -> Interne IP der Fritzbox
77.83.207.224 -> IP des Anrufers
197.15.227.212 -> sipbalance0.schlund.de -> SIP-Server

Wo liegt der Fehler?
Danke

PS: Rufe ich zuest die Gegenstelle an, dann kann der mich auch zurückrufen.