Portforwarding durch IPSec-Tunnel
-
Die primären laufen bei mir. Warum? Weil ich es kann, und weil es geht… ;)
Bei DNS kann ich das vielleicht halbwegs verstehen, MX/Mail ist mir inzwischen zuwider und viele Mechanismen bauen darauf, dass die Mails den gleiche Weg nehmen - was sie bei einem BackupMX nicht tun. Ist mir die Zeit zum Debugging etc. zu schade aber jeder wie er will. :)
Zudem gäbe es beim DNS wesentlich bessere Möglichkeiten: Hidden Primary bspw. und der Provider stellt dann die 2 public DNSe. Bzw. ich lagere das an bspw. Cloudflare o.ä. aus und kann alles eintragen was ich will ohne mich mit dem Kram herumschlagen zu müssen - kostenlos und mit API, die auch bspw. pfSense versteht (ideal für LetsEncrypt & Acme Bot).Aber OT.
Geht das so, wie ich mir das vorgestellt habe?
Vorausgesetzt der Tunnel ist sauber aufgebaut, dass die Netze .1.x und .2.x von der pfExt sauber erreicht werden, dann kannst du bei einem Port Forwarding das so eintragen, ja. Wir machen als Krücke was ähnliches mit gewissen IPs an einem anderen Standort, die noch gebraucht werden, die Server aber schon lange woanders stehen. Nur dass wir statt IPSec OpenVPN haben. Aber das Prinzip ist das Selbe. IP von StandortExt wird via VPN auf Subnetz/VLAN in StandortInt übertragen und zurück.
Gruß
-
Also… der Tunnel ist insofern sauber, als das ich wie gesagt, den DMZ-Server anpingen kann. Auch funktioniert der haproxy problemlos.
Nur dieses Portforwarding eben nicht. Ich logge auf der pfSenseInt alle Pakete mit, die durch den Tunnel ankommen. Da sehe ich die ganzen :80-Pakete vom Proxy aber nicht ein einziges :53. Als ob er zwar nichts blockt, aber die Pakete nicht in den Tunnel leitet.Probiert habe ich nun auch folgende Konstrukte:
Virtuelle IP 192.168.x3.50 auf der Ext erstellt
NAT Öffentliche_IP_E2:53 -> 192.168.x3.50:53
NAT 192.168.x3.50:53 -> 192.168.x2.50:53und
Weiteren Phase2 erstellt mit der Öffentliche_IP_E2 auf der Ext-Seite und dem DMZ-Netz auf der Int-Seite.
Damit konnte ich von der Ext den DMZ-Server auch mit der Öffentliche_IP_E2 als QuellIP anpingen
dann
1:1-NAT Öffentliche_IP_E2 -> 192.168.x2.50Hat alles nichts geholfen. Ich bekomme die :53er Pakete nicht in den Tunnel und bin langsam mit meinem Latein am Ende. Was könnte man noch probieren?
Oder liegt es gar am IPSec? Ich glaube, mal in irgend einem Forum gelesen zu haben, das bestimmte Sachen in der pfSense mit IPSec nicht gehen, aber mit OpenVPN....???? -
Virtuelle IP 192.168.x3.50 auf der Ext erstellt
He? Warum? Ich denke dein Server steht in .2.50. Was willst du mit der 3er Adresse? Du machst das Forwarding auf dem WAN der PFext und als Ziel gibst du die 2er Adresse an. Wenn er die wie du sagst kennt und pingen kann, dann weiß er auch dass er den Traffic durch den Tunnel packen muss. Ansonsten muss man mit tcpdump mal ranhören, ob was in den Tunnel geht und ob es ankommt. Aber mit irgendwelchen Adressen doppelt und zusätzlichen Phasen rumkaspern ist da nicht zielführend, da verbastelst du dir hinterher mehr als dass nachher funktioniert.
Es kann aber durchaus sein, dass dein Problem durch IPSec bedingt ist. Dadurch dass hier Phasen definiert sind und die Remote Seite nur ihr LAN nach drüben schickt, wird wahrscheinlich der port-forwarded traffic nicht durch den Tunnel gewuppert.
Da du an beiden Ecken pfSense hast, würde ich den IPSEC Tunnel wegreißen, OpenVPN hinbauen und dann das ganze nochmal versuchen - wie gesagt, so wuppt das hier problemlos.
-
Das lokale 3er-Netz auf der Ext habe ich wegen dem haproxy. Der kommt nicht damit klar, das die pfSense nur eine WAN-Schnittstelle hat. Der braucht noch eine IP auf dem LAN-Interface (quasi als Quell-IP für seine Anfragen an den Webserver) - das ja eigentlich physisch gar nicht existiert. Daher habe ich auf der WAN-Schnittstelle ein VLAN konfiguriert und das dann als LAN-Schnittstelle definiert. Wie gesagt - bis dahin funktioniert auch alles wunderbar.
Ich werde mich dann mal beimachen und statt IPSec OpenVPN versuchen. Hatte IPSec nur verwendet, weil ich das bereits kenne. Mit OpenVPN habe ich bisher noch nichts gemacht - aber man kann ja nur dazu lernen :-)… ich berichte, obs was gebracht hat.
VG
Micha -
@Micha: Wie gesagt, per OpenVPN lüppt das garantiert, läuft hier ja schon seit gut 3 Jahren das Dingens ;) Dadurch dass OpenVPN Routen sauber in den Stack pusht, klappt das auch anders als bei IPSEC wo eben ein eigenes Interface fehlt und daher das Routing ein wenig "hinterm Rücken" läuft. Das ist mit ein Punkt, was mich an IPSEC leider immer noch stört. Wird aber vllt. besser wenn mit einer der nächsten FreeBSD Versionen auch IPSEC endlich ein Pseudo Interface bekommen soll.
-
So.. die Konfig hat sich nun folgendermaßen geändert:
WAN / Internet
:
:
:
: Öffentliche_IP_E1
: Öffentliche_IP_E2
: Öffentliche_IP_E3 ….
.--------+--------.
| WAN |
| | LAN als virtuelles IF (VLAN)
| pfSenseExt +-----------------
| | 192.168.x3.x/24
| openVPN |
'--------+--------'
| 10.0.8.1(Server)
|
| Internet ADSL (soll umgestellt werden auf VDSL)
---- | Öffentliche_IP_I1
10.0.8.2 (Client)| | Öffentliche_IP_I2.....I5
.---+-----------+-.
|openVPN WAN| -------------------------------> TS 192.168.x2.180
| | priv. DMZ | .-----------------.
| pfSenseInt +------------------------+--+ DMZ-Server |
| | 192.168.x2.50 '-----------------'
| LAN | 192.168.x2.51...60
'--------+---------'
| 192.168.x1.x/24
|
|
.-------+--------.
| LAN-Switch |
'-------+--------'
|
...-----+------... (Clients/Servers)Nachdem ich der Ext noch eine Route von Hand wegnehmen musste, die noch vom IPsec stammte und vom openVPN nicht überschrieben wurde, funktioniert der haproxy wieder wie zuvor.
Also insofern erstmal den Zustand vom Anfang wieder hergestellt.Nun kommen wir zu meinem Portforwarding... und was soll ich sagen: auf einmal kommen bei meinem DMZ-Server die :53er Pakete auch an :-). Nur tut sich da das nächste Problem auf...
als Quell-IP der Pakete kommt die öffentliche IP des anfragenden Host mit. Wenn mein Server darauf antworten will, dann gehen die Pakete natürlich über sein defaultGate (WAN pfSenseInt) raus. (klassisches Triangelrouting :-( )
Offenbar ist Portforwarding hier gar nicht das richtige Mittel.?. Ich bräuchte eine Art Proxyfunktion (wie beim haproxy für http), der die Anfrage auf der Ext entgegen nimmt, mit der LAN-IP der Ext als Quelle an den DMZ weiterreicht, von dem dann die Antwort bekommt und diese dann wieder mit der WAN-IP der Ext als Quelle an den anfragenden Host rausgibt... oder lässt sich das auf mit NAT irgendwie realisieren?VG
Micha -
oder lässt sich das auf mit NAT irgendwie realisieren?
Jup, mache bei der pfSense Int von OVPN kommend nach DMZ auf die DNS Adresse NAT an und NATte auf die OVPN Tunnel IP. Dann kommen die Pakete nicht mit der externen IP an, sondern werden auf der zweiten pfSense dann vom OVPN zum DMZ abgehend geNATtet auf die OVPN Adresse und gehen dann auch wieder in den Tunnel zurück. So müsste es klappen. Da DNS mit UDP da recht "bescheiden" ist, sollte das ganz gut klappen.
Gruß
-
Also.. ich hoffe, ich habe dich richtig verstanden:
Ich habe auf der Ext das Portforwarding dahingehend geändert, das ich als Ziel nicht den DMZ-Server sondern die OpenVPN-TunnelIP der Int gesetzt habe (statt 192.168.x2.50 nun 10.0.8.2)
Auf der Int habe ich sowohl 1:1-NAT auf dem Interface OPENVPN von 10.0.8.2 auf 192.168.x2.50 als auch alternativ ein Portforwarding von 10.0.8.2:53 auf 192.168.x2.50:53 getestet… in beiden Fällen kommen die Pakete ordnungsgemäß beim DMZ-Server an, aber...
Egal, was ich da mache.. es hilft nix. Ich logge auf dem DMZ-Server die Pakete mit Wireshark und als Quell-IP bleibt immer die öffentliche IP des anfragenden Host im Paket drin...
Habe ich noch einen Fehler in meiner Interpretation deiner Lösung? -
Ich habe auf der Ext das Portforwarding dahingehend geändert, das ich als Ziel nicht den DMZ-Server sondern die OpenVPN-TunnelIP der Int gesetzt habe (statt 192.168.x2.50 nun 10.0.8.2)
Nein, das bleibt :)
Auf der Int habe ich sowohl 1:1-NAT auf dem Interface OPENVPN von 10.0.8.2 auf 192.168.x2.50 als auch alternativ ein Portforwarding von 10.0.8.2:53 auf 192.168.x2.50:53 getestet… in beiden Fällen kommen die Pakete ordnungsgemäß beim DMZ-Server an, aber...
Das meinte ich nicht ;) Sondern einen Eintrag bei den OUTBOUND NAT Regeln. Du willst ja Outbound Traffic NATten, nur eben, dass der in deinem Fall IN dein Konstrukt REIN geht und nicht wie sonst von LAN nach WAN RAUS geht.
Ich meinte also eine Outbound Regel VON any NACH 192.168.x2.50 soll auf Interface DMZ (vermutlich?) geNATtet werden. Das könnte dann auch die DMZ IP sein auf die genattet wird, ist eigentlich egal, hauptsache der Traffic geht zur pfSense zurück und dann wieder in Tunnel rein.
-
So, nachdem ich das ganze Thema wegen beruflicher Auslastung erstmal etwas schieben musste, möchte ich kurz schreiben, wie meine Lösung aussieht. Vielleicht interessiert es den ein oder anderen….
Ich habe offenbar viel zu kompliziert gedacht. Die pfSense hat einen Service, der das ganz simpel und smart löst: den Loadbalancer.
Ich habe die ganzen NAT-Regeln über Board geworfen und im Loadblancer einen Pool erstellt, in dem mein interner Server (derzeit) einziges Mitglied ist. Alle Anfragen an die öffentliche IP Port 53 bearbeitet der Loadbalancer und schickt die Pakete an den internen Server weiter. Da damit die Quell-IP des Paketes die interne IP der pfSense ist (da ja der Loadbalancer die Anfrage schickt), werden die Antwortpakete sauber durch den Tunnel zurückgeroutet und der Dienst ist von extern erreichbar. Der Loadbalancer arbeitet nun quasi wie ein Proxy und das auch mit UDP.
Manchmal kann das Leben so einfach sein, wenn man nur mal ein paar Wochen drüber schläft ;D
Trotzdem gilt mein ganz besonderer Dank JeGr, der so viel Geduld mit mir hatte.
-
Kein Problem, an den LB hätte ich an der Stelle als Proxy Ersatz aber auch denken können :D
