Offene NAT-Ports nur für best. ext. IP Range - Denkfehler

[p0ddie]

Hi,

ich hatte das gleiche Anliegen schon mal und habe es damals auch durch die tolle Hilfe hier im Forum gelöst bekommen, stehe allerdings jetzt schon wieder auf dem Schlauch und habe keinen Zugriff mehr auf die Config-Datei, mit der ich das gelöst habe.

Sachverhalt ist folgender:

Kunde hat Sipgate Team und 8 Telefone. Dynamisches NAT hinter dem Lancom funktioniert nicht mit Sipgate Team, gewisse Telefonanlagenfunktionen gehen einfach nicht, also muss für jedes Telefon ein SIP- und ein RTP-Port geforwarded werden. Telefon 1 hat SIP Port 5060 und RTP 5004-5020, Telefon 2 hat SIP 5160 und RTP 5104-5120 usw. Inb4 eine lokale VoIP Anlage wäre besser, aber ich muss mit dem arbeiten, was ich habe.

Ich will eine Firewallregel erstellen, die den Zugriff auf die geforwardeten Ports von außen nur von der IP Range des VoIP Providers gestattet. Damit sind die Ports dann zwar offen, die Firewall blockt aber den Zugriff aus China und Kuba vor den H4xX0Rn.

Hier sind die Screenshots von meiner Konfiguration, die nicht funktioniert: Mit externem NMAP Scan wird mir gesagt, dass die Ports noch open or filtered seien (obwohl "reject" ausgewählt ist), gleichzeitig ist aber der Zugriff von innen nach außen auf manche Seiten nicht mehr möglich. Irgendwo habe ich einen Denkfehler und komme nicht drauf.

Ich habe zunächst eine Regel erstellt, die sämtlichen SIP Traffic dropt:










Und dann eine Regel, die den Traffic an Sipgate erlaubt:









Wo hakt's? Vielen Dank!

[backslash]

Hi p0ddie,

auf den ersten Blick würde ich sagen, daß du dich mit den Richtungen der Regeln vertan hast...

1. Die Telefone sollen intern die gegebenen Ports nutzen - dann müssen die Ports in die Quelle, damit von den Telefonen aus der Zugriff "nach aussen" möglich ist.
2. in der Regel, die die Zugriffe aus dem Sipgate-Netz zulassen soll, müssen die IP-Adressen in die Quelle, die Ports abet tatsächlich ins Ziel, damit SIPgate auf die Telefone zugrifen kann,

also

Code: Alles auswählen

DENY_ALL:
aktion:  zurückweisen
Quelle:  alle Stationen
Quelle:  alle Stationen
Dienste: alle Dienste

ALLOW-TELEFONE->SIPGATE:
aktion:  übertragen
Quelle:  IPs der Telefone
Quelle:  alle Stationen
Dienste: UDP, Quell(!)Ports: 5004-5020, 5061, 5104-5120...

ALLOW-SIPGATE->TELEFONE:
aktion:  übertragen
Quelle:  Sipgate-IPs
Quelle:  IPs der Telefone
Dienste: UDP, Ziel(!)Ports: 5060, 5160, 5260...

In der Regel ALLOW-SIPGATE->TELEFONE müssen tatsächlich nur die Signalisierungs-Ports (5060, 5160, 5260,...) stehen, weil die Telefone die RTP-Ports von sich aus öffnen, sobald sie angerufen werden. Im Portforwarding müssen natürlich alle Ports stehen

Mit externem NMAP Scan wird mir gesagt, dass die Ports noch open or filtered seien (obwohl "reject" ausgewählt ist),

Vorsicht... Der Default in der Firefiwall für Portscans (IDS) ist "drop", d.h.: sobald ide Firewall einen Portscan erkennt, werden die Pakete einfach weggeworfen und ein Portscanner sagt bei UDP der Port sei "open"...

Gruß
Backslash

[p0ddie]

Hi backslash,

vielen dank für deine Antwort, ich glaube ich verstehe:

Also die deny all: alle Stationen an alle Stationen und:



dann eine Regel ALLOW-TELEFONE-SIPGATE:



und




und eine insgesamt dritte Regel ALLOW-SIPGATE-TELEFONE:



und





So richtig?

[backslash]

Hi p0ddie,

ja... nur kannst du dir bei einer DENY-ALL-Regel die Regel DROP-ALL-SIP sparen.

Wenn du die DROP-ALL-SIP-Regel explizit haben willst, dann mußt du sie umdrehen... Denn du willst ja eingehenden Traffic an die Telefone blocken. Somit entspricht die DROP-ALL-SIP der ALLOW-SIPGATE-TELEFONE mit zwei Unterschieden:
1. die Quelle ist "alle Stationen" statt "SIPGATE_IPRANGE" und
2. die Aktion ist "zurückweisen" statt "übertragen"

Gruß
Backslash

[p0ddie]

Vielen Dank, alles funktioniert!