Portforwarding durch IPSec-Tunnel



  • Hallo zusammen,

    ich versuche mich gerade an einem Setup, bei dem ich irgendwie nicht weiterkomme. Mein Aufbau:

    INET ->  PFSenseExt  -> IPSec-Tunnel  ->  PFSenseInt  ->  Server
          (V-Server bei Provider)                (Appliance zu Hause)

    Bisher nutze ich den Server nur als Webserver. Auf der PFSenseExt läuft haproxy und der reicht die http-Anfragen an den internen Server weiter. Alles gut soweit.
    Nun möchte ich aber den Server auch von Extern als DNS nutzen. Dafür habe ich auf der PFSenseExt eine NAT-Regel eingerichtet, die da sagt:
    Alles, was auf externeIP1:53 (TCP+UDP) kommt, schicke bitte weiter auf die (interne) IP vom Server. Den Server kann ich auch von der PFSenseExt aus anpingen. Nur DNS funzt halt nicht.

    Im Firewalllog sehe ich auch die Pakete, aber immer mit Schnittstelle LAN. Müssten diese nicht auf die Schnittstelle IPSec weitergeleitet werden?

    Geht das überhaupt so, wie ich mir das vorstelle? Wie sollte man sowas richtig konfigurieren?

    Hintergrund: Bisher habe ich auf meinem Internetzugang zu Hause (ADSL) einen 8er-Block IPs für externe Dienste. Mit Umstellung auf VDSL geht das nicht mehr (wird leider nicht angeboten). Also habe ich mir bei einem Provider einen V-Server mit mehreren festen IPs geholt und dort auch eine PFSense installiert und diese via IPSec mit meiner zu Hause verbunden. Und nun muss ich halt alle Dienste, die bisher nativ direkt bei mir liefen auf diesen Weg umbauen. Für http funktioniert das dank haproxy super. Aber nun kommen die anderen Zugriffe dran (DNS, RDP….)

    Vielen Dank für eure Ideen und Hilfe
    Micha



  • Sicher, dass deine Provider den Port nicht sperrt? Welchen Sinn sollte es haben, einen öffentlichen DNS zu betreiben?



  • Gesperrt werden die nicht, denn ich sehe die Zugriffe ja im FirewallLog. Ich lasse die NAT-Regel ja mitloggen - und da tauchen die Anfragen auf.

    Zum Sinn:
    Na, wenn ich eigene .de/.com/.net-Adressen registriere, dann brauche ich auch einen eigenen DNS für die Domänen. Ok, man kann das auch an einen externen Provider auslagern, will ich aber nicht. Mein Registrar stellt mir den Secondary-DNS und Secondary-MX. Die primären laufen bei mir. Warum? Weil ich es kann, und weil es geht… ;)



  • So, ich versuche mal, das Konstrukt mithilfe eurer Netzwerkdiagramme etwas genauer zu beschreiben:

    WAN / Internet
                    :
                    :
                    :
                    :  Öffentliche_IP_E1
                    :  Öffentliche_IP_E2
                    :  Öffentliche_IP_E3 ….
          .--------+--------.
          |      WAN      |
          |                      |  LAN als virtuelles IF (VLAN)
          |  pfSenseExt  +-----------------
          |                      |  192.168.x3.x/24
          |        IPSec    |
          '--------+--------'
                    |           
                    |
                    |    Internet ADSL (soll umgestellt werden auf VDSL)
                ----        | Öffentliche_IP_I1
              |            | Öffentliche_IP_I2.....I5
          .---+----------+-. 
          |IPSec    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)

    Ich hoffe, das wird so etwas besser klar.
    Die pfSenseExt ist ein V-Server mit einer Netzwerkkarte und mehreren öffentlichen IPs. Daher musste ich das LAN-Interface als virtuelles Interface auf einem VLAN ausführen.
    Der IPSec-Tunnel hat zwei P2-Einträge (P2_1 192.168.x3.x/24-192.168.x2.x/24  und P2_2 192.168.x3.x/24-192.168.x1.x/24). Der P2_2 ist aber eigentlich nur für die Administration der pfSenseExt von meinem LAN aus.
    Der DMZ-Server macht Web, DNS und MX und ist bisher über die öffentlichen IPs I1-I5 erreichbar. Diese fallen perspektivisch weg. Daher nun die pfSenseExt. Von der pfSenseExt aus kann ich die 192.168.x2.50 anpingen und der haproxy funktioniert auch problemlos. Übrigens gleich mit ACME und LetsEncrypt-Zertifikaten. Die Ext nimmt die http Anfrage auf 443 entgegen und holt sich die Daten vom DMZ-Server auf 80.

    Nun habe ich mir vorgestellt, das ich auf der Ext ein NAT bauen kann Öffentliche_IP_E2:53 -> 192.168.x2.50:53. Später muss dann auch der Terminalserver erreichbar werden. Dazu brauche ich dann das nächste NAT Öffentliche_IP_E3:3389 -> 192.168.x2.180.

    Geht das so, wie ich mir das vorgestellt habe?

    Vielen Dank
    Micha


  • Moderator

    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:53

    und

    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.50

    Hat 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....????


  • Moderator

    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


  • Moderator

    @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


  • Moderator

    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?


  • Moderator

    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.


  • Moderator

    Kein Problem, an den LB hätte ich an der Stelle als Proxy Ersatz aber auch denken können :D