m0n0wall: Geht NAT vor dem VPN Tunnel?

Hermez

Member
Hallo zusammen,

vielleicht hat hier jemand eine Idee, da lt. m0n0wall-mailingliste NAT von VPN Traffic nicht möglich ist; was ich aber nicht ganz glauben kann.

Siehe thread@ http://m0n0.ch/wall/list/?action=show_msg&actionargs[]=96&actionargs[]=82

Hier die Anforderung:
Bevor Pakete durch einen VPN Tunnel zur remote Seite übertragen werden, sollen diese von der privaten IP auf eine öffentliche IP genatet werden. Diese Funktion macht insbesondere Sinn, wenn man nur wenige öffentliche IPs zur Verfügung hat und entsprechend haushalten muß. Genaugenommen soll eine private IP für FTP sowie eine weitere IP für HTTP in eine jeweils eigene öffentliche IP geNATed werden (insgesamt also zwei öffentliche IPs) bevor der Traffic durch den VPN Tunnel geht.

Möglicherweise gibt es ja einen "dirty trick" mit dem sich das NAT vor dem VPN manuell in der Konfigurationsdatei konfigurieren läßt oder per earlyshellcmd" (such commands are executed before most of the system configuration is done). Im schlimmsten Fall würde ich mich auch an das patchen der Sourcen heranwagen, wenn mir jemand etwas Schützenhilfe leistet. Es wäre echt schade, wenn es an diesem blöden NAT scheitern würde, da m0n0wall die perfekte Lösung für meine Anforderungen ist.

Eine kleine Anmerkung noch zu Chris Buechler's Aussage in o.g. Thread: Entgegen seiner Ausage, daß diese Funktion auch nicht von kommerziellen Firewalls unterstützt wird, bieten Cisco Router, Cisco PIX Firewalls sowie Netscreens sehr wohl diese Funktion. Wobei ich diese jetzt nicht mit m0n0wall vergleichen will, da diese Geräte auch richtig Kohle kosten.

Herzlichen Dank schonmal im voraus für jeden Hinweis. :)

Grüße,

H.
 
Also wenn du alles als Link kopierst, gehts schon. :)

Also das alles:


Code:
http://m0n0.ch/wall/list/?action=show_msg&actionargs[]=96&actionargs[]=82
 
Also ich hatte mal auf dem Router der auch NAT macht VPN mittels PPTP laufen... auch IPSEC geht durch NAT mit einigem "Gefummel".

Gruß, I.MC
 
Hermez,

jetzt verstehe ich was Du willst. :)
Da ich m0n0wall noch nie benutzt habe kann ich nur vermuten/raten wie es damit geht:

Wenn Du entsprechende NAT Regeln festlegst (outbound oder 1:1) für Deinen HTTP und FTP Server und dann in der IPSec Konfiguration als Local Subnet die genattete IP (also nicht die private sondern die öffentliche) angibst geht es vielleicht. Ich kann die Konfigurationsmöglichkeiten leider nur aus den Screenshots ersehen.
 
Moin zusammen,

@Embedded BSDler:

Wenn Du entsprechende NAT Regeln festlegst (outbound oder 1:1) für Deinen HTTP und FTP Server und dann in der IPSec Konfiguration als Local Subnet die genattete IP (also nicht die private sondern die öffentliche) angibst geht es vielleicht. Ich kann die Konfigurationsmöglichkeiten leider nur aus den Screenshots ersehen.

Genauso funktioniert es auf dem Cisco VPN Concentrator 3000. Wenn ich diese Woche noch dazu komme, baue ich mal ein Lab auf. m0n0wall direkt mit einem Cisco Router verbinden und hinter den Devices jeweils einen Client. Und dann auf dem Cisco Router debuggen was die m0n0wall so ausspuckt. "Forschungsergebnisse" werden hier dann gepostet. Im übrigen funktioniert VPN zwischen 'ner m0n0wall und Cisco devices prächtig (wenn auch vorerst ohne das gewünschte NAT).

