VPN -- Pre-shared Keys

[Breezer]

Hallo Forum, ich lese mich z.Z. in die Geheimnisse eines öffentlichen Schllüsselaustausch ein, habe zu Testzwecken auch freeswan laufen und würde gerne ein VPN mit pre shared Keys aufbauen.

Vorab habe ich dazu einige Fragen,

Freeswan generiert den pre shared Key durch die datei ipsec.secrets
müssen diese Dateien identisch bei den vpn Partnern vor einem Austausch
vorliegen??
somit besitzen alle Instanzen denselben pre shared Key???
oder ist das egal welche eigenen pre shared keys die Instanzen besitzen.
wie wird ein neuer pre shared key erzeugt ?? hatte meine ipsec.secrets aus versehen gelöscht.
hat die datei ipsec.secrets ein best. Layout ? oder steht da nur der erzeugte schlüssel drin?

Gruß und thx,

[zottel]

hi,

freeswan generiert keine keys aus der ipsec.secret. es
ist vielmehr der key für isakmp. Anschliessend werden
die keys time etc für ipsec ausgehandelt.

es müssen keine identische dateien vorliegen. Pro partner
muss es eine zeile geben mit dem eintrag

ip(partner1) ip(partner2) preshared_key

einen neuen key kannst du einfach eintragen - natürlich
auch beim partner den gleichen ;)

wenn beide partner dynamische adressen haben ist es essig
mit preshared key. du solltest x.509 dir anschauen.

[Breezer]

Hallo Zottel , thx ,

ist ja schon so ein Manko die gleichen Pre shred keys aus den Systemen einzusetzen, die müssen also erst mal sicher zwischen den Systemen übertragen werden PGP etc ..

habe freeswan 1.97 laufen habe mal von so einem x509 patch gehört wird der ab einer bestimmten Version nicht mehr benötigt?

habe die beiden VPN mit Site 2 Site Gateways richtig konfiguriert,
leider kann ich direkt von den GW's keinen Netzteilnehmer im privaten Netz erreichen ( ping an einen TLN hinter dem rechten GW funzt nicht und ebenso vom rechten GW an den linken client ) nur eine
client - client Kommunikkation (ping) ist drin.

client - gateway---internet ---gateway ---client


hast Du eine Idee woran das liegen könnte??
Guss

[zottel]

moin,

ja es funktioniert nur dann mit den gw wenn du die
richtige sourceadresse mitlieferst. ein

ping -I ip(internerKarte) dst_ip

sollte funktionieren. Falls du auch die externe
Karte als in den Tunnel einbeziehen möchtest
musst du einen neuen Tunnel definieren, der
die beiden gw enthält.

Ab welcher Version der x.509 nicht gebraucht wird -
leider keine Ahnung. Ich brauche ihn immer ist mir
symathischer als preshared ;)


Bye
zottel

[Breezer]

Moin Zottel , danke für die Antwort aber habe trotzdem noch Klärungsbedarf

warum ist Deine expliziete Ping -i nterface Beschreibung, notwendig ?

wenn der lokale Routingmehanismus erkennt das für eine Zustellung in das entfernte Private Adressnetz eine Shnitstelle IPSEC vorhanden ist und passt wird diese automatisch gewählt.

das Device IPSEC ist ja eine Pseudoschnittstelle die die tunnelmäßigen Veränderungen zur Verfügung stellt.

ein IP Forwaring sollte ebenfalls bei dieser IPSEC Schnittstelle greifen warum also zwei VPN Tunnel für ein GW?

----interne Schnittstelle IPSEC Schnittstelle--
--------------externe Schnittstelle---------------


Austrittspunkt und Eintrittspunkt des VPN's ist immer die IPSEC
Schnittstelle, was anschließend mit dem Paket passiert, eine lokale Behandlung oder ein forwarding sollte doch durch Auswertung der Dest.Adresse möglich sein, wie sollte denn noch ein zusätzlicher Tunnel definiert werden ?? durch interfaces="ipsec0=eth0,ipsec1=eth1" ? also expliziet für beide Interfaces?

