Konfigutation mit öffentlichem IP-Subnetz

MarcM

Hallo zusammen,

zuerst möchte ich mitteilen, dass ich mich grade frisch in pfSense und Firewalls einarbeiten muss. Wir haben von unserem Provider ein /27-er IP-Subnetz bekommen und möchten jetzt eine Firewall dahinter hängen. Wir haben uns nach viel lesen und vergleichen für pfSense entschieden. Ich denke hier haben wir eine gute Entscheidung getroffen.

Mein Problem ist es jetzt, das ganze einzurichten. Leider scheiter ich bereits daran von draußen eine IP Adresse, die auf eine interne weitergeleitet werden soll, zu erreichen. Ich habe vieles versucht. Firewall Aliasse angelegt, NAT, Rules, … Ich erreiche den internen PC einfach nicht. Ich denke hier habe ich schon an der Grundkonfiguration versagt.

Angeschlossen ist es wie folgt:
ISP --> Planet Modem --> Cisco Router (GW) --> interner Router (derzeit uraltes ClearOS / soll pfSense werden) WAN an das GW und LAN an einen HP Switch zu unserem Netz.

Ziel ist, alle Server behalten ihre interne 192.168.0.x IP und die pfSense soll die öffentlichen IPs zu dem entsprechenden internen NATten. Ist das so machbar und sicher genug? Problem ist hier, es handelt sich fast ausschließlich um MS Hyper-V VMs die erreicht werden müssen. Und die Idee dahinter, dass alle Server die interne IP behalten ist, wenn hier mal Internet ausfällt, erreichen wir wenigstens noch unsere Systeme intern (CRM, Exchange, File-Server etc.)

Ich hoffe ich habe es halbwegs verständlich beschrieben und hoffe auf eure Hilfe. Danke im Voraus für eure Mühe...

Vielen Grüße aus Dortmund

Marc

JeGr

Hi Marc,

Ich denke hier habe ich schon an der Grundkonfiguration versagt.

Wenn du uns diese mal grob darlegst, können wir dir da sicher helfen.

ISP –> Planet Modem --> Cisco Router (GW) --> interner Router (derzeit uraltes ClearOS / soll pfSense werden) WAN an das GW und LAN an einen HP Switch zu unserem Netz.

Muss der Cisco als GW da drin bleiben? Wie sieht die Konfig bei dem aus, ist dort das /27er Netz überhaupt schon bekannt/aufgelegt oder gehört der noch zum Provider und routet euch das nur zu?
Wie ist auch generell das /27er überlassen worden? Hat der Provider hier selbst eine IP aus diesem Netz als dein Gateway definiert oder bekommt ihr das via Transfernetz aufgelegt?

Ziel ist, alle Server behalten ihre interne 192.168.0.x IP und die pfSense soll die öffentlichen IPs zu dem entsprechenden internen NATten. Ist das so machbar und sicher genug?

Machbar ist das, natürlich. Sicherheit ist relativ, wird aber sicher nicht (allein) durch routing vs NATting bestimmt. Es gibt einfach dann diverse Netzkonstrukte die du bei solch einem Szenario nicht nutzen kannst, aber das was du möchtest ist definitiv möglich. Allerdings wäre es "sicherer", wenn trotz Zuweisung von Public auf Interne IP die Server alle in einer extra Zone + Netzbereich und/oder VLAN stehen würden (DMZ) damit einfach kein Zugriff auf euer internes Netz möglich ist, sollte man eine der Kisten gehackt werden.

Problem ist hier, es handelt sich fast ausschließlich um MS Hyper-V VMs die erreicht werden müssen.

Warum ist das ein Problem?

Und die Idee dahinter, dass alle Server die interne IP behalten ist, wenn hier mal Internet ausfällt, erreichen wir wenigstens noch unsere Systeme intern (CRM, Exchange, File-Server etc.)

