Netzwerk für MD richtig planen

Naja, die DMZ ist ein eigenes Segment, wenn man so will. Alle Zugriffe vom LAN (internes Netz mit den Telefonen und Clients) zur pascom (in der DMZ) laufen über die Firewall.
Zugriff von der DMZ in Richtung LAN sind i.d.R. nicht erlaubt.
Die DMZ kann auch mit VLANs realisiert werden.

Die pascom hat beide NICs in der DMZ, der Unterschied hier ist nur die Nutzung derselbigen. NIC1 für die interne Kommunikation (Telefone und Clients, Webserver), NIC2 ist nur für Mobile Client konfiguriert.

NIC2 hat also Mobile Client Pairing = enabled und eine öffentliche IP als Interface DNS Name (FQDN) eingestellt (wichtig für Zertifikat / Mobile Client).

Dabei können NIC1 und NIC2 im selben Subnetz liegen, die Firewall NATtet (denglisch :upside_down_face:) die für den Mobile Client erforderlichen Ports dann auf NIC2. Ist hier im Forum mehrfach beschrieben.

Gruß,
Rapha

Ok, ich fange an es zu verstehen. Aber warum brauche ich dann an dem Server für MD zwei physische NIC’s. Eine stöpsel ich in die DMZ die aus der dritten NIC von der Firewall her kommt. Und die Zweite?

Die zweite NIC braucht man nicht, wenn aber der pascom Client (von extern via MobileHub) genutzt werden soll empfiehlt pascom dazu eine zweite Schnittstelle zu verwenden.

Gruß,
Rapha

Hi, eine DMZ ist sicherlich empfehlenswert, aber nur für die pascom eine weitere Netzwerkkarte in die Firewall einzubauen (ggf wäre ja VLAN die Alternative dazu?) ist vermutlich übertrieben. Wenn du pascom in der pascom.cloud müsstest du dir um das folgende keine Gedanken machen:
Werden neben den internen Endgeräte auch Endgeräte von extern (z.B. Mobile Client) geplant? Falls ja musst du dir um das oben einmal bereits verlinkte Hairpinning gedanken machen oder zwei Interfaces (eins für intern eins für extern) verwenden, beide dürfen auch in deinem regulären LAN angesiedelt sein.
Die Empfehlung ein eigenes Segment zu verwenden hatte zum Hintergrund das man dadurch ggf leichter Quality of Service konfigurieren kann, abseits davon gibt es hierfür keinen Grund.
Wenn die pascom dann im einzigen LAN Segment angesiedelt ist würde ich deinen (Windows?) DHCP als einzigen DHCP-Server weiterverwenden, wenn es viele Telefone sind (dann macht aber eine Segment-Aufteilung ggf wieder Sinn) kannst du dort über MAC Filter die Option 66 gezielt verteilen. Bei wenigen würde ich einfach darauf verzichten und die Provisionierungs URL manuell auf die Handvoll Telefone eintragen.

Link bezüglich Firewall (falls von extern Geräte angebundne werden sollen):
https://www.pascom.net/doc/de/howto/mobile-access/#ihre-firewall-anpassen

Grüße,
Steve

Ich dachte immer die DMZ wir an der Firewall eingerichtet bzw. dort über eine weitere NIC realisiert. Ok, dann bekommt der Pascom-Host eine zweite NIC da MobileHub dann (sobald intern alles läuft) genutzt werden soll. Dann wird der MD-Server mit einer NIC nach LAN verkabelt und wo kommt das zweite Kabel rein? Das ist mir nicht ganz klar.

Ja … Nein, das möchte ich nicht.

Im ersten Schritt sind es lediglich 4 interne Geräte (3 x Tisch / 1 x Schnurlos), alle von Snom. Im zweiten Schritt sollen dann mobile Geräte hinzu kommen und ggf. der Desktop-Client. Ich möchte eben aber gleich alles so aufsetzen dass es dann gleich passt. Ich würde dann gleich zwei NIC’s einrichten. Habe aber noch wie oben beschrieben ein kleines Verständnis-Problem.
Den Link zum Hairpinning werde ich mir noch anschauen.

