PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : VPN mit IPSec -> Verbindung steht , trotzdem kein Zugriff



ReSeT
12.10.02, 13:16
Hallo zusammen!

Ich habe heute eine VPN Verbindung mit FreeS/WAN 198.b eingerichtet, die wie folgt konfiguriert wurde:

2 x Debian Router (3.0.-2.4.18 mit jew. 2x RTL8139)

Die Firewall (iptables 1.27) habe ich entsprechend angepasst, die VPN Verbindung kommt auch ordnungsgemäß zustande,+
wie mir 'ipsec whack --status' zeigt:

Gateway 1:


000 interface ipsec0/ppp0 80.133.11.32
000
000 "hrshop-reset": 10.0.0.0/24===80.133.11.30[@vpngate1.dnsalias.net]---217.5.98.47...195.14.220.1---195.14.222.100[@vpngate2.dnsalias.net]===10.0.1.0/24
000 "hrshop-reset": ike_life: 3600s; ipsec_life: 28800s; rekey_margin: 540s; rekey_fuzz: 100%; keyingtries: 3
000 "hrshop-reset": policy: RSASIG+ENCRYPT+TUNNEL+PFS+DISABLEARRIVALCHECK; interface: ppp0; erouted
000 "hrshop-reset": newest ISAKMP SA: #8; newest IPsec SA: #9; eroute owner: #9
000
000 #9: "hrshop-reset" STATE_QUICK_R2 (IPsec SA established); EVENT_SA_REPLACE in 27200s; newest IPSEC; eroute owner
000 #9: "hrshop-reset" esp.f1412b43@195.14.222.100 esp.3d35822c@80.133.11.30 tun.1008@195.14.222.100 tun.1007@80.133.11.30
000 #8: "hrshop-reset" STATE_MAIN_R3 (sent MR3, ISAKMP SA established); EVENT_SA_REPLACE in 2000s; newest ISAKMP
000

Gateway 2:



000 interface ipsec0/ppp0 195.14.222.102
000
000 "hrshop-reset": 10.0.1.0/24===195.14.222.100[@vpngate2.dnsalias.net]---195.14.220.1...217.5.98.47---80.133.11.30[@vpngate1.dnsalias.net]===10.0.0.0/24
000 "hrshop-reset": ike_life: 3600s; ipsec_life: 28800s; rekey_margin: 540s; rekey_fuzz:
100%; keyingtries: 3
000 "hrshop-reset": policy: RSASIG+ENCRYPT+TUNNEL+PFS+DISABLEARRIVALCHECK; interface: ppp0; erouted
000 "hrshop-reset": newest ISAKMP SA: #7; newest IPsec SA: #8; eroute owner: #8
000
000 #8: "hrshop-reset" STATE_QUICK_I2 (sent QI2, IPsec SA established); EVENT_SA_REPLACE in 26882s; newest IPSEC; eroute owner
000 #8: "hrshop-reset" esp.3d35822c@80.133.11.30 esp.f1412b43@195.14.222.100 tun.1008@80.133.11.30 tun.1007@195.14.222.100
000 #7: "hrshop-reset" STATE_MAIN_I4 (ISAKMP SA established); EVENT_SA_REPLACE in 1512s; newest ISAKMP
000


Ich bin alle Hinweise in der FreeS/WAN Doku durchgegangen, alles scheint korrekt, die Firewall habe ich zu Testzwecken
komplett geöffnet.

Die Routen von Gate 1:



Kernel IP Routentabelle
Ziel Router Genmask Flags Metric Ref Use Iface
217.5.98.47 * 255.255.255.255 UH 0 0 0 ppp0
217.5.98.47 * 255.255.255.255 UH 0 0 0 ipsec0
10.0.0.0 * 255.255.255.0 U 0 0 0 eth0
10.0.1.0 217.5.98.47 255.255.255.0 UG 0 0 0 ipsec0
default 217.5.98.47 0.0.0.0 UG 0 0 0 ppp0


Und von Gate 2:




Kernel IP Routentabelle
Ziel Router Genmask Flags Metric Ref Use Iface
xdsl-195-14-220 * 255.255.255.255 UH 0 0 0 ppp0
xdsl-195-14-220 * 255.255.255.255 UH 0 0 0 ipsec0
localnet xdsl-195-14-220 255.255.255.0 UG 0 0 0 ipsec0
10.0.1.0 * 255.255.255.0 U 0 0 0 eth0
default xdsl-195-14-220 0.0.0.0 UG 0 0 0 ppp0



Die Syslogs zeigen sich auch so, wie in der Doku angegeben.

Ich habe allerdings mit tcpdump herausgefunden, daß zwar (bei Ping z.B) die Pakete fürs gegenüberliegende
Netz tatsächlich auf das Interface ipsec0 gehen, allerdings verlassen sie leider nicht das device ppp0, dementsprechend
kommt auf der anderen Seite nix an.

Ich weiss mir im Moment keinen Rat mehr, hat vielleicht jemand eine Idee woran das liegen könnte?