Das wäre ja kein Problem des Internetausfalls. Selbst wenn die Systeme Public IPs hätten und in einer extra DMZ stünden, dann wäre es trotzdem noch von euch erreichbar, wenn euer Internet ausfiele, denn das Default GW wäre dann ja die pfSense und die kennt dann die Public IPs der DMZ und kann die nach wie vor routen. Das ist also kein Argument pro/contra public IPs. Das ist Sache der Netzplanung :)

Ich hoffe ich habe es halbwegs verständlich beschrieben und hoffe auf eure Hilfe. Danke im Voraus für eure Mühe...

Jap :) Allerdings wäre es da vielleicht besser, wenn du das noch ein wenig umplanen/umbauen könntest, um das ganze Konstrukt besser abzusichern.

Viele Grüße
Jens

MarcM

Hi Jens,

vielen Dank erst mal für die schnelle Antwort. Freut mich sehr!

Mit dem "versagen an der Grundkonfiguration" wollte ich sagen, dass ich jetzt nicht mal mehr mit einem angeschlossenen Notebook ins Internet komme und ich nicht weiß woran das liegt. Ich habe dem LAN if im Moment noch die IP 192.168.0.55 verpasst und ebenfalls als sein default GW. An der 0.1 hängt aktuell noch unsere alte ClearOS Kiste, damit der Rest hier weiter arbeiten kann. Aber auch die 0.1 als LAN if default GW geht nicht. Das WAN if hat die erste public IP nach dem GW. Das GW ist die xx.65 und das WAS if hat die .66.

Der Cisco muss da nicht zwingend bleiben, den habe wir vom Provider bekommen und ich für uns unantastbar. Ich kann aber auch die PPPoE Einwahldaten vom ISP bekommen, dann kann der Cisco weg, sagten die jedenfalls. Das Netz gehort dem ISP, ich denke die routen das direkt hier her. Kann man das irgendwie sehen? Ich kann dir per PN gerne das Netz schicken. Sieht man das an einer RIPE Suche? Den Link dahin hast du schon kommentarlos in deiner Mailbox hier.

Grundsätzlich ist es kein Problem noch umzubauen, wie du vorschlägst. Allerdings schaffe ich es dann noch weniger alles einzurichten denke ich, weil da noch mehr dazu kommt. Werde ich dann aber durch müssen… Habe auch nichts gegen Remotegesteuerte Hilfe, Unterstützung, vormachen und zeigen ;-)

Wie genau muss ich es denn dann umstellen?

Gruß, Marc.

JeGr

Der Cisco muss da nicht zwingend bleiben, den habe wir vom Provider bekommen und ich für uns unantastbar.

Nope, wenn der vom Provider da steht, kann der normaerweise gerade nicht weg.

Ich kann aber auch die PPPoE Einwahldaten vom ISP bekommen, dann kann der Cisco weg, sagten die jedenfalls.

Zweifelhaft, denn per Einwahl (PPPoE) kann ich eigentlich kein IP Netz geroutet bekommen. Es sei denn ich habe definiert immer eine fixe IP und die routen das /27er darauf. Da du aber was schreibst von wegen der Cisco hätte jetzt .65 und das WAN der ClearOS Kiste .66 (hab ich das so korrekt verstanden?), kann das nicht so ohne weiteres sein. Oder es ist kein PPPoE.

Sieht man das an einer RIPE Suche?

Nein, im Normalfall siehst du da nur technische Ansprechpartner und allerhöchstens noch den AS, der dir das Netz bringt, das Routing bestimmt aber der Anbieter.

Wie genau muss ich es denn dann umstellen?

Kann man so pauschal nicht sagen, denn sollte bspw. der Cisco bleiben (müssen), ist es wieder ein ganz anderes Setup als ohne, wenn du bspw. das Netz via Transfernetz beziehen könntest. Das sind dann ganz unterschiedliche Arten, wie die pfSense das WAN konfiguriert bekommt und wie sie IPs annehmen kann (oder eben nicht).

