FTP Proxy für internen Server

JeGr · Jan 10, 2007, 12:04 PM

Grüße beisammen.

Bevor ich mir jetzt 3x ins Bein schieße lieber einmal zuviel nachgefragt ;)
Konstellation: pfSense soll ein BorderGateway übernehmen, also einen Part der Firewall zwischen 2 öffentlichen Netzen. (ext/int keine privaten IPs).

Nun steht im internen Netz ein FTP Server. Schön. Wie setzt man jetzt am (un)geschicktesten den FTP Proxy ein, um nicht wieder ein Riesenloch in die Firewallregeln bohren zu müssen? Reicht es ihn auf dem ext. Interface der pfSense zu aktivieren und Zugriff von außen auf die WAN-IP tcp/21 freizugeben oder gibts es andersweitige Fußangeln zu beachten?

Grüße
Grey

hoba · Jan 10, 2007, 3:48 PM

Sehe ich das richtig, daß Du nicht nattest sondern routest? Oder ist es gebridged?

JeGr · Jan 10, 2007, 3:56 PM

Routing por favor :)

JeGr · Jan 25, 2007, 12:35 PM

Um es einfacher zu machen, es geht um die Umsetzung einer Redundanz-Konstellation:

      +-----+               +-----+
      | R01 |               | R02 |
      +--+--+               +--+--+
         |                     |
         |      +-------+      |
         +------|  HUB  |------+
         |      +-------+      |
         |                     |
      +--+--+               +--+--+
      | F01 |               | F02 |
      +--+--+               +--+--+
         |                     |
         |      +-------+      |
         +------| SWTCH |------+
                +---+---+
                    |
                  SRVCS

R: Router
F: Firewalls

Es kommt eine Leitung pro Firewall (von Cisco Routern) die eben vorher noch über nen Hub laufen, damit alle Konstellationen möglich sind (F1/R2 und F2/R1 wie direkt). Auf seitens der Cisco ist immer nur ein Gerät aktiv (Redundanzprotokoll), dito soll es bei den FWs sein (CARP auf ext. wie int. IF).

So weit so gut, nun steht eben bei den Dienstservern hinter den FWs (SRVCS) ein FTP Server der erreichbar sein soll, ohne dass große Knieschüsse in Firewallregeln mit passiver Portrange etc. gemacht werden müssen. Genügt es hier auf dem ext. IF den FTP Helper zu aktivieren? Welche Regeln sind hier ggf. auf dem ext. IF einzupflegen wenn man ein sehr … rabiates Regelset zugrunde legt (deny all als default int/ext).

Gruß Grey

hoba · Jan 25, 2007, 1:07 PM

Aktiviere den FTP-Helper auf dem WAN interface. Dann generiere einen Portforward für die externe CARP IP des Ports 21. Du solltest einen Hinweis bekommen, daß 2 Regeln generiert wurden (zusätzliche eine auf 127.0.0.1 für den FTP-Helper). Dadurch kann der jetzt dynamisch Ports öffnen und schließen bzw. die IP umschreiben falls notwendig.

JeGr · Jan 25, 2007, 4:27 PM

Welches NAT Ziel soll der Port Forward haben? Den eigentlichen Zielserver oder 127.0.0.1? Das ist gerade ein wenig unklar ;)

hoba · Jan 25, 2007, 8:17 PM

Den tatsächlichen internen Server. Den Rest macht die pfSense für Dich :)

JeGr · Jan 26, 2007, 8:09 AM

Gut, werde ich testen. Mir ist zwar gerade brezelhaft, wie der FTP Helper rausfindet, dass sein Typ gefragt ist, sobald anfragen an die FTP Server Adresse gehen (da der Helper ja auf die CARP IP gebunden wird, so ich das verstehe, und es ja keine NAT gibt) aber ich lasse mich da überraschen. :)

hoba · Jan 26, 2007, 10:34 AM

Genau das sollte die Logik alles "behind the scenes" erledigen.

JeGr · Jan 26, 2007, 12:46 PM

Da ich gerade aus dem IPCenter zurück bin und dort die beiden Hübschen abgeliefert habe, werde ich wohl nächste Woche "live" erleben, ob (und hoffentlich dass) es so ist :) Aber ich bin schon froh, dass sich meine Chefs inzwischen an pfSense gewöhnt und damit angefreundet haben ;) Das "corporate" Theme half übrigens nicht schlecht, sieht doch einfach sehr schick aus, auch wenn mir dein neuester Sproß teils besser gefällt :D

JeGr · Jan 26, 2007, 2:14 PM

Da mir das jetzt schon mehrfach über die Füße gefallen ist: Inwieweit sind die aktuellen Snapshots "production stable"? Es muss nicht unbedingt "rock-solid" sein, aber ich denke hier wie oben zu sehen an Echtbetrieb mit 2 Carp-Nodes. Bzw. lohnen sich die Änderungen in den Snapshots im Gegensatz zu 1.0.1?

hoba · Jan 26, 2007, 2:49 PM

Die Änderungen lohnen sich auf jeden Fall. Die 1.x Serie Snapshots haben gegenüber der 1.0.1 sowohl Geschwindigkeitsvorteile, einige "ungewöhnlichere" Konfigurationen wurden gefixt, mehr Hardwaresupport wegen neuerem FreeBSD 6.2, mehr Bedienkomfort (z.B. Multiwan ist viel einfacher einzurichten), und kleine Feature-Ergänzungen (wie z.B. Failoverpools) und sieht einfach toll aus (neues default Theme) ;D .

Die HEAD-Version ist, wie bereits schon mehrfach erwähnt, unstable und eigentlich noch Alpha. Mit der sollte man allenfalls "rumspielen".

JeGr · Jan 26, 2007, 3:06 PM

Wenn ihr meint, das ist soweit "stable" als das ich nicht jeden Tag neuboote ;) dann werd ichs gern mal hier in der Firma auf der WRAP einspielen (wo es ja einiges an Geschwindigkeit geben soll) und ggf. dann ein paar Tage später im IPC.
Und das default Theme ist definitiv cool ;)

hoba · Jan 26, 2007, 8:54 PM

Ich habe im Büre Multiwan mit Loadbalancing und Failoverpools laufen. PPTP-Server, IPSEC-Tunnel, Trafficshaper, Portforwards am WAN und OPT-WAN, DMZ-subnet,… keine Probleme soweit und wenn ich was gefunden hätte wäre es schon behoben ;)

Wenn Du Loadbalancingpools bereits einsetzt mußt Du allerdings nach dem Update alle Poolmitglieder löschen und wieder neu reinsetzen (den Pool selbst kannst Du bestehen lassen). Liegt an dem geänderten GUI und der zusätzlichen Failoveroption.