Nein, ist ein Linux-DHCP und dass die MD dort hängt wäre mir eigentlich auch lieber da hier alle IP-Endgeräte zentral angelegt und verwaltet werden. Die Geräte bekommen dann anhand ihrer MAC über DHCP immer die gleiche IP.

Hi,

was @rapha sicherlich meinte ist das wenn du keine DMZ hast keine zwangsläufig benötigst (was ich persönlich auch so sehe). Eine DMZ benötigt keine physikalische NIC in der Firewall, das Konzept “DMZ” lässt sich auch virtuell abbilden. Die zweite NIC die @rapha meint war nur an der pascom gemeint (denke ich) und nicht an der Firewall, Hintergrund ist das nicht jeder mit dem “Hairpin NAT” Problem vertraut ist und man Serverzugriffe von intern und extern i.d.R. gerne über SplitDNS löst. Das Problem hierbei ist jedoch das der SBC den Endgeräten eine RTP Ziel in Form von einer IP (SIP sieht im SDP meines Wissens nach keine DNS Namen vor) benötigt. Wenn du etwas Zeit hast und es genauer verstehen willst sieh dir doch bitte den Beitrag hier an:

Meine persönliche kurz gehalte Empfehlung für dich:
-verwende deinen eigenen DHCP und trage die ProvisionierungsURL selbst bei den Telefonen ein
-verwende zwei interfaces auf der pascom aber lass deine Firewall wie sie ist
– das Management interface mit FQDN der privaten IP des Interfaces, hierüber bindest du alle deine lokalen Geräte/Clients an und diese IP darf idealerweise ungehindert in das Internet raus
– das zweite Interface bekommt ebenfalls eine statische IP im gleichen (einzigen) Netz, als FQDN trägst du hier aber deine feste öffentliche IP ein. Die unter pascom Cloud Telefonanlage Dokumentation erwähnten Ports werden dann auf dieses Interface geforwarded. Auf diesem Interface bitte das mobile client pairing aktivieren und am anderen Interface deaktivieren.

Deine Clients dürfen dann gerne einen DNS Namen verwenden um mit der pascom zu kommunizieren, wenn beide Interfaces bezüglich Verschlüsselung gleich konfiguriert sind funktionieren diese dann auch wenn intern die interne IP des ersten Interfaces aufgelöst wird und von extern die öffentliche IP.

Grüße,
Steve

ich glaube ich bin entweder zu doof oder denke zu kompliziert …

ok, versatanden. MD-Server hat zwei Netzwerkkarten. Aber physisch, oder?

Das ist die 1. NIC am MD-Server. Wird in’s LAN eingesteckt und bekommt eine IP aus dem internen LAN.

und wo stecke ich das Kabel rein?

bitte nicht falsch verstehen :wink:

ok, versatanden. MD-Server hat zwei Netzwerkkarten. Aber physisch, oder?

wenn es direkt auf Hardware installiert ist ja (VLANs lassen sich pascom Seitig nicht mehr konfigurieren), wenn du es in der virtuellen Umgebung hast dann einfach eine weitere Netzerkkarte anlegen und in das gleiche (wohl einzig vorhandene) VLAN hängen. Verstehe die Frage leider nicht.

Das ist die 1. NIC am MD-Server. Wird in’s LAN eingesteckt und bekommt eine IP aus dem internen LAN.

möglich würde aber Serversystemen eine feste IP empfehlen, auch wenn du mit DHCP Reservierungen arbeitest.

und wo stecke ich das Kabel rein?

da du wohl keine VLANs an den Switchen nutzen einfach irgendwo in den Switch, wenn es also Hardware von uns ist mit zwei Netzwerkkarten dann einfach beide gerne in den gleichen Switch. Die interfaces bei uns werden nicht gebridged, es ensteht also kein Loop :wink:

ich habe es zum einfacheren Verständnis so beschrieben als wären es physische NIC’s und Kabel was nachher leicht auf die virtuelle Umgebung mit virtueller NIC und anbinden an die Bridge (Kabel) zu übertragen ist.

Ich habe auf dem Virtualisieruns-Host die Bridge br0 was das interne LAN darstellt und auch mit der physikalischen Netzwerkkarte die im LAN hängt verbunden ist. Alle VM’s die auf’s LAN zugreifen oder von dort angesprochen werden sind an diese Bridge angestöpselt. Daneben gibt es jetzt noch die br1. Daran ist die physische NIC die mit dem Glasfaser-Anschluss verbunden angebunden sowie die 2. virtuelle NIC der Firewall (und nur dies).

VLAN’s habe ich keine eingerichtet bzw. noch nie genutzt. Der hier physikalisch verbaute Switch kann dies aber.

Wenn ich nun eine VM mit MD aufsetze bekommt diese zwei virtuelle Adapter. Den ersten verbinde ich mit der br0 und die zweite? … Die Fragestellung ist immer gleich aber irgendwie kann ich da keine Antwort raus lesen.

Oder meinst Du ich brauche entweder eine DMZ was in dem Fall eine weitere br2 wäre oder ich richte statt dessen ein VLAN am Switch ein?

Heißt für dich beide Netzwerkadapter mit br0 verbinden.

Nein, ich bin kein Beamter aber plane noch immer :slight_smile: Ich werde nun vorher den IPFire der ja als VM auf dem Server läuft gegen PFSense auf physischer Hardware einrichten. In dem Server der PFSense bekommt sind ohnehin 4 NIC’s.

Da könnte ich doch ein echtes DMZ aufspannen und MD kommt dann mit einer Schnittstelle ins LAN und mit der anderen in die DMZ. Oder wäre das nicht sinnvoll?

Hallo @pixel24,

die DMZ ist für Applikationen gedacht die von außen (als aus dem Internet) zugänglich sind, sei es Web- und Mail-Server oder die pascom.

Eigentlich sollte dann diese Applikation nicht im LAN direkt verbunden sein, ein Angreifer könnte sonst den Webserver kapern und direkt ins LAN zugreifen. Wenn der Webserver in der DMZ steht muss der Angreifer erst durch die Firewall um ins LAN zu kommen und hat nicht direkten Zugriff auf alle möglicherweise “unsicheren” Dienste im LAN.

Die pascom sollte in der DMZ stehen, die Telefone greifen nur auf die pascom zu, können also ins LAN. Das Telefon bekommt eine IP-Adresse aus dem LAN und nutzt das Gateway/pfsense um auf die pascom zuzugreifen.

Bei uns haben wir ein separates VLAN für die DMZ, die pfsense selbst ist ebenfalls virtualisiert, muss also nicht bare metal sein. Der Internetzugang hat natürlich ein eigenes VLAN und ist nur mit der pfsense verbunden.

Edit: Skizze Netzwerkplanung

Gruß,
Rapha

dann ist es wohl tatsächlich besser die PFSense wie (im Moment den IPFire) als VM laufen zu lassen und mit VLAN’s zu arbeiten. Ich dachte nur bzw. meinte gehört zu haben dass man die Firewall besser auf physische Hardware bannt. Ich richte mal eine Testumgebung ein und installiere :slight_smile:

Also wenn sich deine Switchports auf “Access / Edge” einstellen lassen sollte es nicht möglich sein aus dem VLAN auszubrechen, wie es bei einem eigenen Kabel sein sollte.

Gruß,
Rapha

jetzt bin ich wieder verwirrt. Wenn doch alle beteiligten Systeme als VM laufen sind die VLAN’s doch auch virtuell d.h. am Virtulisierungs-Host geht: Bridge “LAN” → NIC → Switch und hier hängen alle internen Geräte dran. Auf dem physichen Switch brauche ich doch kein VLAN mehr?