Mit dem "versagen an der Grundkonfiguration" wollte ich sagen, dass ich jetzt nicht mal mehr mit einem angeschlossenen Notebook ins Internet komme und ich nicht weiß woran das liegt.

Abgehende NAT nicht konfiguriert? Keine allow Regeln von LAN -> WAN? WAN nicht richtig konfiguriert? Es könnten vielfältige Probleme sein. Da ich nicht weiß wie die ClearOS Büchse arbeitet und wie die IPs ankommen, könnte es sein, dass die pfSense parallel dazu überhaupt keine IP abbekommt, weil die alte Kiste nebendran alle IPs hat.

Aber auch die 0.1 als LAN if default GW geht nicht.

Naja die alte Kiste muss ja funktionieren, sonst würden deine Leute ja schon die Heugabeln auspacken ;)
Also ist irgendwas an deinem Testsetup mit dem Laptop madig!?

Das WAN if hat die erste public IP nach dem GW. Das GW ist die xx.65 und das WAS if hat die .66.
Das ist noch nicht ganz klar: welches Gerät hat was für eine IP wo und warum?

Grüße

MarcM

Nein, das ist nicht ganz richtig. Es hängt ja noch das VDSL Modem vor dem Cisco… Aktuelles Setup (siehe Anhang).
Der ClearOS Router hat die IP Adressen 192.168.1.1 und 192.168.0.1. Die public .66 hat die WAN Karte der pfSense.

Die Konfig auf dem Cisco sieht so aus:

interface FastEthernet0/1 
description LAN 
ip address 192.168.1.1 255.255.255.0 secondary 
ip address 85.22.69.65 255.255.255.224 

ip nat inside source list NAT_INTERNET interface Dialer1 overload 
ip nat inside source static tcp 192.168.1.32 4430 interface Dialer1 4430 
ip nat inside source static udp 192.168.1.52 2022 interface Dialer1 2022 
ip nat inside source static tcp 192.168.1.52 2022 interface Dialer1 2022 
ip nat inside source static tcp 192.168.1.32 8080 interface Dialer1 8080 
ip nat inside source static tcp 192.168.1.32 2081 interface Dialer1 2081 
ip nat inside source static tcp 192.168.1.32 2443 interface Dialer1 2443 
ip nat inside source static tcp 192.168.1.32 2080 interface Dialer1 2080 
ip nat inside source static tcp 192.168.1.32 23560 interface Dialer1 23560 
ip nat inside source static tcp 192.168.1.32 587 interface Dialer1 587 
ip nat inside source static tcp 192.168.1.32 995 interface Dialer1 995 
ip nat inside source static tcp 192.168.1.32 993 interface Dialer1 993 
ip nat inside source static udp 192.168.1.32 1194 interface Dialer1 1194 
ip nat inside source static tcp 192.168.1.32 443 interface Dialer1 443 
ip nat inside source static tcp 192.168.1.32 3033 interface Dialer1 3033 
ip nat inside source static tcp 192.168.1.32 1195 interface Dialer1 1195 
ip nat inside source static tcp 192.168.1.32 80 interface Dialer1 80 
! 
ip access-list extended NAT_INTERNET 
permit ip 192.168.1.0 0.0.0.255 any

Wir haben hier erst mal nur einen 1:1 Tausch gemacht, als wir das bekommen haben. Die Fritzbox raus, das Modem und den Cisco rein. Alles andere hat der ISP gemacht. An der Router Konfig des Cisco können wir gar nichts machen. Kommen auf die Kiste nicht mal drauf.

Der ISP sagte, der Cisco kann weg wenn wir das wollen oder anders machen können. Müsste ich noch mal genau nachfragen.

Das Internet raus geht jetzt mit dem Laptop. Ich habe vergessen bei der Vergabe der IP unsere internen DNS Server einzutragen. Die pfSense übernimmt kein DHCP und kein DNS. Dafür haben wir Windows DCs.

