ipsec und nat

speedball

Member
Hi,
ich hab folgendes Problem:

Ich hab ein OpenBSD 3.3 Gateway mit isakmpd laufen. Die Kiste läuft mit 3 NICs. Mein Ziel ist es einen Client übers Internet einen Tunnel aufbauen zu lassen um dann mit dem LAN zu kommunizieren. isakmpd und pf sind auf dem Gateway fertig konfiguriert und funktionieren auch für das interne VPN, welches aus WLAN Clients besteht. Der Client, der aus dem Internet einen Tunnel aufbauen soll, ist eine Win 2000 Mühle ohne zusätzliche VPN Software, also nur mit dem nativen IPSec von M$ (ich weiss, nicht das beste, aber so ist das Leben). Derzeitiger Stand der Dinge ist, dass die Schlüssel ordentlich ausgetauscht werden und auf beiden Seiten die Verschlüsselten Tunnel angezeigt werden. Ich kann aber nicht vom Client ins LAN pingen, was wohl am NAT liegt, dass auf dem Gateway läuft. Setz ich aber einen Ping vom LAN zum Client ab, wird wohl eine Route ins NAT eingetragen, was mr "pfctl -s" anzeigt und ich kann dann auch vom Client zurück pingen und Ressourcen mappen (die gesamte Kommunikation ist auch ordentlich mit ESP verschlüsselt, was mir mein Sniffer anzeigt). Das ist aber leider nicht Sinn der Sache jedes Mal vom LAN zum Client zu pingen um die NAT Einträge zu aktualisieren, damit der Client kommunizieren kann. Was muss ich an der pf.conf ändern, damit es funzt ?????

Vielen Dank schonmal im vorraus ................
 
Original geschrieben von speedball
Hi,
ich hab folgendes Problem:


Dein Problem liegt erst mal in deiner Formulierung ... wie wäre es wenn du etwas Rücksicht auf die Augen der anderen hier im Forum achten würdest.

Du kannst nicht einfach so einen Batzen hinschmeißen und allen Ernstes denken, dass es jemand freiwillig lesen will!

Nehme es als ein freundliches Hinweis an.

Ich hab ein OpenBSD 3.3 Gateway mit isakmpd laufen. Die Kiste läuft mit 3 NICs.

Am besten immer eine Skizze posten ... sonst erschwert es erheblich das Nachdenken.

Immerhin willst du ja, dass dir jemand hilft, oder?

Also hilf du uns zuerst.

Mein Ziel ist es einen Client übers Internet einen Tunnel aufbauen zu lassen um dann mit dem LAN zu kommunizieren.

O.K.

isakmpd und pf sind auf dem Gateway fertig konfiguriert und funktionieren auch für das interne VPN, welches aus WLAN Clients besteht.

Das hat mit der Problemstellung nichts zu tun und gehört nicht hierher.

Es ist mir egal, wass du in deinem LAN drin hast.

Denn du hast im ersten Satz gesagt, dass du mit einem externen Client in dein LAN reinkommen willst.

Der Client, der aus dem Internet einen Tunnel aufbauen soll, ist eine Win 2000 Mühle ohne zusätzliche VPN Software, also nur mit dem nativen IPSec von M$ (ich weiss, nicht das beste, aber so ist das Leben).

Hört mit diesem Sch.. auf ... es spielt keine Rolle, ob es eine Mühle, Karre, Sack, Ferrari, Porsche oder sonstwas ist!

Bleibe technisch, wenn du schon so viel hinschreibst.

Derzeitiger Stand der Dinge ist, dass die Schlüssel ordentlich ausgetauscht werden und auf beiden Seiten die Verschlüsselten Tunnel angezeigt werden.

Also kann ich davon ausgehen, dass du mit deinem externen Clienten mit deinem LAN bzw. zumindest deiner Firewall/Router kommunizieren kannst?

Ich kann aber nicht vom Client ins LAN pingen, was wohl am NAT liegt, dass auf dem Gateway läuft.

Woher willst du das denn wissen?

Und was hat das mit NAT zu tun?