gruß & thx

[zottel]

moin,

ich stimme dir zu das freeswan es erkennen sollte tut es
aber nicht. Bei der Definition von left bzw rightsubnet
gibst du doch die internen Adressen an richtig? Diese
sind doch aber andere als die externen oder? Ein Packet
welches nun über die externe Karte herausgeschickt wird
bekommt normalerweise immer als Sourceadresse die Adresse
des externen Interfaces. Dieses ist aber in deiner
Tunneldefinition nicht vorhanden. Du kannst entweder einen
zweiten Tunnel (gleiches dev ipsec0 aber neue connection) definieren
oder aber die Routingtabelle so umbiegen, das die Sourceadresse
wenn sie über das ipsec0 geht als intern gekennzeichnet wird.

klarer?

[Breezer]

thx, kann dir folgen wenn auch nur in einigem Abstand ;-)

wenn die interne source adresse bei der Paketweiterleiterleitung geändert wird , wird zuvor die IPSe SA befragt dies entscheidet wie das Paket zu behandeln ist eine Umsetzung der privaten Adresse auf die externe ist meiner Meinung für das gekapselte ( nicht für den externen IP Kopf ) nötig , da

1. Das Paket ist sowiso werschlüsselt das gekapselte Paket ist ist meiner somit nicht sichtbar und auswertbar

2. trifft ein Paket ein muß eine zuordnung an den internen Klienten erfolgen

könntest Du mir mal die speziellen Änderungen schreiben anhand eines beispiels schreiben,

thx, Gruß

[zottel]

hi breezer,

ich weiss jetzt nicht was für Änderungen du jetzt meinst.
Ich versuchs mal:


int_ip1 interne ip des gw1
|
gw1
|
ext_ip1 externe ip des gw1
|
internet
|
ext_ip2 externe ip des gw2
|
gw2
|
int_ip2 interne ip des gw2


Deine Tunneldefinition sieht so aus:
left=ext_ip1
leftsubnet=netz(int_ip1)
rightsubnet=netz(int_ip2)
right=ext_ip2

möchtest du nun von left nach rightsubnet dann
nimm diese tunneldefinition hinzu
left=ext_ip1
rightsubnet=netz(int_ip2)
right=ext_ip2

von right nach leftsubnet folgende
left=ext_ip1
leftsubnet=netz(int_ip1)
right=ext_ip2

und von den gw1 nach gw2 folgende
left=ext_ip1
right=ext_ip2


wie du erkennst definierst du immer den gw als einzelnen
rechner gegen ein subnet. Damit gehts dann ohne Änderung
der src ip der Packete. Es sollte auch mit ip route
gehen und die src Adresse zu ändern. Allerdings habe
ich das noch nicht ausprobiert und ich bin mir ziemlich
sicher, das freeswan am kernel vorbei routet.

Ich hoffe dieses Beispiel, übrigens aus der FAQ, hat
dir geholfen. Wenn nicht einfach weiterfragen ;)

Bis denne
zottel

[Breezer]

Hi Zottel, werde morgen mal Deinen Vorschlag ausprobieren,

es wird also noch zwei zusätzliche verbindung in
connection specifications Beschreibung ,
zu der bereits bestehenden angelegt ...

(insgesamt also 3 mögl. Verbindungen)
1. gw <-> gw
2. left subnet -> rightsubnet
3. right subnet -> left subnet

wie von Dir beschrieben...

Deine Tunneldefinition sieht so aus:
left=ext_ip1
leftsubnet=netz(int_ip1)
rightsubnet=netz(int_ip2)
right=ext_ip2

möchtest du nun von left nach rightsubnet dann
nimm diese tunneldefinition hinzu
left=ext_ip1
rightsubnet=netz(int_ip2)
right=ext_ip2
....

--------------------

Gruss