JeGr

Die Konfiguration auf dem Cisco sieht aber so aus, als würde ER die externen Adressen tragen, nicht die ClearOS Kiste hintenan.

MarcM

Richtig.
Die ClearOS Kiste macht nichts. Die ist nur ein interner Router und der openVPN Zugang. Der soll ja durch die pfSense ersetzt werden mit zusätzlicher FW. Das ClearOS kennt nicht mal eine der public IPs.

Vorher war es so:

ISP –> Fritzbox mit einer festen IP und intern 192.168.1.0/24
|
| --> LAN 1 ein Fileserver der extern erreichbar sein musste.
|
| --> LAN 2 Der ClearOS Router
| |
| | --> unser interes Netz (192.168.0.0/24)
| |
| |
| |

Sorry ich habe im letzten Post die aktuelle Setup vergessen anzuhängen. Die hängt hier dran. So sieht es genau jetzt aus.

setup-aktuell.png_thumb

JeGr

Die ClearOS Kiste macht nichts. Die ist nur ein interner Router und der openVPN Zugang.

Wofür wird sie dann konkret genutzt? Und warum hängt nicht einfach alles hinter dem Cisco (der ja auch filtern kann)?

Ich verstehe momentan das Konzept nicht, dass da umgesetzt werden soll, das sieht mir alles nach Daisy-Chaining hintereinander aus, aber ohne dass es für mich jetzt konkreten Sinn ergibt ;)

MarcM

Der hat das Routing gemacht. Wir wollten damals ein abgesichertes Büro-LAN das nicht groß erreichbar ist. Den Cisco und das IP-Subnetz haben wir erst seit einer Woche und ist noch nicht live.

Ich habe grade mit dem ISP telefoniert. Es ist wirklich so wie ich eingangs sagte. Der Cisco kann weg, die pfSense macht die PPPoE Einwahl und das xx.xx.xx.64/27-er Netz wird dann auf die pfSense geroutet. Die pfSense wird dann Gateway mit der .65, wenn sie das kann?

Dann kann ich die IP Adressen und Ports durch NATten auf die bestehenden internen 0.x Adressen.

=====

Ein Konzept gibt es so gar nicht. Ich bin erst seit einem Jahr in dem Unternehmen tätig. Der Wunsch war es, einige Server (Exchange, MS Dynamics CRM, Atlassian Jira und Confluence etc.) extern verfügbar zu machen. Da wir nur eine public IP hatten damals die auf der Fritzbox was und mehrere Dienste die selben Ports benötigen, was der Aufwand mit einem NGINX Webserver dahinter zu groß. Wir hatten eine Subdomain web.firma.de (die firma.de liegt bei Strato) auf unsere feste IP geleitet und alles mit web.firma.de/jira, /crm, /owa etc. gemacht. Problem an der Sache ist, wir haben einen Geschäftsführer in HH sitzen und einige MAs die viel unterwegs sind. Die immer zu zwingen VPN zu nutzen, damit Outlook geht, war keine Lösung. Die Handys haben das ordentlich gemacht, die gehen ja auch über ActiveSync…

Also musste eine Lösung her. Das Netz hat uns jetzt einmalig 100 Euro gekostet und ist lebenslang kostenlos. Da war die Lösung klar - das muss her! Jetzt haben wir es und ich muss es zum laufen gekommen.

=====

Ich habe es nun irgendwie geschafft die public IP .67 zu NATten auf die interne 0.80 und siehe da, XAMPP ist da. War der Test mit dem Laptop. Hoffe das ich das so alles richtig mache... Ein Problem habe ich allerdings, die public IP .90 kommt der Web-Admin der pfSense.

Guest

ISP –> Planet Modem --> Cisco Router (GW) --> interner Router (derzeit uraltes ClearOS / soll pfSense werden) WAN an das GW und LAN an einen HP Switch zu unserem Netz.

ISP = ok
Modem = ok
Cisco Router = erste mal NAT
ClearOS = zweites mal NAT