NAT ist für die Adressübersetzung da und nicht fürs Filtern.

Vielleicht liegt es daran, dass du einfach alle Pings blockst.

Hast du schon mal deine pf.conf darauf überprüft?

Oder wie wäre es, wenn du deine Konfigs mal postest?

Setz ich aber einen Ping vom LAN zum Client ab, wird wohl eine Route ins NAT eingetragen,

Hast du dir denn nicht schon mal gedacht, dass dies deshalb möglich ist, weil du auf deiner Windows-Maschine eben keinen Paketfilter (wie z.B. PF) hast?


was mr "pfctl -s" anzeigt und ich kann dann auch vom Client zurück pingen und Ressourcen mappen (die gesamte Kommunikation ist auch ordentlich mit ESP verschlüsselt, was mir mein Sniffer anzeigt).

Also jetzt kannst du auf einmal pingen.

Das liegt daran, dass du eben mit deinem LAN ein State aufbaust, der in die interne Tabelle des PF eingetragen wird und alle anderen Datenpakete die dazugehören (incl. der Antwortpakete) durchgelassen werden.

Das ist aber leider nicht Sinn der Sache jedes Mal vom LAN zum Client zu pingen um die NAT Einträge zu aktualisieren, damit der Client kommunizieren kann. Was muss ich an der pf.conf ändern, damit es funzt ?????

Wie ich es schon mal gesagt habe: deine Windows-Maschine hat natürlich keinen PF. Deine anderen Maschinen schon.

Sehe in deinen pf.conf-Regeln nach, ob du nicht zu restriktiv vorgegangen bist.

Und bitte poste das nächste mal zumindest deine pf.conf, damit wir dir helfen können, denn sonst wird dies hier zu einer Rate-Stunde und das ist nicht angenehm.

Vielen Dank schonmal im vorraus ................ [/B]

CW
 
@CW

Man bist heute wieder gut gelaunt! Ich finde übrigends deine Schreibweise mit immer einer Leerzeile eine Katastrophe, nicht seine kompakte. Und dass du immer so viel (überflüssig) quoten musst macht die Übersichtlichkeit auch nicht gerade besser. DAS freiwillig zu lesen empfinde ich als nicht erwartbar.

Nu so als Anmerkung, aber back to topic.

Gruß, incmc
 
w2k ==> internet ==> fw --> lan

wenn ich das richtig verstanden habe.

flush die pf rules auf der fw und probier es nocheinmal.
zeig uns die routing table des w2k rechners nachdem der tunnel gebaut wurde.
dann zeig uns die routing table (w2k) nachdem du vom lan den w2k pinged hast.

ansonsten:
www.openbsd.de/ipsec/html
 
Original geschrieben von incmc
@CW

Man bist heute wieder gut gelaunt!


Das hat mit meiner Laune nichts zu tun, sondern damit, dass ich gerne jemandem helfen möchte und dafür natürlich erst einmal den Sachverhalt verstehen muss.

Und daher sollte man doch nicht in einem fetten Block schreiben.

Ich finde übrigends deine Schreibweise mit immer einer Leerzeile eine Katastrophe, nicht seine kompakte.

Dann bist du der erste, der damit Probleme hat.

Ich finde es viel angenehmer, wenn der Leser die Möglichkeit hat, schnell zu merken, wo ich aufhöre (und wo auch der Sinn des Satzes aufhört), damit er Pausen machen kann.


Aber, bitte, gebe mir einen Tipp, wie ich mich verbessern könnte.

Hilf du auch mir, wenn du schon Probleme damit hast.

Immerhin musst du mich als OpenBSD-Mod "ertragen". :)

Und dass du immer so viel (überflüssig) quoten musst macht die Übersichtlichkeit auch nicht gerade besser.

Kannst du mir bitte sagen, nach welchen Kriterien du hier das "Überflüssige" von "Wichtigen" trennst.


DAS freiwillig zu lesen empfinde ich als nicht erwartbar.

Was zu lesen?

Nu so als Anmerkung, aber back to topic.

Gruß, incmc [/B]

Anmerkung angenommen und meine eigene hinzugefügt.

