voip H.323 über VPN - Tunnel- oder Anlagen-Problem?

achim · Beitrag von **achim** » Mo 18.04.2011, 15:51

Wir haben 2 Firmenstandorte mit 2 Securepoints per S-t-S verbunden.

In einem Standort steht eine Siemens HiPath-Anlage und im anderen Standort stehen einige VOIP-Telefone...

funktioniert eigentlich ganz gut, bis auf die Logmeldungen:
Apr 18 23:36:53 a.b.c.d Unknown kernel: nf_ct_h323: incomplete TPKT (fragmented?)
und die Problematik, dass "Rückfragen"/Konferrenzen and em Standort mit den Voip-Telefonen nicht funktionieren.

Im moment schaffen wir es nicht die Fehlerquelle zu identifizieren (Securepoints, VPN, TK, Telefon-Firmware...)

Auf den Firewalls sind IDS und VOIP-Proxy deaktiviert.

Fragen:
Ist die Fehlermeldung relevant? oder sind dies Pakete, die fälschlicher Weise als H.323 interpretiert werden (gibt es ja einige Posts im netfiler-bereich)?
Hat sonst jemand bereits ähnliche Probleme gehabt/lösen können?

Ich tippe ja eher auf die TK/Telefone und meine Fehlertendenz wäre die MTU...

gruß
achim

Beitrag von **Erik** » Mo 18.04.2011, 17:07

Das Problem ist da die Kompatibilität (oder besser gesagt: das Fehlen ebendieser) zwischen HiPath-Anlage und H323-Modul des Netfilters auf der Firewall.

Unter der Vorraussetzung, dass die Verbindung nicht genattet wird (ich gehe davon aus, weil VPN) und dass eine *-stateless-Regel für die Telefone angelegt ist, können Sie testweise mal das entsprechende Kernel-Modul entfernen.
Dazu auf der root-Konsole eingeben:

Code: Alles auswählen

modprobe -r nf_nat_h323 && modprobe -r nf_conntrack_h323

achim · Beitrag von **achim** » Mo 18.04.2011, 18:31

Erik hat geschrieben: eine *-stateless-Regel für die Telefone angelegt ist,

Kann ich das noch erläutert haben?
stateful inspection und auch von mir aus stateless inspection kann ich ja noch einordnen, aber als Regel (Beispiel bitte)...

(kein nat, da vpn)

Danke
Achim

Beitrag von **Erik** » Mo 18.04.2011, 18:35

Wenn Sie einen Dienst anlegen der "irgendwas-stateless" heisst, wird für Firewallregeln, die diesen Dienst beinhalten die Stateful Packet Inspection deaktiviert. Ich hoffe das reicht, damit das Paket als ganz normales UDP-Paket behandelt wird.

achim · Beitrag von **achim** » Do 21.04.2011, 16:23

Ich habe nun einmal die Dienste angelegt und den modprobe-befehl ausgeführt, leider noch nicht mit vollem Erfolg...

durch den modprobe-befehl erscheinen keine "Unknown kernel: nf_ct_h323: incomplete TPKT (fragmented?)"-Meldungen mehr.
Wie mache ich diesen permanent? (also nach neustart der Firewall)

Dienste auf beiden Firewalls (beide v10.5.1):

voip1-stateless port 1720 tcp
voip2-stateless port 4060 tcp
voip1-stateless port 5060 udp
voip1-stateless port 5004 udp
voip1-stateless port 5005 udp
voip1-stateless port 5006 udp
-> mitglied in dienste-gruppe grp-voip

Regeln auf der Firewall mit den telefonen:
grp-lan-phones -> remote-telefonanlage -> grp-voip
remote-telefonanlage -> grp-lan-phones -> grp-voip

Regeln auf der Firewall mit der TK:
grp-remote-phones -> telefonanlage -> grp-voip
telefonanlage -> grp-remote-phones -> grp-voip

Bei Konferrenz-Schaltung bzw. Rückruf-Funktion werden folgende Pakete geloggt:

Apr 21 15:58:39 remote-ip Firewall ACCEPT kernel: ACCEPT(rule:16) IN=eth1 OUT=ppp0 SRC=192.168.x.144 DST=192.168.y.181 LEN=60 TOS=0x08 PREC=0x60 TTL=63 ID=38528 PROTO=TCP SPT=1317 DPT=1720 WINDOW=8192 RES=0x00 SYN URGP=0
Apr 21 15:58:40 remote-ip Firewall ACCEPT kernel: ACCEPT(rule:14) IN=ppp0 OUT=eth1 SRC=192.168.y.181 DST=192.168.x.144 LEN=280 TOS=0x18 PREC=0xA0 TTL=124 ID=63110 PROTO=UDP SPT=29104 DPT=5006 LEN=260 MARK=0x1