Und wo genau ist nun die pfSense?

Sicherlich kann man einen Cisco Router benutzen und dahinter eine pfSense Firewall, nur dann müssten bzw. sollten
die zu erreichenden PCs, Server und was weiß ich nicht noch alles hinter dem Cisco Router, also in der DMZ aufgestellt
werden und nicht hinter der pfSense.

Noch schlimmer kommt es dann wenn drei mal NAT gemacht wird, dann kann man das ganze gleich vergessen.
Ich weiß auch nicht warum ein PC eine öffentliche IP Adresse bekommen sollte?

Also ich bin jetzt mal ganz ehrlich das ClearOS macht höchst wahrscheinlich so etwas wie NAT + Squid + ClamAV
für Euch und dann noch die pfSense dazu ist nicht so der Bringer in meinen Augen.

Ich würde das ganz einfach wie alle anderen auch machen wollen, hinter den Cisco Router alles was aus dem
Internet erreicht werden soll in die DMZ und dann dahinter einfach nur die pfSense um das LAN abzusichern.
Fertig. Dann kann man von dem LAN auf die DMZ zugreifen aber nicht umgekehrt, aber die Ports vorne am WAN
Interface sind offen für die Server.

Man kann auch nur das Modem benutzen und dann dahinter die pfSense mit Squid und SquidGuard & ClamAV und
legt dort eine DMZ an der pfSense an, das geht auch dann ist OWA nicht gleich nackt im Internet zu sehen sondern
hinter einem Squid Proxy.

MarcM

Hallo Frank,

wie du schon zitiert hast […]–> interner Router (derzeit uraltes ClearOS / soll pfSense werden)[…] wird der ClearOS RT durch die pfSense ersetzt. Der Cisco hat NOCH ein NATting, weil es bislang nur ein 1:1 HW Tausch war und noch nichts an dem neuen Netz passiert ist. Damit die Mitarbeiter weiter arbeiten können und die Kunden entsprechende Systeme noch erreichen, haben wir mit der Umstellung erst mal gewartet. Steht alles im Verlauf des Threads.

Der Cisco RT kann bleiben, muss er aber nicht. Da der nur eine Schnittstelle rein und eine raus hat, macht es keinen Sinn da eine DMZ aufzubauen. Denn da muss ich noch nen Switch kaufen. Und auch kann der Cisco nicht von innen nach außen nach innen NATten, wie eine FW. Das wäre viel zu viel Aufwand.

Also entweder Cisco stehen lassen und NAT anpassen lassen, oder Cisco raus und Lösung wie mein letzter Post. Sprich pfSense wird das Netz routen und wird gleichzeitig Gateway. Wenn sie das denn kann?

Guest

Der Cisco RT kann bleiben, muss er aber nicht. Da der nur eine Schnittstelle rein und eine raus hat, macht es keinen Sinn da eine DMZ aufzubauen.

Der Bereich zwischen dem Cisco und der pfSense ist die DMZ, die musst Du nicht erst neu bauen.

MarcM

Der Bereich zwischen dem Cisco und der pfSense ist die DMZ, die musst Du nicht erst neu bauen.

Das macht ja keinen Sinn, die Server sind ja dann nicht abgesichert und 100% öffentlich. Dann würde ich der pfSense lieber ein drittes Interface einbauen und hier die DMZ einsetzen, oder verstehe ich hier grade was falsch?

Der ISP würde das Netz auf die pfSense routen und die pfSense würde die PPPoE Einwahl machen.
Kann die pfSense das Gateway sein auf der WAN Seite und die LAN Seite geht über das WAN_GW?

Guest

Was für ein Cisco Router ist das denn genau?
Modell, Nummer?

Das macht ja keinen Sinn, die Server sind ja dann nicht abgesichert und 100% öffentlich.