Zu Deiner Frage mit welchen Befehlen man das Problem auf einer Cisco PIX löst (seltsamerweise erscheint die Frage lediglich in der Benachrichtigungsmail des Forums aber nicht hier im eigentlichen Thread, but anyway).

static (inside,outside) <FTP server public_IP> <FTP server private_IP> netmask 255.255.255.255 0 0

Anmerkung: Die Reiheinfolge von (inside,outside) ist verwirrend, weil nach der Klammer zuerst die öffentliche IP definiert wird und danach erst die private IP. Es ist also genau umgekehrt zu der Reihenfolge in der Klammer! ;)

In der access-liste definierst Du dann welcher Traffic überhaupt durch den VPN Tunnel fließen soll. Die access-liste mit dem Namen VPN_2_MONOWALL ist im übrigen einem VPN-Tunnel zugeordnet. Das heißt, alles was in der access-liste VPN_2_MONOWALL steht, wird durch den VPN Tunnel gejagt.

access-list VPN_2_M0N0WALL permit ip host <FTP server public_IP> host <remote FTP server>
access-list VPN_2_M0N0WALL permit ip host xx.yy.0.1 host ww.zz.69.166
access-list VPN_2_M0N0WALL permit ip host xx.yy.0.2 host ww.zz.69.167


Ab welcher IOS-Version diese Funktionen bereitstehen kann ich Dir nicht sagen. Wieso eigentlich die Fragestellung? Steht so eine Büchse bei Dir unter dem Tisch, die darauf wartet ein bißchen zu tunneln? :D

Im übrigen nochmals Danke an das Forum sich mit dem Thema m0n0wall auseinanderzusetzen, obwohl es ja schon etwas Off-Topic ist.

Beste Grüße,

R.
 
Hermez,

habe die Frage nach den Befehlen wieder gelöscht weil ich selbst drauf gekommen bin. Hatte anfangs nicht sofort verstanden was Du mit Deinem NAT wolltest und ob es überhaupt geht. War etwas vorschnell mit posten... :)

Funktioniert das von mir vorgeschlagene Beispiel mit m0n0wall oder nicht ?
Hast Du es mal ausprobiert?

Wenn es nicht geht müsste man mal direkt mit einer Shell auf die Kiste und sehen ob durch manuelle Kofiguration von ipfilter und/oder racoon etwas hinzubiegen ist.
 
I.MC schrieb:
Also ich hatte mal auf dem Router der auch NAT macht VPN mittels PPTP laufen... auch IPSEC geht durch NAT mit einigem "Gefummel".

Gruß, I.MC

Also _das_ wuesste ich jetzt gerne genauer. Was verbirgt sich hinter 'mit einigem "Gefummel"'? NAT Traversal ist ja sozusagen in der IPSec Ecke bei den BSDs most wanted.
 
NAT vor IPSEC geht mit m0n0wall definitiv nicht!

Nun wie versprochen die "Forschungsergebnisse".

Versuch 1: Outbound NAT

attachment.php


Eigentlich ist von vornherein klar, daß es nicht funktionieren kann. Die Auswahl des Interfaces, auf dem das NAT erfolgen soll, ist das WAN Interface. Dummerweise erfolgt IPSEC ebenfalls auf dem WAN Interface mit der Wahrscheinlichkeit, daß die NAT Routine nicht vor der IPSEC Routine ausgeführt wird. Und nachdem die Pakete IPSEC durchlaufen haben ist sowieso Schicht im Schacht. Abschließend noch der Auszug des Debuggings vom Router.

*Mar 1 01:54:15.403: %CRYPTO-4-RECVD_PKT_NOT_IPSEC: Rec'd packet not an IPSEC packet.
(ip) dest_addr= 194.7.ww.xx, src_addr= 212.190.yy.zz, prot= 6


Versuch 2: 1:1 NAT

attachment.php


