Best Practise - DHCP-WAN und Public IP



  • Hallo aus Wien!

    Ich habe suche eine Best-Practise Lösung wie man folgende Topologie (siehe Diagramm im Attachment) am besten umsetzt:

    Topologiebeschreibung:

    Vom ISP bekommt das Cable Modem und in weiterer Folge der NIC1 (WAN) per DHCP IP-Adressen zugewiesen.

    Auf diese per DHCP vergebenen Adressen mappt/routet der ISP zwei Public IP Adresspakete/-pools (200.x.x.A/20 und 200.x.x.B/29 – je 4 verwendbare IP-Adressen)

    Die Konfiguration möchte ich unabhängig von einem etwaigen IP-Wechsel des ISP machen und eine der Adressen aus den zugewiesenen Pools als Ausgangsadresse für LAN, DMZ und WAN nutzen.
    (Zumal die aktuell zugewiesene IP mittlerweile wegen eines Trojaners blacklisted wurde gggrrrr - denn ist alles richtig eingestellt könnte man mittels Alias-Zuweisung sehr leicht eine Umkonfiguration auf eine andere IP erreichen))

    Betriebene Dienste:

    In der DMZ sollen einige Webserver und zumindest ein Mailserver betrieben werden. Die Server liegen zum Teil physisch und zum Teil als Instanzen einer VMWare Esxi vor.

    Die Netze sollen per snort (package in pfSense oder bessere Lösung) überwacht werden (alle externen und alle internen Netze, also WAN, LAN und WLAN)

    OpenVPN als VPN-Lösung (package in pfSense) - als IP nicht die per DHCP zugewiesene WAN-IP sondern die IP,m die als ausgehende IP aus einem der Pools gewählt wurde.

    Weitere Dienste:  NAS(wohl lieber per VPN), Owncloud, SVN-Server(wohl auch lieber per VPN)

    als NiceToHave: Drucker, VOIP-Lösung(asterisk o. ähnliches), Medienserver

    • evtl können die einzelnen Dienste auch als kleine, schlanke VMWare Instanzen realisiert werden, die nur intern Zugriff auf das NAS haben, um das NAS besser zu schützen und nur als Storage zu nutzen.

    Schutz und Moonitoring:

    Die in der DMZ angebotenen Dienste möchte ich entsprechend schützen – z.B. sollte der Zugang zu einem Webserver nur die nötigen Ports zulassen bzw auch intern auf andere untypische Ports forwarden um die Sicherheit zu erhöhen.

    Schwerpunkt soll auch das Monitoring und der Schutz der internen Netze sein, mittlerweile bin ich etwas vorsichtig, denn der Trojaner hat einiges an Schaden angerichtet.

    Deswegen ist vielleicht auch wichtig in welches Netz das NAS soll.

    Frage nach den richtigen Konzepten:
    z.B. ob man in der DMZ die Public IPs (aus den zugewiesenen Adressen-Pools 200.x.x.A, 200.x.x.B) direkt den entsprechenden Servern zuweist oder ob man sie per NAT auf ein internes Netz (z.B. 192.168.2.x) weiterleitet?
    Ist 1:1NAT für Mailserver nötig? (z.B. wegen des korrekten MX-Records?)
    Oder reicht es, Virtuelle IPs zu definieren (bei ganzen 8 Stk ist das ja noch machbar)

    Bitte um Hilfe bei der Konzeption, beim Finetuning und letztlich sicher auch bei der Implementation, denn auch wenn ich mittlerweile etliches durchgeackert habe, fühle ich mich immer noch ziemlich blank :-(
    Im Gegenzug beschreibe ich dann gerne die Lösung für die weitere Verwendung hier im Forum.

    LG
    CharlyTango



  • LAYER 8 Moderator

    Hallo erstmal :)

    Ich weiß zwar nicht, ob man das als best practice beschreiben würde, aber ich gebe gern mal meinen Senf dazu.

    Vom ISP bekommt das Cable Modem und in weiterer Folge der NIC1 (WAN) per DHCP IP-Adressen zugewiesen.

    Da muss ich gleich mal einhaken: Meines Kenntnisstandes ist es nicht möglich, dass ein Interface bei einer DHCP Abfrage mehrere Adressen zugewiesen bekommt. Das würde nur über weitere virtuelle oder physikalische Adressen laufen und das halte ich für unwahrscheinlich, so wie ich deine weiteren Beschreibungen lese.

    Auf diese per DHCP vergebenen Adressen mappt/routet der ISP zwei Public IP Adresspakete/-pools (200.x.x.A/20 und 200.x.x.B/29 – je 4 verwendbare IP-Adressen)

    Ich gehe beim ersten Pool mal von einem /29 aus - sonst wärst du reich ;) Aber ich finde es etwas ungewöhnlich, dass ein Provider einerseits die Adresse des Anschlusses per DHCP vergibt und dann 2 /29er Netze dort hin routet. Wie kam es dazu? Sind das ggf.  IPv4 PI (provider independent) Adressen die du gerade über den Provider routen lässt? Ansonsten ist das für den Provider einfach ungewöhnlich, denn der müsste bei jeder IP Änderung (auch wenn die nicht oft passieren bspw. bei Kabelmodems) ja das Routing (und ggf. BGP) Target ändern.

    Du solltest dann eigentlich auch mitgeteilt bekommen haben, was für die beiden IP Netze dein Gateway ist oder ob es der gleiche wie bei deiner normalen IP ist. Auch deswegen überrascht mich das Setup, denn dann würden sich für die IP Netze ja häufiger mal die Gateways ändern. Sehr merkwürdig.

    In der DMZ sollen einige Webserver und zumindest ein Mailserver betrieben werden. Die Server liegen zum Teil physisch und zum Teil als Instanzen einer VMWare Esxi vor.

    Das sollte kein Problem darstellen

    Die Netze sollen per snort (package in pfSense oder bessere Lösung) überwacht werden (alle externen und alle internen Netze, also WAN, LAN und WLAN)

    Snort auf LAN und WLAN? Sehe ich evtl bei viel "Fremdverkehr" im WLAN ggf. noch ein, aber LAN sollte schon der vertraute Bereich sein. Wenn ich meinem eigenen Netz nicht mehr vertraue, kann ich auch einpacken ;) Zudem sehe ich Snort eher als Monitor, weniger als Überwachung und Abwehr.

    OpenVPN als VPN-Lösung (package in pfSense) - als IP nicht die per DHCP zugewiesene WAN-IP sondern die IP,m die als ausgehende IP aus einem der Pools gewählt wurde.

    Das könnte sich ggf. als schwieriger herausstellen. Ich habe mir da die Version von 2.1 noch nicht angesehen, aber bei 2.0 war es m.W. nicht ohne weiteres möglich, die Interface Adresse frei zu wählen.

    Weitere Dienste:  NAS (wohl lieber per VPN), Owncloud, SVN-Server (wohl auch lieber per VPN)

    Aber hoffentlich in der DMZ und nichts davon auf der pfSense?
    Ansonsten würde ich alle 3 Dienste lieber per VPN only handhaben.

    Die in der DMZ angebotenen Dienste möchte ich entsprechend schützen – z.B. sollte der Zugang zu einem Webserver nur die nötigen Ports zulassen bzw auch intern auf andere untypische Ports forwarden um die Sicherheit zu erhöhen.

    Schutz ist gut. Unfug nicht ;) Um einen Satz einzuwerfen: "Security through obscurity is no security at all. Only pain." Ports sind Ports. Ob du die jetzt auf andere Ports weiterleitest (warum auch immer) oder nicht - ist ein Port offen kann er genutzt werden. Oder mißbraucht. Ich hatte diese Woche erst einen Kunden, der mir erzählen wollte, ich möge doch SSH für das Internet aufmachen, aber eben auf einem anderen Port, dann müsste man das ja nicht durchs VPN machen, weil das wäre ja blöde wegen Overhead und doppelter Verschlüsselung und so'n Kram. Wenn man so etwas liest, möchte man gepflegt in die Tischplatte beißen. ;)

    Es macht absolut Sinn die offenen Ports auf die zu beschränken, die absolut notwendig sind. Also bspw. HTTP/S, SMTP o.ä. - alles weitere würde ich auch nur per VPN oder aus dem LAN zugänglich machen. Und das wars. Irgendwelche Ports zu verbiegen ist kein Schutz, sondern hält 5,8 Sekunden, bis der Portscan auf die IP durchgelaufen ist ;)

    Schwerpunkt soll auch das Monitoring und der Schutz der internen Netze sein, mittlerweile bin ich etwas vorsichtig, denn der Trojaner hat einiges an Schaden angerichtet.

    Und wie soll das realisiert werden? Internes "Monitoring"? Wie kam denn der Trojaner rein, dass er so großen Schaden angerichtet hat? Hätte sich was geändert mit den Maßnahmen die du jetzt implementieren willst? Ansonsten bringt es vllt gar nichts?

    Deswegen ist vielleicht auch wichtig in welches Netz das NAS soll.

    Was heißt? In die DMZ oder intern?

    z.B. ob man in der DMZ die Public IPs (aus den zugewiesenen Adressen-Pools 200.x.x.A, 200.x.x.B) direkt den entsprechenden Servern zuweist oder ob man sie per NAT auf ein internes Netz (z.B. 192.168.2.x) weiterleitet? Ist 1:1NAT für Mailserver nötig? (z.B. wegen des korrekten MX-Records?) Oder reicht es, Virtuelle IPs zu definieren (bei ganzen 8 Stk ist das ja noch machbar)

    Kann man, auch eine Möglichkeit mit 1:1 NAT, nein, ja :D

    Ja, man kann natürlich die gerouteten Adressen nutzen und weiterreichen. Allerdings bei nur 4 Adressen pro Netz glaube ich nicht, dass du eine davon vergeuden willst für das Gateway wenn du die Adressen routest. Deshalb würde ich mir das sparen und die Adressen als VIPs direkt auf dem WAN abgreifen und dann per 1:1 NAT direkt in die DMZ hineinmappen. Über die abgehende NAT von DMZ und LAN kannst du dann auch bestimmen, mit welcher Adresse die Netze/Server/Clients nach draußen auftreten. Beim Mailserver würde man ganz normal in der DNS Zone die externe IP eingeben, die auf die interne Adresse gemappt wird.

    Ich hoffe das hilft im ersten Gang mal weiter.

    Grüße!



  • Hallo!
    danke f die Antwort - mal sehen ob ich mit dem quotedingsbums hier zurechtkomme ggg

    @JeGr:

    Hallo erstmal :)

    Ich weiß zwar nicht, ob man das als best practice beschreiben würde, aber ich gebe gern mal meinen Senf dazu.

    Vom ISP bekommt das Cable Modem und in weiterer Folge der NIC1 (WAN) per DHCP IP-Adressen zugewiesen.

    Da muss ich gleich mal einhaken: Meines Kenntnisstandes ist es nicht möglich, dass ein Interface bei einer DHCP Abfrage mehrere Adressen zugewiesen bekommt. Das würde nur über weitere virtuelle oder physikalische Adressen laufen und das halte ich für unwahrscheinlich, so wie ich deine weiteren Beschreibungen lese.

    Auf diese per DHCP vergebenen Adressen mappt/routet der ISP zwei Public IP Adresspakete/-pools (200.x.x.A/20 und 200.x.x.B/29 – je 4 verwendbare IP-Adressen)

    Ich gehe beim ersten Pool mal von einem /29 aus - sonst wärst du reich ;) Aber ich finde es etwas ungewöhnlich, dass ein Provider einerseits die Adresse des Anschlusses per DHCP vergibt und dann 2 /29er Netze dort hin routet. Wie kam es dazu? Sind das ggf.  IPv4 PI (provider independent) Adressen die du gerade über den Provider routen lässt? Ansonsten ist das für den Provider einfach ungewöhnlich, denn der müsste bei jeder IP Änderung (auch wenn die nicht oft passieren bspw. bei Kabelmodems) ja das Routing (und ggf. BGP) Target ändern.

    Du solltest dann eigentlich auch mitgeteilt bekommen haben, was für die beiden IP Netze dein Gateway ist oder ob es der gleiche wie bei deiner normalen IP ist. Auch deswegen überrascht mich das Setup, denn dann würden sich für die IP Netze ja häufiger mal die Gateways ändern. Sehr merkwürdig.

    Alle Kabelmodems des ISP (=upc) erhalten per DHCP ihre IPs - das ist deren Standardfall. Diese IPs sind quasi semipermanent, denn sie ändern sich im wesentlichen nur bei Modemtausch. Ich habe beim ISP bloss zwei "IP-Pakete" bestellt und bekam sie auch zugewiesen. Jedes dieser Pakete hat ein eigenes Gateway - z.B. 200.x.x.26-30 verwendbar  Gateway: 200.x.x.25  Netmask 255.255.255.248
    Diese IP-Paket werden vom ISP in deren Verwaltung manuell gemappet, geroutet oder geirgendwast, was bei IP-Wechsel des kabelmodems gerne auch mal vergessen wird und dann steht der Karren.

    Die Netze sollen per snort (package in pfSense oder bessere Lösung) überwacht werden (alle externen und alle internen Netze, also WAN, LAN und WLAN)

    Snort auf LAN und WLAN? Sehe ich evtl bei viel "Fremdverkehr" im WLAN ggf. noch ein, aber LAN sollte schon der vertraute Bereich sein. Wenn ich meinem eigenen Netz nicht mehr vertraue, kann ich auch einpacken ;) Zudem sehe ich Snort eher als Monitor, weniger als Überwachung und Abwehr.

    scheinbar habe ich mir einen Trojaner auf meinem NAS (Xubuntu) eingefangen, wobei ich mir nicht vorstellen kann wie das passiert sein soll. Möglicherweise wurde meine IP-Adresse auch gespooft. Jedenfalls bekam ich vom ISP etliche abuse-mails weitergeleitet. Meine Trojaner-Jags blieb bislang erfolglos, bleibt nur - aus reinen Sicherheitsgründen - das NAS neu aufzusetzen, freu mich tierisch.

    Monitoring im LAN könnte zumindest den Rechner identifizieren, der betroffen ist und aus der reihe tanzt.

    Jedenfalls bin ich einfach sensibilisiert und träume von einem passenden Monitoring oder einem widerstandsfähigeren Layout. Vorschläge ?

    OpenVPN als VPN-Lösung (package in pfSense) - als IP nicht die per DHCP zugewiesene WAN-IP sondern die IP,m die als ausgehende IP aus einem der Pools gewählt wurde.

    Das könnte sich ggf. als schwieriger herausstellen. Ich habe mir da die Version von 2.1 noch nicht angesehen, aber bei 2.0 war es m.W. nicht ohne weiteres möglich, die Interface Adresse frei zu wählen.

    Weitere Dienste:  NAS (wohl lieber per VPN), Owncloud, SVN-Server (wohl auch lieber per VPN)

    Aber hoffentlich in der DMZ und nichts davon auf der pfSense?
    Ansonsten würde ich alle 3 Dienste lieber per VPN only handhaben.

    Die pfSense würde ich gerne so "sauber" wie möglich halten. Was nicht drauf ist kann auch nicht gehackt werden.
    Ideen wie ein asterisk drauf laufen zu lassen wäre nix f mich.

    Die in der DMZ angebotenen Dienste möchte ich entsprechend schützen – z.B. sollte der Zugang zu einem Webserver nur die nötigen Ports zulassen bzw auch intern auf andere untypische Ports forwarden um die Sicherheit zu erhöhen.

    Schutz ist gut. Unfug nicht ;) Um einen Satz einzuwerfen: "Security through obscurity is no security at all. Only pain." Ports sind Ports. Ob du die jetzt auf andere Ports weiterleitest (warum auch immer) oder nicht - ist ein Port offen kann er genutzt werden. Oder mißbraucht. Ich hatte diese Woche erst einen Kunden, der mir erzählen wollte, ich möge doch SSH für das Internet aufmachen, aber eben auf einem anderen Port, dann müsste man das ja nicht durchs VPN machen, weil das wäre ja blöde wegen Overhead und doppelter Verschlüsselung und so'n Kram. Wenn man so etwas liest, möchte man gepflegt in die Tischplatte beißen. ;)

    Guten Appetit und einen Gruß an den Zahnarzt  ;)
    Hab schon verstanden…

    Es macht absolut Sinn die offenen Ports auf die zu beschränken, die absolut notwendig sind. Also bspw. HTTP/S, SMTP o.ä. - alles weitere würde ich auch nur per VPN oder aus dem LAN zugänglich machen. Und das wars. Irgendwelche Ports zu verbiegen ist kein Schutz, sondern hält 5,8 Sekunden, bis der Portscan auf die IP durchgelaufen ist ;)

    Schwerpunkt soll auch das Monitoring und der Schutz der internen Netze sein, mittlerweile bin ich etwas vorsichtig, denn der Trojaner hat einiges an Schaden angerichtet.

    Und wie soll das realisiert werden? Internes "Monitoring"? Wie kam denn der Trojaner rein, dass er so großen Schaden angerichtet hat? Hätte sich was geändert mit den Maßnahmen die du jetzt implementieren willst? Ansonsten bringt es vllt gar nichts?

    Deswegen ist vielleicht auch wichtig in welches Netz das NAS soll.

    Was heißt? In die DMZ oder intern?

    yep, aber schon oben beantwortet –> NAS kommt ins LAN und bestenfalls per VPN zugreifen.

    z.B. ob man in der DMZ die Public IPs (aus den zugewiesenen Adressen-Pools 200.x.x.A, 200.x.x.B) direkt den entsprechenden Servern zuweist oder ob man sie per NAT auf ein internes Netz (z.B. 192.168.2.x) weiterleitet? Ist 1:1NAT für Mailserver nötig? (z.B. wegen des korrekten MX-Records?) Oder reicht es, Virtuelle IPs zu definieren (bei ganzen 8 Stk ist das ja noch machbar)

    Kann man, auch eine Möglichkeit mit 1:1 NAT, nein, ja :D

    Ja, man kann natürlich die gerouteten Adressen nutzen und weiterreichen. Allerdings bei nur 4 Adressen pro Netz glaube ich nicht, dass du eine davon vergeuden willst für das Gateway wenn du die Adressen routest. Deshalb würde ich mir das sparen und die Adressen als VIPs direkt auf dem WAN abgreifen und dann per 1:1 NAT direkt in die DMZ hineinmappen. Über die abgehende NAT von DMZ und LAN kannst du dann auch bestimmen, mit welcher Adresse die Netze/Server/Clients nach draußen auftreten. Beim Mailserver würde man ganz normal in der DNS Zone die externe IP eingeben, die auf die interne Adresse gemappt wird.

    OK, jetzt gehts ans eingemappte….

    So ich das korrekt verstanden habe ist dein Vorschlag:

    Definieren von Virtual IPs auf dem WAN Interface

    Typ: IP-Alias
      Ich nehme an als single Address (bei 8 IPs wohl granulierter steuerbar)

    Und diese IP-Adressen per 1:1NAT auf die jeweiligen Rechner in der DMZ mappen die vorher die gleichen Public IPs bekommen haben ? oder bekommen die Rechner in der DMZ interne 192.168.2.x IPs ?

    Wobei die 1:1NAT Einstellung sozusagen nur die "Straße" baut und eine zusätzliche Firewallregel den Verkehr darauf regelt?

    Ich fürchte da sind meinerseits noch einige Verständnishürden zu nehmen :-(

    Ich hoffe das hilft im ersten Gang mal weiter.

    In jedem Fall, danke erstmal

    Grüße nach ….. wohin auch immer ;)


  • LAYER 8 Moderator

    @CharlyTyngo:

    Alle Kabelmodems des ISP (=upc) erhalten per DHCP ihre IPs - das ist deren Standardfall. Diese IPs sind quasi semipermanent, denn sie ändern sich im wesentlichen nur bei Modemtausch. Ich habe beim ISP bloss zwei "IP-Pakete" bestellt und bekam sie auch zugewiesen. Jedes dieser Pakete hat ein eigenes Gateway - z.B. 200.x.x.26-30 verwendbar  Gateway: 200.x.x.25  Netmask 255.255.255.248
    Diese IP-Paket werden vom ISP in deren Verwaltung manuell gemappet, geroutet oder geirgendwast, was bei IP-Wechsel des kabelmodems gerne auch mal vergessen wird und dann steht der Karren.

    So etwas ähnliches hatte ich schon erwartet, inklusive dem "Stillstand" wenn was getauscht wird. Aber gut, wenn das deren Standardfall ist und es sogar eigene Gateways für die IP-Ranges gibt, sollte das machbar sein.

    @CharlyTyngo:

    scheinbar habe ich mir einen Trojaner auf meinem NAS (Xubuntu) eingefangen, wobei ich mir nicht vorstellen kann wie das passiert sein soll. Möglicherweise wurde meine IP-Adresse auch gespooft. Jedenfalls bekam ich vom ISP etliche abuse-mails weitergeleitet. Meine Trojaner-Jagd blieb bislang erfolglos, bleibt nur - aus reinen Sicherheitsgründen - das NAS neu aufzusetzen, freu mich tierisch.

    Monitoring im LAN könnte zumindest den Rechner identifizieren, der betroffen ist und aus der reihe tanzt.

    Jedenfalls bin ich einfach sensibilisiert und träume von einem passenden Monitoring oder einem widerstandsfähigeren Layout. Vorschläge ?

    Also ich würde erstmal die abuse Mails vom Provider genau studieren bevor ich ein komplett gutes NAS einfach mal so zerlege. Das hört sich an der Stelle nicht richtig an, denn wenn deine Trojanerjagd erfolglos bleibt und du keine wirkliche Auffälligkeit des NAS ausgemacht hast (notfalls lässt sich ja dessen Verkehr mitschneiden, so dass man sehen könnte, ob es aus der Reihe tanzt), wäre es ja Unfug es neu aufzusetzen um dann zu bemerken, dass in Wirklichkeit ein anderer Rechner zum Zombie geworden ist. Sofern das NAS jetzt nicht direkt im Netz stand und offen wie ein Scheunentor war, könnte ich mir auch nicht wirklich vorstellen, wie das (X)ubuntu darauf einfach so zum Zombie werden sollte.

    @CharlyTyngo:

    Die pfSense würde ich gerne so "sauber" wie möglich halten. Was nicht drauf ist kann auch nicht gehackt werden.
    Ideen wie ein asterisk drauf laufen zu lassen wäre nix f mich.

    Gut, denn wie auch das Core-Team immer gerne betont, ist pfSense kein FreeNAS und solls auch nicht werden. Es gibt zwar Leute, die da schon eine Verschmelzung hinbekommen haben (wollen), aber im Grunde läuft es darauf hinaus, dass die sich gerne etwas wie eine Fritz!Box XXL bauen wollen. Und das hat mit Firewall oder Border Gateway nichts mehr zu tun. Eher mit der eierlegenden Wollmilchsau ;)

    @CharlyTyngo:

    Guten Appetit und einen Gruß an den Zahnarzt  ;)
    Hab schon verstanden…

    Hehe, den meide ich lieber ;) Aber schön, wenn man mir folgen konnte. :)

    @CharlyTyngo:

    yep, aber schon oben beantwortet –> NAS kommt ins LAN und bestenfalls per VPN zugreifen.

    Sehr schön!

    @CharlyTyngo:

    OK, jetzt gehts ans eingemappte….

    So ich das korrekt verstanden habe ist dein Vorschlag:

    Definieren von Virtual IPs auf dem WAN Interface

    Typ: IP-Alias
      Ich nehme an als single Address (bei 8 IPs wohl granulierter steuerbar)

    Und diese IP-Adressen per 1:1NAT auf die jeweiligen Rechner in der DMZ mappen die vorher die gleichen Public IPs bekommen haben ? oder bekommen die Rechner in der DMZ interne 192.168.2.x IPs ?

    Wobei die 1:1NAT Einstellung sozusagen nur die "Straße" baut und eine zusätzliche Firewallregel den Verkehr darauf regelt?

    Ich fürchte da sind meinerseits noch einige Verständnishürden zu nehmen :-(

    So weit weg bist du da gar nicht. Mein Setup sieht nur ein klein wenig anders aus, da wir eine statische IP für die pfSense bekommen und die anderen Netze dort hingeroutet werden. Sprich die Netze haben kein eigenes Gateway, sondern werden über das Default Gateway geroutet. Da bin ich auch ein wenig am Grübeln, wie das einfach klappen soll, dass du die entsprechenden Netze dann auch noch mit eigenem Gateway routen sollst. Du hast ja eigentlich ein Gateway (das, was du vom Kabelmodem dynamisch bekommst) und keine drei. Hättest du die anderen beiden GWs auch noch, warum dann überhaupt dir eine dynamische IP via Modem zuweisen lassen? Das klingt alles noch ein wenig komisch. Ich würde an deiner Stelle beim ISP nochmal genau nachfragen, wie das geplant ist mit den beiden /29er Netzen. Ob die da wirklich in jedem Netz einen eigenen Gateway haben, den du ansprechen sollst, oder ob die Netze nicht doch über das Default Gateway des Modems geroutet werden. Dann würde ich nämlich nicht verstehen, wozu man die dynamische IP überhaupt braucht, weil das bedeuten würde, dass das Modem wie ein Router oder ein Netzkoppler fungiert und dich direkt mit dem Router der beiden Netze verbindet.

    Aber davon abgesehen, hätte ich genau das gesagt:

    • Virtual IP
    • Typ Alias IP
    • IP definieren mit Maske /29
    • Der DMZ ein internes Netz geben (10.x, 172.16-32.x.x, 192.168.x.x)
    • 1:1 NAT von externer IP auf interne IP definieren
    • FW Regel automatisch erstellen lassen oder selbst definieren (FW Regel muss auf die interne IP lauten, nicht auf die externe, da die IP umgeschrieben wird auf die interne, bevor sie den Filter erreicht)
    • rinse & repeat für die anderen Adressen

    @CharlyTyngo:

    Grüße nach ….. wohin auch immer ;)

    In diesem Fall: Karlsruhe, DE ;)

    Grüße
    Jens



  • Hallo Jens,

    erstmal danke f deinen Kommentar – ich werde mir das noch im Detail zu Gemüte führen.
    Vom ISP habe ich tatsächlich für jede IP-Paket ein eigenes Gateway bekommen.

    Ziemlich leicht möglich dass ich bei der Detailumsetzung noch quälen muss ;-)

    Nach deinem Posting werde ich da nochmals nachfragen wie das gemeint ist.

    LG
    Karl


  • LAYER 8 Moderator

    Hallo Karl,

    das würde ich auf alle Fälle raten. Ich hatte den Fall bereits einmal vor einiger Zeit bei einem anderen dt. Hoster, der erst kommuniziert hatte, dass es in jedem seiner Netze (/27er waren das bei ihm) ein eigenes Gateway gäbe. Nach nachfragen bei den Netzwerkern dort war dann auch allgemeine Konfusion, wie das denn vonstatten gehen sollte, denn das würde bedeuten, dass in jedem der zugewiesenen Netze der Hoster/ISP ja noch ein eigenes Gateway hineingepackt hat. Wäre das der Fall gewesen (was bei mir gut möglich gewesen wäre), dann wäre aber die Host-IP mit eigenem Gateway, die wir bekommen hatten komplett sinnlos gewesen. Wozu denn dann noch eine eigene IP nur für die FW und ein eigenes Gateway, wenn in jedem der anderen Netzsegmente eh schon ein Gateway des Hosters steht, welches erreichbar ist?
    Das "Problem" in deinem Fall sehe ich eher darin, dass es (für mich gerade) keinen Sinn ergäbe, wenn das so gelöst wäre, denn dann hieße dass ja, dass du eine feste Leitung mit statischen Endpunkten für deine Netze hast, aber die pfSense selbst soll dann per DialUp-Verfahren dynamisch eine Adresse bekommen? Macht irgendwie keinen großen Sinn ;) Deshalb würde ich da nachbohren.

    VG



  • Hallo Jens,

    ich hab gerade den Support von upc etwas gequält und solgende Info erhalten.

    Das Kabelmodem und das nachgelagerte WAN Interface der PfSense Box erhalten ihre IPs dynamisch, also per DHCP. Diese IPs werden managed IPs genannt.

    Beide IP-Packs die ich zugewiesen bekam funktionieren nach folgendem Schema:

    IP-Range1 :
    Subnet ID:  x.x.x.24/29
    Gateway: x.x.x.25
    verwendbar: x.x.x.26-30
    Broadcast: x.x.x.31
    Netmask 255.255.255.248

    Beide IP-Packs haben unterschiedliche Gateways und die jeweiligen Netzte sollen auch über die korrespondierenden Gateways geroutet werden.

    …. ich lege schon mal einige IP-Alias-Einträge an und am Montag versuche ich mal ein erstes Setup.

    Sag mal, sollte ich nicht erst auf die neue Version 2.1 upgraden oder ist zuwarten noch ein Thema?

    LG
    Karl


  • LAYER 8 Moderator

    Ich würde empfehlen zu updaten. Die Vorteile sind da einfach zu groß. Das Setup kommt mir zwar trotzdem komisch vor ;) aber wenn die das so vorgeben… ggf. musst du die Netze die aufgeschaltet sind noch routen (also extra Gateways anlegen) aber erst einmal testen.



  • puhhh….

    Der update ging relativ problemlos, aber dann kams dicke.
    Plötzlich nur mehr der halbe Durchsatz und dann gar keine Verbindung ins Internet mehr. Nach langem hin und her und knapp davor den ultimativen Hammer auf die Kiste krachen zu lassen. Ein lockerer Stromstecker am Switch hatte alles ausgelöst.

    Wieder retour zur pfsense installation hab ich dann gleich alles auf Factory-Default zurückgesetzt und die Interfaces neu aufgesetzt und alle virtuellen IPs neu eingetragen dowie dhcp und den ganze Rest.

    Danach will ihc die 1:1 NAT Verbindung eintragen und bekomme die Fehlermeldung 'Source address' is required was ich auch verstehe, trotzdem gibt es kein Eingabefeld dafür (siehe beiliegendem screenshot)

    Irgendwie scheint da etwas nicht zu funktionieren... grrrr

    LG
    Karl



  • LAYER 8 Moderator

    Hallo Karl

    nein die Fehlermeldung ist richtig ;) du trägst die Adresse ins falsche Feld ein. Wenn du die Beschreibung darunter liest, erschließt sich das auch. Kirk (ich nehme an das ist dein Alias?) funktioniert hier nicht (1:1 Mappings gehen leider nicht mit Aliasen, das ist eine Einschränkung, weswegen da auch absichtlich NICHT "Single Host OR ALIAS" steht). Außerdem trägst dus ins falsche Feld ein. Nicht Destination ist hier korrekt, sondern die Internal IP. Du mappst ja eine external IP (.26) auf Intern. Also muss da oben bei Single Host wo jetzt nix steht, deine IP von Kirk hinein.

    Destination ist (wie darunter steht) meistens any ;)

    Grüße
    Jens



  • Hi,

    habe wieder Zeit mich mit der pfsense zu beschäftigen.

    a.)

    -Alias-IPs hab ich konfiguriert

    • 1:1 NAT passt
    • Port Forward (Interface WAN) erstellt für Ports 80, 443, 22, 21 (mittels Alias angelegt und zugewiesen)

    Von außen ist der Webserver erreichbar, allerdings nicht per shh (putty)

    b.)

    LAN: Zugriff auf Webseiten von innen klappt, allerdings kann ich nichts downloaden (weder ein Download von heise.de noch ein Windows Update) … grübel

    NAT-Outbound hab ich entweder automatisch oder manuell probiert -- keine Änderung

    c.)

    Ich hab dann auch noch probiert im LAN outbound unter dem Punkt "Translation" eine der Virtual IPs einzugeben. whatismyipaddress.com gibt dann die eingegebene Virtual-IP  zurück, allerdings weiss ich nicht ob f den outgoing traffic aus dem LAN das korrekte Gateway benutzt wird.

    d.)

    ich habe eine Firewall Rule auf dem LAN Interface eingerichtet, die Verkehr in die DMZ zuläßt. Der Webserver (Kirk) ist über seine interne IP 192.168.1.200 erreichbar -- leider nicht unter seiner externen Virtual IP 213....26
    Wo muss man die NAT-Reflection eintragen, oder ist NAT-Reflection überhaupt keine gute Idee ?

    Mühsam nährt sich das Eichhorn ggg

    LG
    Karl


  • LAYER 8 Moderator

    Also…

    zu a) SSH sollte gehen (Port 22/tcp). Wenn das auf dem Webserver eingerichtet ist, sollte es auch erreichbar sein, wenn der 1:1 NAT Eintrag und die zugehörige Filterregel passt

    b) Webseiten klappen aber Downloads nicht? Das klingt dubios, wenn das eine geht, sollte auch das andere kein Problem sein? Kannst du das ausführen?
    NAT Outbound manuell zu konfigurieren ist meist praktischer, weil man sieht was man tut :)

    c) Outbound IP sollte eigentlich entweder eine fix definierte VIP für NAT sein oder der Einfachheit halber die externe WAN IP der pfSense. Das Default GW (sieht man auch unter System/Routing) wird beim Routing LAN->WAN genutzt wenn in der Regel auf dem LAN nicht namentlich ein anderes Gateway für die Regel eingetragen wird.

    d) Ich persönlich mag NAT Reflection nicht. Das gibt meistens zu viele Seiteneffekte und man muss das immer im Hinterkopf halten, wenn man am Debuggen von Problemen ist. Bsp.: Kunde ruft an, Webseite geht nicht, Kollege testet - doch die geht. Klar, er biegt ja auf dem Gateway direkt in die DMZ ab, der Kunde kommt von außen. Nur ein einfaches Beispiel.

    Es gibt generell die Option NAT Reflection, die in den Advanced Options enabled sein muss. Zusätzlich dann noch in der entsprechenden NAT Regel eintragen, und dann sollte es theoretisch tun.
    Praktisch lösen wir in meiner Firma lieber gern über einen Split-Horizon DNS, der für interne Zugriffe den Namen anders auflöst als bei externen. Damit wird bspw. kirk.domain.local intern mit 192... aufgelöst, extern aber mit 200.x.x.x

    Das sind aber nur meine 2cent ;)

    Grüße



  • @JeGr:

    zu a) SSH sollte gehen (Port 22/tcp). Wenn das auf dem Webserver eingerichtet ist, sollte es auch erreichbar sein, wenn der 1:1 NAT Eintrag und die zugehörige Filterregel passt

    Das sehe ich mir noch im Detail an

    b) Webseiten klappen aber Downloads nicht? Das klingt dubios, wenn das eine geht, sollte auch das andere kein Problem sein? Kannst du das ausführen?
    NAT Outbound manuell zu konfigurieren ist meist praktischer, weil man sieht was man tut :)

    Das war sehr seltsam, nachdem ich einige male auf alte Versionen zurückgegangen bin hab ich beim startup der pfsense eine seltsame Logmessage entdeckt:

    Startup CRON … done
        Startup /usr/local/etc/rc.d/snort.ch..done

    Ich hatte von einer 2.0.3 auf die 2.1 Version upgedated und in der alten Version war snort installiert, das ich als Paket zum testen deinstalliert habe -- offensichtlich ein Rest der alten installation, die vielleicht wie im snort-package auch Download-IPs geblockt hat. Habe die Datei per shell gelöscht und schon klappte es :-)
    Da scheint es einen Bug in der Deinstallation des package zu geben.

    c) Outbound IP sollte eigentlich entweder eine fix definierte VIP für NAT sein oder der Einfachheit halber die externe WAN IP der pfSense. Das Default GW (sieht man auch unter System/Routing) wird beim Routing LAN->WAN genutzt wenn in der Regel auf dem LAN nicht namentlich ein anderes Gateway für die Regel eingetragen wird.

    Die IP und das Gateway des WAN-Interface wird per DHCP zugeordnet.
    Um von den gelegentlichen Wechseln der WAN-IP-Adresse unabhängig zu werden soll lt ISP eine der IP-Adressen aus einem zugewiesenen IP-Pack 213…...112/29 als LAN-Outbound verwendet werden. Dieses IP-Pack hat auch sein eigenes Gateway das benutzt werden soll.

    Unter Firewall>NAT>Outbound (Manuelle Outbound rule generation) habe ich bei der ausgehenden NAT des WAN-Interfaces eine Translation auf eine der definierten Virtual IPs ausgewählt.

    whatismyip.com zeigt nun als Absende-IP die gewünschte und ausgewählte Virtual-IP.
    Leider kann ich nicht feststellen ob der Traffic übers richtige Gateway geht.
    Wie kann man das feststellen/prüfen ?

    d) Ich persönlich mag NAT Reflection nicht. Das gibt meistens zu viele Seiteneffekte und man muss das immer im Hinterkopf halten, wenn man am Debuggen von Problemen ist. Bsp.: Kunde ruft an, Webseite geht nicht, Kollege testet - doch die geht. Klar, er biegt ja auf dem Gateway direkt in die DMZ ab, der Kunde kommt von außen. Nur ein einfaches Beispiel.

    Es gibt generell die Option NAT Reflection, die in den Advanced Options enabled sein muss. Zusätzlich dann noch in der entsprechenden NAT Regel eintragen, und dann sollte es theoretisch tun.
    Praktisch lösen wir in meiner Firma lieber gern über einen Split-Horizon DNS, der für interne Zugriffe den Namen anders auflöst als bei externen. Damit wird bspw. kirk.domain.local intern mit 192… aufgelöst, extern aber mit 200.x.x.x

    Das sind aber nur meine 2cent ;)

    Na ja, deine 2cents sind mir mal lieber als die großen scheine die man eh nie bekommt gggg

    Nachdem immer wieder von problemen mit NAT-Reflection berichtet wird und unter
    https://doc.pfsense.org/index.php/Why_can%27t_I_access_forwarded_ports_on_my_WAN_IP_from_my_LAN/OPTx_networks%3F ja die Split-DNS Methode empfohlen wird, schließe ich mich gern deiner Meinung an.  ;)

    Eine Firewall-rule auf dem LAN-Interface und ein Eintrag unter Services>DNS Forwarder>Host Overrides der den Server Kirk auf die interne IP definiert löst das Problem insofern, als man den Server aus dem LAN mit seinem Namen (kirk) erreichen kann. Das reicht f meine Zwecke allemal.

    Was komisch ist, dass die Auflösung von kirk.knoffice.at nicht klappt  (ich habe knoffice.at als Domainnamen in System>General Setup verwendet, wobei das bloss ein Fantasiename ist und keine registrierte domain.

    ich hoffe ich bekomme die anderen "Kleinigkeiten" auch noch in den Griff, denn jetzt hab ich Blut geleckt.
    Gerade hat mir mein LAN-Switch den Dienst aufgekündigt nachdem er in den letzten Tagen schon Mätzchen machte.
    Kannst du mir einen günstigen 16 oder 24 Port Gigabit-Switch mit Monitorport empfehlen? Das Problem des LAN-Monitorings könnte man damit auch gleich erschlagen.

    Dann ist auch noch die Frage zu lösen welche Hardware f die pfsense (die dzt noch auf einem alten schrottrechner haust) nun ins Haus kommen soll.

    • geringer Stromverbrauch, passable Leistung, ausreichend RAM, kostengünstig, Installation auf CF Cards(sinvollerweise auf solche mit 32 od 64 GB – dann kann man schnell Backups auf einer Karte hinterlegen

    • WAN, Cable Modem dzt 2MBit Down, 1Mbit up (später u.U. ein zweites WAN-IF f Redundanz und Loadbalancing und Ausbau auf 16Mbit)

    • LAN etwa 25 Officerechner

    • DMZ mit Webserver, mailserver, Chatserver und anderen Nettigkeiten wie z.B. ZIMBRA oder opencloud und Musicserver

    • WLAN  (evtl ein Captive Portal f Freunde, aber direct Access f meine eigenen Devices - da werden kaum mehr als 3 gleichzeitig aktiv sein)

    • optional VOIP-Interface auf eigenem Switch od auch im LAN-Bereich

    • Packages: OpenVPN ( optional: snort)

    • Syslog Server im LAN

    • einen Überwachungsserver samt Snort im Netz, vielleicht irgend etwas wie nagios

    Jetzt ist er verrückt geworden, wirst du sicher denken .. aber ich träum mal vor mich hin hehehehe
    Vielleicht hast du auch einen feinen hardware-Tip ;)

    LG
    Karl


  • LAYER 8 Moderator

    Eine Firewall-rule auf dem LAN-Interface und ein Eintrag unter Services>DNS Forwarder>Host Overrides der den Server Kirk auf die interne IP definiert löst das Problem insofern, als man den Server aus dem LAN mit seinem Namen (kirk) erreichen kann. Das reicht f meine Zwecke allemal.

    Das wäre auch mein Vorschlag gewesen. Der DNS Forwarder ist für einen "kleinen" SplitDNS Ansatz eigentlich genau richtig. Notfalls kann man hier noch eine komplette lokale Domain als local resolution auswählen (so dass bspw. domain.lan für ein AD immer NUR lokal aufgelöst und nie weitergereicht wird).

    Leider kann ich nicht feststellen ob der Traffic übers richtige Gateway geht.
    Wie kann man das feststellen/prüfen ?

    Eigentlich recht einfach über einen Traceroute von intern (am Besten IP only ohne DNS Auflösung) und dann nachsehen, ob der nächste oder übernächste HOP des Rechners dann das GW vom zugewiesenen Netz ist oder das DefaultGW. Allerdings: wenn draußen die richtige IP ankommt, wäre es höchst seltsam, wenn der Traffic übers falsche Gateway ginge, weil das bedeuten würde, dass die zugewiesenen Teilnetze auch über das normal per DHCP erhaltene DefaultGW geroutet werden. Das wäre seltsam konfiguriert (es sei denn das Default GW wäre auch eben über mehrere IPs erreichbar, nur warum dann die Scharade mit dem DHCP?)

    Dann ist auch noch die Frage zu lösen welche Hardware f die pfsense (die dzt noch auf einem alten schrottrechner haust) nun ins Haus kommen soll.

    Nun da gibts diverse Möglichkeiten, aber bis auf 2 Sachen würde ich mir kaum Sorgen machen:

    1. WLAN
    2. Nagios?

    zu 1) Es gibt einfach (noch) keine aktuellen WLAN Treiber für pfSense, die ordentlichen Standard und Durchsatz ermöglichen. Wir hoffen, dass das mit 2.2 besser wird, da dieser Branch dann auf FreeBSD 10 (statt 8.3) aufsetzen soll und sich da Treiber-mäßig doch viel getan hat. Aber in 8.3 gibt es eigentlich nichts, was 802.11n spricht, geschweige denn 11ac.
    Mein Tipp an der Stelle ist da auch wirklich, WiFi machen zu lassen von Geräten die nichts anderes tun und den AP dann einfach an ein dediziertes Interface der pfSense zu hängen. Dann ist auch Captive Portal etc. nur ein kleines Problem. Und je nach AP kann man dann dabei gleich noch Nettigkeiten wie unterschiedliche VLANs, multiple SSIDs und Co implementieren

    zu 2) Was willst du mit Nagios auf der pfSense? ;)

    Aber was ich mir durchaus vorstellen könnte für deine Anforderungen: Die Lanner FW-7541D. Dazu kannst du auch hier im Forum den österreichischen Kollegen "esquire1968" aka Thomas befragen, der hat sich das gute Stück gerade zugelegt. Ich selbst habe den Vorgänger, eine FW-7535H. Was dafür spräche - und sich mit deinen Anforderungen deckt:

    • Dual Core Intel Atom D525 (genügt für die meisten, nicht so CPU lastigen Prozesse, wenn nicht noch extrem viel VPN dazu kommt etc.)
    • 6 x GbE LAN ports (genug zum Spielen und für diverse Interfaces: 2x WAN, 1x DMZ, 1x LAN, 1xWLAN, 1x VOIP bspw.)
    • Up to 4GB of RAM (damit kann man auch über eine kleine Snort-Lösung nachdenken)
    • SATA and CompactFlash (somit CF Karte kein Problem, 2,5" SSD/HDD Einbau ist aber später auch kein Problem wenn man mehr Platz bräuchte)
    • Mini-PCIe Expansion (wäre theoretisch für WiFi möglich, evtl. gibt es auch irgendwann mal wieder Crypto-Karten in dem Formfaktor für VPN speedup oder auch eine 3G Modemkarte)
    • Lüfterlos
    • Leise
    • Sehr geringer Stromverbrauch

    Ist mit ca. 480€ zwar auch nicht gerade "günstig", billig ist sie auf gar keinen Fall. Und eines der wenigen Geräte, die gleich mit stolzen 6 1GbE Interfaces daherkommen. Syslogging auf externen Host ist ja kein Problem, via SNMP und/oder NRPE/Zabbix Client lässt sich das gute Stück auch überwachen, ein paar OpenVPN Connects sind kein THema und deine WAN Bandbreite ist noch jenseits eines Werts, wo das gute Stück zu schwitzen anfangen würde (außer natürlich bei heftigem Snort Einsatz ;))

    Grüße


Log in to reply