Wenn es dedizierte NICs für Internet/WAN und LAN sind brauchst du keine VLANs.

Oft werden die Virtualisierungshosts mit Trunk-Ports am Netzwerk betrieben (Redundanz usw.), das WAN ist in diesem Fall in einem VLAN, genau wie LAN und andere Netze.

Gruß,
Rapha

Ich muss nochmal nerven. Hat doch noch etwas gedauert, habe mich erst mal so weit wie möglich in VLAN und DMZ eingelesen. Daneben habe ich nun den Virtualisierungs-Host durch Proxmox erstetzt und als Firewall PFSense als VM eingerichtet.

Den Artikel:

habe ich auch gelesen und das Problem auch verstanden :slight_smile: … hoffe ich.

Ich denke VLAN und DMZ lass ich erst mal raus um es einfacher zu halten.
Mein internen Netz hat ja 192.168.24.0/24, am Virtualisierungs-Host gibt es die Bridge br0 welche physisch mit dem LAN verbunden ist und alle VM’s die LAN-Zugriff brauchen sind an diese Bridge angebunden. Soweit, so unspannend.

Den MD installiere ich jetzt mit zwei virtuellen NIC’s die beide an die br0 kommen und konfiguriere diese wie im Artikel beschreiben mit zwei festen (unterschiedlichen) IP’s und gleichem Default-GW.

Noch eine Frage zum externen Zugriff bzw. dem beschriebenen Port-Forwarding. Muss allerdings etwas “ausholen” und hat im ersten Teil nichts mit MD zu tun … Damit ich unterschiedliche Server im LAN (Groupware, Cloud …) unter gleichem Port erreichen und dies mit vertrauenswürdigen Zertifikaten habe ich auf dem PFSense ACME (für LetsEncrypt) und den HA-Proxy eingerichtet. Was auch tadellos funktioniert.
Kann ich diesen genauso für MD nutzen wie bei den anderen Diensten? Also ich setze beim Hoster meiner Domain (All-Inkl) einen A-Record:

md.mydomain.de → 10.20.30.40

wobei 10.20.30.40 die feste WAN-IP des PFSense ist und leite am HA-Proxy dann alles was md.mydomain.de aufruft an die zweite (für Mobilzugriff definierte) NIC am MD weiter.

Würde das so passen?

Viele Grüße
Sven

Hallo Sven,

Ja das sollte so gehen wobei du den HA Proxy ja nur für Port 80 benötigst (acme).

Alle anderen Ports 5222/tcp, 30000-35000/udp, 8884/tcp solltest du aus meiner Sicht per DNAT machen.
Das Webfrontend der Pascom (443) aber auf jedenfall das Management (8443) sollte du auf keinen Fall von extern erreichbar machen

Gruß Markus

Ja, ACME auf der PFSense macht die ACME-Challange und legt den ACME-Token auf einem Webserver hinter der Firewall (LAN) am. Der HA-Proxy regelt das die LE-CA von extern auf diesen HTTP-Server zugreifen kann um den Token zu prüfen. da funktioniert ja bereits alles.

Ja, da hatte ich noch einen kleinen Denkfehler. Diese Ports werden nicht vom HA-Proxy behandelt sondern einfach per Port-Forwarding auf die MD-VM geleitet. Der Proxy kann ohnehin kein ankommendes UDP handeln (soweit ich weiß)

Ja, diese kann ich von extern erreichen indem ich vorher eine VPN-Verbindung aufbaue.

Meine DM hat ja nun 2 virtuelle NIC’s die beide an der br0 (LANG hängen).

Die erste für die Kommunikation im LAN (192.168.24.8) die zweite für den Mobil-Zugriff (192.168.24.9).

Die Ports Ports 5222/tcp, 30000-35000/udp, 8884/tcp leite ich auf die 192.168.24.9, richtig?