Leider läßt sich das 1:1 NAT ebenfalls nur auf dem WAN Interface einstellen.
Dementsprechend herrscht hier das gleiche Problem, daß IPSEC auf dem gleichen Interface vor der NAT Routine ausgeführt wird. Auch hier vollständigkeits-halber der Auzusg des Debuggings vom Router.

*Mar 1 02:03:19.671: %CRYPTO-4-RECVD_PKT_NOT_IPSEC: Rec'd packet not an IPSEC packet.
(ip) dest_addr= 194.7.ww.xx, src_addr= 212.190.yy.zz, prot= 6


Server NAT hatte ich sicherheitshalber auch versucht. Allerdings spare ich mir die Auflistung hier, da es sich primär für Traffic von "außen", also WAN Interface handelt. Was mir, selbst wenn es funktioniert würde, nicht weiterhilft weil ja erstmal der inital traffic genatet werden muß.

Der Vollständigkeitshalber hier noch der Screenshot von der VPN Konfiguration für die oben genannten Versuche. Der erste Eintrag enthält die IP 212.190.yy.zz für den Server im lokalen Netz. Wie in den oben aufgeführten Auszügen des Router debuggings offensichtlich ist, reicht m0n0wall den Traffic zwar mit der korrekt genateteten IP durch, aber leider unverschlüsselt.

attachment.php


Die zweite Rule der IPSEC Konfiguration (grau, weil ich die für den ersten Versuch deaktiviert habe) enthält die gleichen Settings wie die erste, nur mit dem Unterschied der privaten IP Adresse für den Server im lokalen Netz. Ich hab' dann nochmal beide IPSEC Rules aktiviert, ohne vorher das NAT auszuschalten. Hierzu das entsprechende Debugging des remote Routers beim Versuch eine Verbindung zur Gegenstelle aufzubauen:

*Mar 1 18:56:29.747: IPSEC(validate_proposal_request): proposal part #1,
(key eng. msg.) INBOUND local= 217.20.yy.zz, remote= 217.20.ww.xx,
local_proxy= 194.7.ww.xx/255.255.255.255/0/0 (type=1),
remote_proxy= 172.17.4.104/255.255.255.255/0/0 (type=1), <-- private IP!!!
protocol= ESP, transform= esp-des esp-sha-hmac ,
lifedur= 0s and 0kb,
spi= 0x0(0), conn_id= 0, keysize= 0, flags= 0x4


Dem Log nach wird der IPSEC Tunnel zwischen der m0n0wall (remote= 217.20.ww.xx) und dem Cisco Router (local= 217.20.yy.zz) erfolgreich aufgebaut.
"local_proxy= 194.7.ww.xx/255.255.255.255" ist hierbei der Server hinter dem Cisco Router, "remote_proxy= 172.17.4.104/255.255.255.255" der Server hinter der m0n0wall. Kurze Anmerkung zu local und remote: Da das Debugging auf dem Cisco Router erfolgt, ist die m0n0wall die remote Seite und der Cisco Router das local System.

Den ganzen Tests nach zu urteilen greift auf der m0n0wall die IPSEC Routine vor der NAT Routine. Bevor also irgendwas überhaupt geNATet werden kann, hat die m0n0wall die Pakete bereits mit IPSEC verschlüsselt. Dass ein anschließendes NATen der IP Adressen innerhalb der IPSEC Pakete wegen der Verschlüsselung nicht mehr möglich ist, versteht sich wohl von selbst.

Lösungsansätze:

1. Direkt per Shell die Settings von ipfilter bzw. racoon umzubiegen schließt sich von vornherein aus, da es schlichtweg keine Shell gibt. Auch nicht am consolen port (über COM1).

2. Hat jemand eine Idee, ob man die Settings von ipfilter bzw. racoon evtl. über die globale XML-Konfigurationsdatei umbiegen könnte?

3. earlyshellcmd (such commands are executed before most of the system configuration is done):
Hierüber ipfilter/racoon zum NATen vor der Verschlüsselung mit IPSEC zu bewegen. Hat jemand 'ne Idee?