Wenn man schon eine DMZ baut dann auch richtig und nicht unnütz.
In Eurer ersten DMZ (ersten Zeichnung) ist der Cisco Router zu sehen und dahinter ein Fileserver
und dann ein ClearOS Server der entweder NAT oder NAT und Squid oder NAT, Squid und Snort
realisiert. Und dort ist der Fileserver genau an der richtigen Stelle! Aus dem Internet zu erreichen
und aus dem LAN zu erreichen. Und warum soolte der Filserver dann 100% ungeschützt im Internet
stehen? Ob ich nun am Cisco Router oder an der pfSense Ports öffne, diese "forwarde" und die Server
in der DMZ darüber zu erreichen sind ist doch fast egal, sie sind zu erreichen. Und völlig nackt und
zu 100% erreichbar ist wenn man vorne am WAN Interface alles auf Durchzug stellt, was natürlich
nicht anzuraten ist.

Dann würde ich der pfSense lieber ein drittes Interface einbauen und hier die DMZ einsetzen,
oder verstehe ich hier grade was falsch?

Man stellt in der Regel die ganzen Server und Geräte die aus dem Internet zu erreichen sein sollen
eigentlich immer hinter das erste WAN Gerät (SPI/NAT/Firewall) und wenn man nicht eine extra DMZ
anlegt ist das dort, der gesamte Bereich der DMZ Bereich! Man spricht dann auch oft von dem "Border"
Gateway, Router oder Firewall und die zweite Instance dahinter die muss nicht, aber kann noch einmal
SPI/NAT oder eben nur Firewall bzw. IDS/IPS machen. Nur dann noch einmal eine dritte Instance dahinter
würde ich nicht machen wollen. Wofür NAT machen wenn ich dann alles nur wieder aufbohren muss?

Der ISP würde das Netz auf die pfSense routen und die pfSense würde die PPPoE Einwahl machen.
Kann die pfSense das Gateway sein auf der WAN Seite und die LAN Seite geht über das WAN_GW?

Ja das geht alles. Die Zeichnung ist etwas groß geworden daher würde ich empfehlen sie zu speichern und
dann zu betrachten!

MM.jpg_thumb

MarcM

Hallo Frank,

danke für deine ausführliche Antwort und die Zeichnung. Hat geholfen! Es ist ein Cisco 1840.

Die finale Entscheidung ist nun gefallen, wir lassen den Cisco erst mal stehen und der macht lediglich die Einwahl. Das NAT wird vom ISP wieder entfernt. Hinter den Cisco kommt dann unsere pfSense. Die bekommt auf dem WAN IF (welche in den Cisco geht) eine öffentliche IP .66 und auf dem LAN IF die 192.168.0.1. Die LAN Seite geht in unseren großen HP Switch und da kommt alles mit internen IP Adressen dran.

In der pfSense werden viruelle IPs angelegt und diese dann per NAT auf die internen Dienste verteilt. Das wird sicher nicht die Lösung für immer sein, aber hauptsache es läuft langsam mal was.

Eine Frage habe ich noch:
Der ISP wird mir bei der Einrichtung behilflich sein. Dafür würde ich gerne das Webinterface über die Haupt IP (WAN .66) erreichbar machen. Das scheint nicht zu funktionieren. Wie kann ich das einrichten?
Unter FW –> Rules --> WAN habe ich eine Regel angelegt die sagt, dass rein über WAN IF und TCP from any to IP .66 auf HTTPS erlaubt. Das klappt aber nicht.

JeGr

Der Wunsch war es, einige Server (Exchange, MS Dynamics CRM, Atlassian Jira und Confluence etc.) extern verfügbar zu machen.

DAS ist gruselig. Die Dinger hängt man nicht nackt ans Netz. Empfiehlt dir niemand. Dafür gibts Reverse Proxies, die das verfügbar machen und nebenbei dafür Sorgen, dass eben zuverlässigere Komponenten am Netz hängen als das was da so normalerweise drauf läuft.