Apr 21 15:58:38 tk-ip Firewall ACCEPT kernel: ACCEPT(rule:9) IN=eth0 OUT=eth1 SRC=192.168.x.144 DST=192.168.y.181 LEN=60 TOS=0x08 PREC=0x60 TTL=62 ID=38528 PROTO=TCP SPT=1317 DPT=1720 WINDOW=8192 RES=0x00 SYN URGP=0 MARK=0x1
Apr 21 15:58:40 tk-ip Firewall ACCEPT kernel: ACCEPT(rule:12) IN=eth1 OUT=eth0 SRC=192.168.y.181 DST=192.168.x.144 LEN=280 TOS=0x18 PREC=0xA0 TTL=125 ID=63110 PROTO=UDP SPT=29104 DPT=5006 LEN=260

Also die Ports 1720 tcp und 5006 udp...

Die Regeln stehen jeweils ganz oben im Regelwerk und NAT ist natürlich deaktiviert.

Habe ich noch einen Konfigurationsfehler gemacht? Oder müsste nun firewalltechnisch alles OK sein?

Danke
Achim

Beitrag von **Erik** » Fr 29.04.2011, 12:02

Ups... Vielleicht sollte ich auch im Urlaub mal das Forum aufsuchen

Sie schreiben, dass sie teilweisen Erfolg haben, aber nicht, wo denn nun das verbliebene Problem ist. ACCEPT-Meldungen sind in dem Fall ja dann nichts schlechtes.

Das Kernel-Modul beim reboot direkt zu entladen erfordert die Anpassung eines init-Skripts. Aber welches, weiß ich jetzt nicht aus dem Kopf. Ich bin Montag wieder in Firma, dann such ich das mal raus.

Beitrag von **Erik** » Mo 02.05.2011, 10:39

Editieren Sie die Datei /sbin/init.d/rc ("mount / -o remount,rw" -> WinSCP -> runterkopieren -> anpassen -> hochladen) und schreiben ans Ende die modprobe-Zeile von oben.
Der untere Teil sieht dann so aus:

Code: Alles auswählen

	echo "switching to /tmp"
	cd /tmp
	mkdir clients
	echo "start server"
	/bin/server
	modprobe -r nf_nat_h323 && modprobe -r nf_conntrack_h323
	echo "bye"
fi

HINWEIS:
Wenn die Datei irgendwie fehlerhaft ist (Windows-Linebreaks, Irgendwelche Steuerzeichen drin) wird die Firewall nicht mehr hochfahren. Da kann Ihnen dann auch niemand am Telefon helfen

Also am besten einen (funktionierenden) USB-Stick mit einem Update-Image bereithalten.

achim · Beitrag von **achim** » Mo 02.05.2011, 10:46

Der teilweise erfolg war, dass bei einem Rückruf bzw. einer Konferrenz nun wenigstens das Telefon das eingeladenen klingelte...
... beim Annehmen des Gesprächs ist die Verbindung dann trotzdem komplett weg.

Das Verhalten lässt sich übrigens auch auf unsere eigene Firewall mit einem Tunnel mit einer Fritzbox nachstellen.
VOIP-Telefon am Fritzboxstandort kann keine Konferrenzen/Rückrufe über die Telefonanlage am Securepoint-Standort einleiten.

Analyse/Tests werden noch etwas dauern...

achim · Beitrag von **achim** » Mi 04.05.2011, 14:56

OK - neuer Status:

Die Lösungsvariante funktioniert (doch):

1. Dienste anlegen:
voip1-stateless port 1720 tcp
voip2-stateless port 4060 tcp
voip3-stateless port 5060 udp
voip4-stateless port 5004 udp
voip5-stateless port 5005 udp
voip6-stateless port 5006 udp
-> neue Dienstegruppe
2. Regeln auf beiden Firewalls
3. per putty (root): modprobe -r nf_nat_h323 && modprobe -r nf_conntrack_h323

alles bestens danach.

Aber da fast jeder unserer Securepointkunden auch eine Hipath-Anlage besitzt, VOIP vermehrt eingesetzt wird und die Außenstellen teilweise mehrere 100 Kilometer entfernt sind - sprich nicht immer jemand mit einem Notfallstick vor Ort sein kann:

Featurequest:
Bitte entweder "modprobe -r nf_nat_h323 && modprobe -r nf_conntrack_h323" irgendwie per "Haken" abschalten können, oder Problem anderweitig beheben.

Danke
nochmal