4. Die Sourcen dahingehend zu patchen, daß die NAT Routine vor der IPSEC Routine ausgeführt wird. Wäre wohl die sauberste und effektivste Lösung. Wer hat eine Idee wie und wo man das patchen müßte. Evtl. hätte ich jemanden, der das machen könnte (habe selbst leider keine Programierkenntnisse).

Wäre super, wenn doch noch jemand einen Handgriff kennt wie dieses Problem zu lösen ist.

Schöne Grüße,

H.
 

Anhänge

  • Versuch1.webp
    Versuch1.webp
    21,3 KB · Aufrufe: 1.688
  • Versuch2.webp
    Versuch2.webp
    18 KB · Aufrufe: 1.720
  • IPSEC_conf.webp
    IPSEC_conf.webp
    11,8 KB · Aufrufe: 1.811
Zuletzt bearbeitet:
fader schrieb:
Also _das_ wuesste ich jetzt gerne genauer. Was verbirgt sich hinter 'mit einigem "Gefummel"'? NAT Traversal ist ja sozusagen in der IPSec Ecke bei den BSDs most wanted.
Es gab hier wegen IPSEC schon mal einen Thread wo stand, dass es geht wenn ich mich recht erinnere. Es gibt ja zwei Modi bei IPSEC, der mit dem es gehen sollte heisst glaube ich Tunneling, kann aber auch der andere gewesen sein. Ich habe das mal eine Weile selber versucht, aber mit IPSEC habe ich es nicht an's Laufen bekommen. Die dazu vorhandene Doku war sehr duerftig. Meine Kenntnis is da also doch beschraenkt :-(

Gruss, I.MC
 
Hermez,

ich glaube das Problem ist wirklich nur durch einen Eingriff in den Sourcecode von IPFilter zu lösen. Da NetBSD auch IPFilter (wie m0n0wall) benutzt und auf der manpage zu ipf(4) folgender Text zu lesen ist (unter BUGS :) ):

When a packet encapsulated by ipsec(4) tunnel comes in, ipf(4) looks at wire-format packet on inbound and outbound. ipf(4) will not look at decapsulated packets on inbound, nor packets prior to encapsulation on outbound.

Und unter http://netbsd.binarycompass.org/Documentation/network/ipsec ist zu lesen:

Since February 2001, on NetBSD-current, ipf(4)/IPsec interaction was clarified as below:

ipf(4) looks at packets in native wire format only. ipf(4) looks at packets before IPsec processing on inbound, and after IPsec processing on outbound.


Auch unter Linux (Kernel 2.6) und OpenBSD/pf gibt es zu diesem Thema einige Threads die ich gefunden habe, aber leider noch keine saubere generelle Lösung dafür, bis auf einige Patches.

Tut mir leid, aber an der Stelle kann ich Dir dann auch nicht mehr weiterhelfen.
 
Etwas OT:
Kann man dieses m0n0wall auch auf einem existierenden FreeBSD Rechner installieren? Ohne quasi das Image zu booten. Ich habs schon in den Ports gesucht, aber nix gefunden...
 
Hi Alexco,

wenn ich Deine Frage richtig verstehe, willst Du m0n0wall quasi als Applikation starten. Habe zu wenig FreeBSD Erfahrung, als daß ich das mit Bestimmtheit sagen kann. Vielleicht kennen die Cracks hier einen Kniff' ala "chroot".

Wenn Du aber nur mal schnuppern willst, dann könnte http://m0n0.ch/wall/download.php?file=cdrom-1.1.iso was für Dich sein. Ist nämlich auch von CD lauffähig, während die Konfiguration auf Floppy gesichert wird. Läuft prächtig bei einem Kunden von uns. Nur als Testsystem ist es etwas nervig, wenn die ständigen Änderungen immer erst auf die Floppy geschrieben werden, was halt dauert.

Gruß,

H.
 
Zuletzt bearbeitet:
Zurück
Oben