Das macht ja keinen Sinn, die Server sind ja dann nicht abgesichert und 100% öffentlich. Dann würde ich der pfSense lieber ein drittes Interface einbauen und hier die DMZ einsetzen, oder verstehe ich hier grade was falsch?

Wie Frank schon schreibt ist das nicht richtig, nur wenn die Server nackt am Netz hingen und der Cisco macht(e) ja NAT und kann sicher auch Regeln (auch wenn ich die nicht nehmen würde, er kanns wahrscheinlich).

Ich bin zwar normalerweise gegen so eine durchgeschleuste DMZ, aber tatsächlich besser als nix.

Die finale Entscheidung ist nun gefallen, wir lassen den Cisco erst mal stehen und der macht lediglich die Einwahl. Das NAT wird vom ISP wieder entfernt. Hinter den Cisco kommt dann unsere pfSense.

Bekommt der Cisco dann die .65 und das Netz geroutet? Wie routet der dann das Netz weiter? an die .66 die du auf die pfSense knoten willst? Macht kein Sinn, denn das Netz liegt dann ja schon auf. Verstehe also nicht ganz wie ihr das dann klöppeln wollt.

Die LAN Seite geht in unseren großen HP Switch und da kommt alles mit internen IP Adressen dran.

Und warum zum Geier nehmt ihr dann nicht - wenn es eh alles so billig war - ne neue APU Kiste, die erstens mehr Bumms hat und zweitens noch ein drittes Interface? Dann kann man auch ne ordentliche DMZ konfigurieren? Alternativ, wenn euer HP das hintendran kann - 2 getrennte VLANs machen und die Server die man Live stellen möchte da rein packen (oder deren Proxies). Das wirkt alles einfach sehr gebastelt und wenn man dann doch eh am Aufräumen ist, warum nicht richtig? :)
Die Möglichkeiten von Frank mögen valide sein (kein Affront dagegen :)) aber gruseln mich alle. Warum kein sauberes 3-Bein Setup implementieren?

Grüße

MarcM

Ich bin hier nur der ausführende Befehlsempfänger. Entscheidungen treffen andere Stellen. Ich kann immer nur mit meinen Ideen und euren Vorschlägen dahin wandern und das vorschlagen. Das macht mir langsam keinen Spaß mehr. Ich würde das so machen, wie ihr es sagt, auch wenn ich dafür neue Netzwerkkarten kaufen müsste. 2x 10 GBit Karte und fertig ist der Laden! Aber leider ist dem nicht so…

Ja, so wie es aussieht wird dem Cisco das NAT entzogen und der macht nur noch die Einwahl und routet das Netz auf die pfSense. Die hat am WAN IF bereits die public IP 66. Per SSH komme ich von draußen drau, per HTTPS aber nicht... Why? Wie mache ich das Webinterface vorübergehend per HTTPS von draußen aus erreichbar?

Guest

Also wenn ich mir das hier so alles anschaue dann würde ich einfach zwei neue Geräte anschaffen wollen.
Zum Einen eine fette Lösung für die Front und eine weniger gute aber dennoch schnelle Appliance dahinter.

Also einfach den Cisco Router gegen eine flotte pfSense Lösung austauschen und dann neue Hardware
für die ClearOS Lösung dahinter. Kann ja weiterhin bleiben und Ihren Dienst verrichten soll aber auch
nicht der Flaschenhals sein.

Irgend wann haben eben irgedn welche Leute zusammen mit den Leuten vom SANS Institute
die drei Hauptarten einer DMZ festgelegt, sicherlich gibt es dazu noch hunderte wenn nicht
sogar tausende Sublösungen gibt.

"Exposed Host" - pseudo DMZ
DMZ Port in Hardware oder Software realisiert = true & dirty DMZ
Dual homed oder "bastion host" Variante mit zwei Routern oder Firewalls = true & clean DMZ
Wird oft auch als Router oder Firewallkaskade bezeichnet.