GreetZ

ein völlig ratloser

ReSeT

(IP-Adressen und Namen sind abgeändert)

ReSeT
13.10.02, 23:26
So wie's aussieht, bin ich nicht der einzige, der hier ratlos ist.

By the way: Die gleiche Geschichte passiert bei einem unverschlüsselten IP-Tunnel mit iproute2.

der Tunnel steht, aber es gehen keine Pings durch. Beim Nachsehen mit tcpdump das gleiche Ergebnis:
Die Pakete tauchen auf dem Tunneldevice auf, verlassen aber nicht ppp0, obwohl die Defaultroute
korrekt gesetzt ist.

Übersehe ich hier vieleicht ne Kleinigkeit?

ReSeT
14.10.02, 21:15
Öhm...



Ich frag' dann doch lieber mal ein paar Experten

ReSeT
14.10.02, 21:19
Juhuu, endlich ein Thread, der mir ganz alleine gehört :ugly:

Newbie2001
14.10.02, 21:36
hm, da dir hier scheinbar keiner nen tip geben kann, geb ich dir einen, der hat zwar nix mit ipsec zu tun aber ich geb ihn dir trotzdem: benutz openvpn, das is nich ganz so kompilziert wie ipsec und kann das gleiche.

ReSeT
14.10.02, 22:13
Schönen Dank, ich schau mir das mal an. :)

bertl
15.10.02, 10:29
Hi,

du machst doch bestimmt auf deiner xdsl-Seite masquerading? Da kannst du Probleme bekommen, wenn der router nicht eine Option hat, Ipsec-Pakete zu forwarden.

Gruß, bertl

ReSeT
15.10.02, 13:17
Ja, masquerading läuft auf beiden Seiten. Zu diesem Thema habe ich haufenweise sich gegenseitig widersprechende
Informationen gefunden. Prinzipiell ist mir klar, das zwischen zwei Subnetzen, die via VPN miteinander verbunden sind,
kein masquerading stattfinden darf. Diese Information finde ich auch in der c't 16/02 wieder. Die sagen allerdings,
wenn man mit iptables arbeitet, reicht es aus die entprechenden Ports für UDP Port 500 und das ESP Protokoll zu öffnen.
(Warum das so ist, darüber wird allerdings kein Wort verloren)

Ja was den jetzt? Ist das hier der Fehler? Oder vielleicht doch nicht? Und warum scheint dann der Tunnel zu stehen?

Kann mir das mal jemand erklären,denn mittlerweile blick ich da nicht mehr so richtig durch. :confused:

GreetZ

ReSeT

ReSeT
17.10.02, 17:16
Also, für alle, die das hier mit Interesse verfolgen:

Der Fehler lag tatsächlich beim MASQUERADING, es darf also unter gar keinen Umständen zwischen den
mit IPsec verbundenen Subnetzen maskiert werden. Demzufolge ist auch die Aussage der c´t Blödsinn (hach :D).

Der Eintrag im Firewallscript muss also wie folgt lauten:



iptables -A POSTROUTING -t nat -s $localnet -d ! $opposite_lan -j MASQUERADE


anstatt



iptables -A POSTROUTING -t nat -s $localnet -j MASQUERADE


Dann klappts auch mit dem Nachbarn :)

Allerdings habe ich noch herbe Performanceprobleme und mitunter Ping-Replys von bis zu 24000ms (!)

Aber das kriegen wir (mein EGO und ich) auch noch in den Griff.

GreetZ

ReSeT

habbom
17.10.02, 19:48
Hi reset,

ich hab Deinen :) thread verfolgt, da ich selber mit ipsec rumbastel, aber bei mir scheitert es schon an den einfachsten dingen
Nach welchen Anleitungen bist Du gegangen?
Performance, bist Du höher als 1024 bit mit dem Schlüssel gegangen ?

Ich hab ipsec installiert, dann wollte ich die zertifikate erstellen, Du hattest von der Ct geschrieben, habs mir angeschaut, aber leider nicht damit hinbekommen

ich bekomme meistens die Meldung, dass die serial die falsche Länge hat

Bei freeswan steig ich noch nicht so ganz durch die Anleitung,

bei uns ist es folgendermassen geplant
server mit fester IP 212.xxx.xx.xxx/27 (unsere Firma) Suse 8.1 mit aktuellem ipsec
mein Server mit variabler IP (ISDN-Flat, router, squid) dahinter mein zweiter interner server und meine Linux Wks, beides Suse7.3
außerdem noch ein Laptop mit variabler IP (übers I-net)
jetzt möchte ich von zuhause und unterwegs auf das Firmennetz zugreifen

Deinen Tip mit dem masq werde ich beherzigen, aber soweit muß ich erst einmal kommen :D

wenn Du ein paar Tips oder gute Anleitungen hast wäre ich dankbar

wie sieht Deine ipsec.conf bzw. Deine openssl.conf aus ? Wie hast Du die keys erstellt?