CW
 
@CW

Komm, "der Böse" stand mal bei dir und dein erstes Posting war schon "böse", auch wenn ich natürlich ein wenig verstehe was du meinst :D

Ich finde einfach, dass (ich suche jetzt nicht kleinlich nach Bsp) manchmal zu viel / zu kleinlich gequotet wird (allgemein). Man muss doch nicht zu jedem Furz nen Quote machen. Man könne auch einigermaßen zusammenliegende Bereiche als einen Quote machen, sonst wird die Antwort immer so lang und super unübersichtlich. Deine erste Antwort war bei mir 2,75 Bildschirme "lang" und das bei einer 1600x1200er Auflösung :(

Man muss aber auch sagen, dass hier im Forum das Quoten selbst schon irre Platz frisst von der Formatierung. Evtl. könnte man das in den Bulletin Board Einstellungen knapper machen. Ansonsten ist hier auch alles sehr effizient dargestellt.
Da ist aber noch ein anderer Grund: Bei mir sind aufgrund der Auflösung die Postings immer sehr breit gezogen. Wenn ich den Browser kleiner mache, rücken die Texte wieder mehr zu Blöcken zusammen (so wie es beim tippen hier in der Textbox auch aussieht). Könnte man auch im Board ändern, so von wegen, ey nie mehr als 80 Zeichen pro Zeile anzeigen.

Sicher, bei riesen Texten ist es doof eng zu schreiben, aber da kann man dann entsprechend auch mal nen Absatz machen wenn man zu einem anderen Themenbereich kommt.
Ich empfinde es einfach als nervig riesige durch platzfressende Maßnahmen aufgeblähte Postings zu lesen. Man verliert auch dadurch schnell wieder den Überblick. "Was hat er oben noch mal geschrieben" und schwup muss ich wieder 2 Seiten hochscrollen, mal ganz davon zu schweigen wenn ich zu einer anderen Antwort möchte.

So, alles weitere als private Nachricht. Das gehört nun echt nicht mehr hier her...

Gruss und raus, incmc
 
Original geschrieben von incmc
@CW

Komm, "der Böse" stand mal bei dir und dein erstes Posting war schon "böse", auch wenn ich natürlich ein wenig verstehe was du meinst :D

Es war Kritik und keine Bosheit. Auch wenn ich zugeben muss, dass ich nicht zu den Menschen (ja ich bin auch einer) gehöre, die sich unbedingt viel Mühe geben, "sanft" zu reden.

Das worauf es ankommt ist die Präzision, denn es geht um Technik.

Man muss doch nicht zu jedem Furz nen Quote machen.

Das was meine Gesprächspartner posten, halte ich normalerweise nicht für einen "Furz". Natürlich kannst du ruhig dies anders sehen.

Außerdem ist es meistens so, dass ich sie ermahne und diese es dann auch kapieren.

Man könne auch einigermaßen zusammenliegende Bereiche als einen Quote machen, sonst wird die Antwort immer so lang und super unübersichtlich. Deine erste Antwort war bei mir 2,75 Bildschirme "lang" und das bei einer 1600x1200er Auflösung :(

Dein Thema war nicht gerade einfach.

Das ist nicht meine Sache, wie die Auflösung bei dir aussieht.

Man postet, wenn man was zu sagen hat und nicht, weil man auf einem Bildschirm gut aussehen möchte.

Man muss aber auch sagen, dass hier im Forum das Quoten selbst schon irre Platz frisst von der Formatierung. Evtl. könnte man das in den Bulletin Board Einstellungen knapper machen. Ansonsten ist hier auch alles sehr effizient dargestellt.

Das ist ein technisches Thema und ich würde am besten einen neuen Thread anfangen. Vielleicht kann man was dagegen tun?

Da ist aber noch ein anderer Grund: Bei mir sind aufgrund der Auflösung die Postings immer sehr breit gezogen. Wenn ich den Browser kleiner mache, rücken die Texte wieder mehr zu Blöcken zusammen (so wie es beim tippen hier in der Textbox auch aussieht). Könnte man auch im Board ändern, so von wegen, ey nie mehr als 80 Zeichen pro Zeile anzeigen.

Mache einen neuen Thread auf und/oder wende dich an die beiden Admins des Boards.

Ich empfinde es einfach als nervig riesige durch platzfressende Maßnahmen aufgeblähte Postings zu lesen.

Und ich empfinde es als störend, wenn die ganzen Sachverhalte in einem Batzen hinplatziert werden.

Man verliert auch dadurch schnell wieder den Überblick.

Und ich bekomme bei der anderen Schreibweise nicht einmal einen!

"Was hat er oben noch mal geschrieben" und schwup muss ich wieder 2 Seiten hochscrollen, mal ganz davon zu schweigen wenn ich zu einer anderen Antwort möchte.

Nun, bei gequoteten Sachen, ist dies einfacher, da du ja feste "Grenzen" hast. Während du bei einem Block erst einmal das Wichtige vom Unwichtigen trennen musst, was Zeit und Kraft kostet.

So, alles weitere als private Nachricht. Das gehört nun echt nicht mehr hier her...

Gruss und raus, incmc [/B]

Besser wäre es, einen Thread aufzumachen.

Dann können andere mitmachen.

Gruß

CW
 
Ich konnte das Problem soweit zurückverfolgen:

Wenn ein Client aus dem LAN versucht den Win Rechner im Internet zu pingen funktioniert es. "pfctl -s state" zeigt den State als:

Lan gateway IP -> Default Gateway IP -> Remote Host IP MULTIPLE:MULTIPLE

Solange dieser State besteht funktioniert der VPN Tunnel von beiden Seiten aus!
Geht der Ping aber vom Remote Rechner im Internet aus zeigt "pfct -s state":

esp LAN GW Ip <- 48.0.2.212 <- Remote Host IP NO TRAFFIC:SINGLE

Wobei die 48.0.2.212 natürlich unsinn ist und ich nicht weiss woher sie kommt. Bei jedem Neuaufbau ändert sich die Adresse in eine andere unsinnige.

Das ganze sieht dann so aus das der Rechner, der im LAN angepingt wird den PING auch bekommt aber die Antwort verloren geht.


Meine pf.conf (192.168.1.77 = Internes GW):

rdr on $WAN proto esp from $WAN to any -> 192.168.1.77

rdr on $WAN proto udp from any to any port 500 -> 192.168.1.77 port 500
nat on $WAN inet from $NAT to any -> ($WAN)

pass in quick all keep state
pass out quick all keep state

das erste redirect hab ich auch durch ein binat ausgetauscht, keine Änderung.

Jetzt habe ich einem posting gelesen, dass es ähnliche Probleme auf Grund eines Bugs in pf gab und die in Current wohl behoben sein müssten. Falls einer KONSTRUKTIVE Vorschläge, ausser dem upgrade zu bieten hat : danke
 
Original geschrieben von speedball

rdr on $WAN proto udp from any to any port 500 -> 192.168.1.77 port 500

Warum machst du hier ein Redirect der Normalen UDP-Pakete.

Port 500 ist nur für ESP vorbehalten. Und bei ESP wird eh alles verschlüsselt (egal ob TCP, UDP, ICMP).

Du solltest diese Regel rauswerfen. Außerdem musst du wissen, dass die NAT und REDIRECT-Regeln nicht wie die übrigen nach der Richtlinie: last matching rule wins, sondern: first matching rule wins ausgewertet werden.

Also: die zweite Redirect-Regel brauchst du nicht, da alles ohnehin verschlüselt wird.

CW
 
Original geschrieben von speedball
Die brauche ich für den Schlüsselaustausch. Nehme ich sie raus, kommt keine Tunnel zu stande.

Wäre es möglich, das du die GANZE pf.conf postest, damit ich weiß, was $WAN ist usw.

Weil ich mir ziemlich sicher bin, dass es mit den RDR/NAT-Regeln zu tun hat.

CW
 
WAN="tun0"
LAN="sis2"
DMZ="sis1"
Loopback = "lo0"
WLAN="wi0"

NAT = "{'192.168.1.0/24' '192.168.2.0/24'}"

#scrub in all no-df
#scrub out all no-df

rdr on $WAN proto esp from $WAN to any-> 192.168.1.77
rdr on $WAN proto udp from any to any port 500 -> 192.168.1.77 port 500
nat on $WAN inet from $NAT to any -> ($WAN)

pass in quick all keep state
pass out quick all keep state
 
Und falls du deine pf.conf aus welchen Gründen auch immer nicht posten möchtest, kann ich dir noch diese Website nennen: http://www.openbsd.de/ipsec/onehtml/

Aber ich bin mir fast sicher, dass es mit den RDR/NAT-Regeln zu tun hat.

Bestimmt wird da ein Interface anstelle eines anderen Gefiltert.

Nur weiß ich ja nicht, welches, weil ich die Variablenwerte nicht kenne.

CW
 
Wie wäre es, wenn du eine ICMP-Regel einbaust, die ICMP auf dein Gateway umleitet bzw. an die Clients die du angepingt haben willst?

CW
 
Ich denke das ist nicht nötig. Ich setze z.B. ein Ping auf 192.168.1.22 ab.
Auf diesem Rechner läuft ein Sniffer, der mir die ICMP Pakete auch ordentlich anzeigt, was ja ein Zeichen dafür ist, dass die Weiterleitung an die LAN Clients funktioniert.
Die Antwort des LAN Clients geht aber dann verloren, was dann wohl an der dubiosen IP in "pfctl -s state" liegt.

Wenn ich pfclt mit -x misc starte, dann gibt er mir auch folgende Fehlermeldungen:

pf: state insert failed: tree_lan_ext lan: 192.168.1.77 gwy: 104.202.127.214 ext: 213.7.208.9

104.202.127.214 ?????
 
Original geschrieben von speedball
Ich denke das ist nicht nötig. Ich setze z.B. ein Ping auf 192.168.1.22 ab.


Es ist schon klar, dass dies nicht notwendig ist. Ich habe es aus Debugging-Gründen vorgeschlagen, damit auf alle Fälle sichergestellt wird, dass die ICMP-Pakete "geschnappt" werden.

Wenn ich pfclt mit -x misc starte, dann gibt er mir auch folgende Fehlermeldungen:

pf: state insert failed: tree_lan_ext lan: 192.168.1.77 gwy: 104.202.127.214 ext: 213.7.208.9

104.202.127.214 ????? [/B]

Ich glaube langsam, dass der PF selbst wohl ein Problem hat.

Schicke doch diese Meldung an die OpenBSD-Mailingliste.

Vielleicht haben sie was genaueres darüber.

CW
 
NACHTRAG

Original geschrieben von speedball

pf: state insert failed: tree_lan_ext lan: 192.168.1.77 gwy: 104.202.127.214 ext: 213.7.208.9

104.202.127.214 ?????

Das Problem liegt daran, dass ein falsches Gateway für die 192.168.1.77 gesetzt wird.

Daher können auch die Pakete nicht mehr ankommen.

CW
 
Hallo,

ich habe auch einen OBSD-Router laufen. Ich habe zwei VPN's darauf eingerichtet.
Beide laufen tadellos sogar zusammen.

Also erstmal zu den Adressen:
Ist der Win-Client in einem anderen Subnetz? Dann musst du natürlich auf dem Router eine eigene Route dafür anlegen.
Zu den Regeln:

Es muss UDP Port 500 freigeschaltet sein
proto ESP muss freigeschaltet sein.
Da ESP selbst ein PROTOKOLL ist hat es nichs mit TCP, UDP oder ICMP zu tun.

Mann braucht dafür keine RDR/NAT Regeln, da man ja in das Netzwerk eingebunden wird. Ist ja Sinn der Sache.

Es muss nur die Route stimmen.

Bei Bedarf kann ich mal meine pf.conf und Routing Table posten.

Gruß
atarianer
 
@CW
hast recht ESP ist ein Aufsatz und kein eigenes Protokoll, mein Fehler.

Hier mal meine Routing Table:

Routing tables

Internet:
Destination Gateway Flags Refs Use Mtu Interface
default 217.5.98.156 UGS 3 17409227 1492 tun0
127/8 127.0.0.1 UGRS 0 0 33224 lo0
127.0.0.1 127.0.0.1 UH 2 0 33224 lo0
192.168.0/24 link#1 UC 0 0 - vr0
192.168.0.2 127.0.0.1 UGHS 2 0 33224 lo0
192.168.1/24 192.168.0.2 UGS 0 11 - vr0
192.168.2/24 192.168.0.2 UGS 0 26 - vr0
192.168.60/24 link#2 UC 0 0 - rl0
217.5.98.156 80.138.240.45 UH 1 0 1492 tun0
224/4 127.0.0.1 URS 0 0 33224 lo0

rl0 ist die ext. NIC
vr0 die interne
192.168.1 und 192.168.2 sind die beiden angekoppelten VPN's
Wichtig ist dann natürlich das Gateway

Die pf.conf poste ich noch

atarianer
 
Original geschrieben von speedball
WAN="tun0"
LAN="sis2"
DMZ="sis1"
Loopback = "lo0"
WLAN="wi0"

NAT = "{'192.168.1.0/24' '192.168.2.0/24'}"

#scrub in all no-df
#scrub out all no-df

rdr on $WAN proto esp from $WAN to any-> 192.168.1.77
rdr on $WAN proto udp from any to any port 500 -> 192.168.1.77 port 500
nat on $WAN inet from $NAT to any -> ($WAN)

pass in quick all keep state
pass out quick all keep state

Baue diese Regeln mal ein:

pass in quick on $WAN proto udp from $DEIN_CLIENT to $DEIN_GATEWAY port = isakmp
keep state
pass out quick on $WAN proto udp from $DEIN_GATEWAY to $DEIN_CLIENT port = isakmp
keep state

Du muss nur doch die Variablen setzen, damit es bei dir klappt.

Ich habe diese Regeln von der einen Website, die ich dir gepostet habe. :)


Gruß

CW
 
@speedball:
kannst du mal deine Route senden
einmal mit netstat -rnf inet
und einmal mit netstat -rnf encap
letzteres bei aufegebautem Tunnel.

@cw
muss mich nochmal korrigieren.
Du hast recht, es ist ein Aufsatz. Trotzdem ist ESP ein Protokoll und es sind dann keine TCP oder UDP Pakete mehr, da sie verschlüsselt sind und einen neuen IP-Header bekommen.
Außerdem hat ESP ja eine eigene IP-Protokoll-Nummer.

atarianer
 
Original geschrieben von atarianer
[B@cw
muss mich nochmal korrigieren.
Du hast recht, es ist ein Aufsatz. Trotzdem ist ESP ein Protokoll und es sind dann keine TCP oder UDP Pakete mehr, da sie verschlüsselt sind und einen neuen IP-Header bekommen.
Außerdem hat ESP ja eine eigene IP-Protokoll-Nummer.

atarianer [/B]

Und noch genauer: IPSec ist nur ein Bestandteil von IPv6. Und weil IPv6 immer noch auf sich warten lässt, ist man auf die Idee gekommen, diesen einen Bestandteil von IPv6 auf IPv4 zu übertragen, um die standardmäßig nicht vorhandenen Security-Features (Authentikation, Integrity usw.) zu bekommen.

Gruß

CW
 
Hier mal die pf-Konfiguration

Allerdings muss ich noch klarstellen, daß ESP verschlüsselte Pakete nicht geNATed werden können, da der Hash den IP-Header mit einbezieht (Jedenfalls bei Standard IKE und AH). Also muss das VPN auf jedenfall auf dem Router/Gateway gemacht werden.

# VPN
pass in quick on tun0 proto udp from any to any port 500
für den Key-Exchange

pass in quick on tun0 inet proto esp from any to any
pass out quick on tun0 inet proto esp from any to any

für den Tunnel

pass in quick on enc0 proto tcp all
pass out quick on enc0 proto udp all

Filter innerhalb des Tunnels
 
Zuletzt bearbeitet:
Zurück
Oben