Was jeder für sich nimmt und benutzt muss ernatürlich selber wissen und umsetzen
klar da scheiden sich die Geister immer und wenn die ClearOS "Kiste" hinter der pfSense Firewall,
so wie das netzwerk jetzt aufgebaut ist, laufen würde und das noch transparent als Snort und/oder
Squid Proxy wäre das auch noch vertretbar, aber so wie das jetzt geplant ist würde ich das nicht realisieren
wollen, und wozu auch? Cisco Router Ports auf und Route auf die pfSense dahinter die hat dann auch gleich
erst mal das NAT aufgebohrt und dann erst die Server freigeben? Die stehen doch im LAN und das soll doch
der geschützte Bereich sein der nicht?

ISP –- Internet --- Modem --- Router/Firewall --- LAN

So und wenn nun einige Server Kontakt zum Internet brauchen hat der Admin doch ein Problem
oder nicht? Er muss die Server an das Internet anbinden und möchte keinen Kontakt zum Internet
seitens seines LANs haben. Man kann nun eine DMZ Software seitig oder mittels Hardware DMZ Port
aufsetzen oder aber zwei Geräte hintereinander setzen und dazwischen ist dann die DMZ und natürlich
auch die Server.

Sollte das OS am WAN interface einen Bug haben, steht dahinter noch ein anderes gerät mit einem
anderen OS drauf was am besten unterschiedlich ist.
Hat man sich verkonfiguriert sind nur die Server mit Internetkontakt davon betroffen aber nicht die LAN
Server und Arbeitsstationen.
Vorne terminiert man das VPN und realisiert den HTTP-Proxy zur DMZ hin und am zweiten Gerät weiter
hinten setzt man ISD/IPS ein.

Das wird sicher nicht die Lösung für immer sein, aber hauptsache es läuft langsam mal was.

und das nenne ich dann eben nur noch "blinden Aktionismus" ist nicht böse gemeint aber später will da
so oder so niemand noch einmal bei gehen!

Aus dem pfSense Shop C2758 mit pfSense für den Cisco Router
XG-1540 oder einem kleinen Intel E3-12xxv3 mit 32 GB ECC RAM mit ClearOS dahinter und gut ist es.
alternativ kann man auch ein Supermicro C2758 und D-1540 Board dazu nehmen und gut ist es.
Die Server mittels eines Layer2 Switches und 10 GBit/s in der DMZ anbinden und die ClearOS
Lösung kann dann ja auch transparent laufen, also ohne NAT nur mittels Firewall und Snort.

MarcM

Du hast völlig Recht, ich würde mich da auch direkt so entscheiden, dass es die nächsten Jahre läuft wie es ist. Ich kann nur das ausführen, was ich genehmigt bekomme und das ist nun mal das was ich grade gesagt habe…

Sollte ich doch noch wiedererwartend eine andere Sache dürfen, wie genau ist die vorgehensweise wenn alle Server (auch die die nicht dreigegeben werden sollen) VMs auf zwei Windows Hyper-V Servern sind?
Dann müssten die Hyper-V Server beide in die DMZ und dann ist auch das frei was nicht raus soll, oder?

Noch mal die wichtige Frage: Wie kann ich die pf-Sense Web-Gui extern erreichbar machen mit der WAN IP?

Guest

Noch mal die wichtige Frage: Wie kann ich die pf-Sense Web-Gui extern erreichbar machen mit der WAN IP?

Am besten gar nicht, sondern nur Einwahl via VPN und dann am besten nur wenn auf Deinem Gerät ein Radius
Zertifikat installiert ist, als zusätzliche Absicherung. Sollte einmal eine Bug auftauchen sei es nun in pfSense
oder SSH, oder irgendwo anders hast Du wenigstens kein Problem.

LAN seitig würde ich VLAN1 als Admin VLAN benutzen und auch mittels Radius Zertifikat abgesichert.
WAN seitig nur via VPN und mit Radius Zertifikat abgesichert