nat, ipsec und pf

13/10/2008 - 19:13 von hh_usenet | Report spam
Ich habe hier (FreeBSD 7) ein pf(4), das Pakete filtert, NAT macht, mit
route-to ins Routing eingreift etc. Weiters habe ich ipsec, das mir zu
einem befreundeten, privaten Netz einen Tunnel sichert. Funktioniert
soweit.

Jetzt habe ich einen weiteren Tunnel, der aber bei mir (und am anderen
Ende) geNATete (sorry. Adreßgefàlschte?) Endpunkte haben soll, da unser
beide private Netze die jeweilige Gegenseite nichts angehen. (bzw.
einfach nicht geroutet werden sollen)

Nun zum Problem: Wenn ich wie gewohnt in der pf.conf ein "nat on gifx
from drinnen to drüben -> (gifx)" reinschreibe und racoon/setkey einen
tunnel "spdadd mein_endpunkt sein_endpunkt any -P out ipsec
esp/tunnel/meine_öffentliche-seine_öffentliche/require;" (und umgekehrt)
bauen lasse, werden zwar die Pakete richtig geroutet, neNATed und
gekapselt, aber nicht verschlüsselt. Obwohl ein Tunnel(SA) aufgebaut
wird.

Wenn ich man 4 ipsec (OpenBSD 4.3) richtig lese, dann müssten die zu
verschlüsselnden Pakete identifiziert werden, bevor sie NAT passieren:


NAT can also be applied to enc# interfaces, but special care should be
taken because of the interactions between NAT and the IPsec flow match-
ing, especially on the packet output path. Inside the TCP/IP stack,
packets go through the following stages:

UL/R -> [X] -> PF/NAT(enc0) -> IPsec -> PF/NAT(IF) -> IF
UL/R <-- PF/NAT(enc0) <- IPsec <- PF/NAT(IF) <- IF

With IF being the real interface and UL/R the Upper Layer or Routing
code. The [X] stage on the output path represents the point where the
packet is matched against the IPsec flow database (SPD) to determine if
and how the packet has to be IPsec-processed. If, at this point, it is
determined that the packet should be IPsec-processed, it is processed by
the PF/NAT code.



Allerdings haben sie da noch die privaten Absenderadressen, für die es
keine passende SPD gibt. Denn racoon matcht ja gegen die beiderseits
bekannten, publizierten Tunnelendpunkte, die eben nicht privat sind,
somit definieren die SPDs die Paketselektion _nach_ dem NAT.

Irgendwie erinnert mich das an diese Situation:
<http://groups.google.com/group/luck...ad/thread/
3ee49d6085755642/e774693d73887e8d?hl=en&lnk=st&q=ipsec+pf+encrypt+nat+sp
d+problem#e774693d73887e8d>

Was mach ich jetzt?

cheers
Heimo

stell dir vor, es ist krieg und keiner geht hin.
 

Lesen sie die antworten

#1 hh_usenet
22/10/2008 - 03:57 | Warnen spam
Heimo Hetl wrote:

[...] richtig geroutet, neNATed und
gekapselt, aber nicht verschlüsselt. Obwohl ein Tunnel(SA) aufgebaut
wird. [...]



Ok, nachdem ich damit jetzt substanziell viel meiner unbezahlten
Freizeit verschi en habe, will ich meine Lösung (oder Workaround)
wenigstens auch unbezahlt kundtun. Vielleicht fàllt ja jemandem noch was
besseres ein.

Ich habe alle NAT Regeln für diese Verbindung aus pf.conf entfernt,
ebenso explizit alle "keep state" Anweisungen, die diesen Pfad
betreffen.

Danach ipfw dazuinstalliert, dort zwei passende divert-Regeln zu einem
auf das Tunnelinterface gelegten natd eingerichtet. Örks.

Die ipfw ist generell auf Durchzug gestellt, im pf müssen das gif und
das enc Interface geskippt werden. Filtern kann man nur noch auf dem
internen Interface, aber das reicht für meinen Anwendungsfall.


cheers


Ingrid

stell dir vor, es ist krieg und keiner geht hin.

Ähnliche fragen