Gruß
Michael

ReSeT
17.10.02, 20:08
Hi!

Am besten hältst Du Dich wirklich an die Doku auf der FreeS/WAN Seite. Schritt für Schritt.
Alles andere hat sich bisher als Müll herausgestellt. (Und ich habe viele "Tips" und Newsgroups gesehen)

Wenn Du noch ein paar Tage Geduld hast, gebe ich Dir gerne die komplette Projektdoku, dann sollten auch die
Performanceprobleme ausgeräumt sein. (Zum gegenwärtigen Zeitpunkt führe ich diese auf die pppoe Clients zurück, offensichtlich läuft hier irgendein Buffer über, da die Ping-Replys mit jedem Ping anwachsen, bis nichts mehr geht)
Ausserdem muß ich noch anpassungen für dynamische DSL Anbindungen machen, damit die Verbindung auch dauerhaft stehen bleibt.

Die Schlüssel habe ich mit ipsec newhostkey > /etc/ipsec.secrets manuell erzeugt und via Copy und Paste
in die ipsec.conf eingetragen. (Standarmäßig ist der RSA 2192 Bits lang)

Die Konfigurationsdateien können 1 zu 1 von der FreeS/Wan Doku übernommen werden (am besten das Site-to-Site VPN)

Das Haarige an der Sache ist wohl die Konfig der Firewall, da hier doch relativ viel angepasst werden muss,
aber soweit habe ich ein gut konfigurierbares Script gebastelt. Kannst Du gerne haben wenn Du willst.
Ich plane noch eine Setuproutine in C zu schreiben inclusive Frontend und Schlüsselverwaltung für Roadwarrior,
damit soll sich dann alles einfach managen lassen (Ist aber bisher nur ne Idee ;) )

GreetZ

ReSeT

habbom
17.10.02, 20:25
danke für die Antwort,

ich werd mir wohl die Doku nochmal durchlesen, mit den dokus im Netz hast Du recht, ich hab mitlerweile diverse ausprobiert und Fehler waren in fast jeder.

Der Hintergrund ist halt, ein Kollege versucht das seit etwa 2 - 3 Monaten und verzweifelt langsam daran, da er in einer anderen Abteilung sitzt, dachte ich mir, daß ich ihn unabhängig von seinen Bemühungen unterstütze, nur durch einfaches abtippen komm ich nicht weiter.
Leider habe ich vom Programmieren keine Ahnung , kann ich Dich in Deinem Vorhaben nicht unterstützen, wäre aber über zukünftige Infos dankbar

Gruß
Michael

Harry
17.10.02, 21:08
Original geschrieben von ReSeT
Das Haarige an der Sache ist wohl die Konfig der Firewall, da hier doch relativ viel angepasst werden muss,
Was soll am Paketilfter so schwierig sein?
Du benötigst folgende Freigaben:
udp/500 <-> udp/500 (Managementtunnel)
ip/50 <-> ip/50 (ESP -> Verschlüsselte Datenübertragung)
ip/51 <-> ip/51 (AH -> Authentification Header, soweit der nicht bereit in ip/50 integriert ist)

Diese Datagramme müssen auf Client und Server ein- und ausgehen und Du bist fertig mit dem Paketfilter :D

Harry

ReSeT
17.10.02, 21:32
Ich hatte vorher mit iptables nicht viel am Hut und hab relativ lang gebastelt, bis ich ein allgemeingültiges Script hatte, deswegen 'haarig'. Ausserdem ist alles einfach, wenn man weiss, wie's geht. :) (Probier mal, daß deiner Oma zu erklären :D )

Harry
17.10.02, 21:33
Original geschrieben von ReSeT
(Probier mal, daß deiner Oma zu erklären :D )
Haarspalter :D

Harry

ReSeT
17.10.02, 21:35
Um das mal beim Schopf zu packen : Du hast doch damit angefangen :D

Harry
17.10.02, 21:44
Du findest aber auch immer ein Haar in der Suppe :D

Harry

ReSeT
18.10.02, 11:06
Ich glaub, wir reden grade haarscharf am Thema vorbei.... :cool:

Hotspott
03.07.03, 01:54
Hi ihr!

Bin auch gerade am Freeswan basteln. Ich werde mal openvpn anschauen. Ich will allerdings
Win XP Kisten verbinden daher muss ich erst gucken ob openvpn das kann.

Habe durch gedanken Anstoss von CT und shinewelt.de ein established in meiner /var/log/auth.log
nur pingen kann ich nicht.

Habe den Aufruf

iptables -A POSTROUTING -t nat -s $localnet -d ! $opposite_lan -j MASQUERADE

probiert. Dann bekomme ich aber den Fehler :

iptables v1.2.8: cannot have ! before -j
Try `iptables -h' or 'iptables --help' for more information.

Hast du die Variablen localnet und opposite_lan selbst vorbelegt?

Wie bekomme ich da nun eine Ping gebacken?