Best Practise - DHCP-WAN und Public IP

[CharlyTango]

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

[JeGr]

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

[CharlyTango]

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

[JeGr]

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.

[CharlyTango]

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

[JeGr]

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

[CharlyTango]

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

[JeGr]

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

[CharlyTango]

@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

[JeGr]

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