Archiv verlassen und diese Seite im Standarddesign anzeigen : FreeS/WAN auf zwei Router mit DynDNS. Endlich Klarheit
Hi@all,
ich habe die beiden letzten Wochen damit verbracht, zu versuchen zwei Netzwerke welche beide mittels einem Debian-Router (Firewall) an's Internet angebunden sind mittels FreeS/WAN zu verbinden. Hierzu habe ich mich durchs Web gegoogelt, Mailinglisten befragt und verschieden Heftartikel bemüht.
Das Ergebnis dieser Recherche hätte vewirrender nicht sein können. Ich habe ein paar Webseiten gefunden welche angeblich diese Problem behandeln. Teilweise standen die dort aufgeführten Paramtern jedoch mit anderen Dokus im Wiederspruch. Ein User in der Debian-Mailingliste schrieb mir das genau dieser Fall mit FreeS/WAN nicht funktionieren würde.
Das fand ich schade da ich, meiner Meinung nach, schon recht weit gekommen bin (soweit wie nie :D ). Nun wollte ich es genau wissen und meinen 'Plan' dem Linux-Magazin geschildert und die Antwort war für mich positiv. Ich poste einfach mal die Mail bzw. die Antwort.
Meine Mail:
++++++++++++++++++++++++++++++++++++++++++++++++++
Hallo Linux-Magazin-Team,
hier ist mal wieder der Ornitologe aus dem sonnigen Baden. Mit viel Interesse
habe ich mich auf den Artikel in der aktuellen Ausgabe (VPN & FreeS/WAN)
gestürzt. Nachdem ich die Installationshürde genommen hatte und mich auf die
Konfiguration gestürzt. Da bin ich jedoch auf Probleme gestoßen die ich so
nicht erwartet habe.
Dies soll keine Supportanfrage werden sondern ich erhoffe mir vielmehr eine
grundsätzliche Aussage darüber ob mein 'Plan' realisierbar ist.ei
Ich betreibe zwei LAN's die jeweils durch ein Linux-Router via DSL an das
Internet angebunden sind. Dies bedeutet das keiner der beiden Linux-Router
von extern über eine feste IP angesprochen werden kann sondern alle 24
Stunden eine neue IP bekommt, diese wird jedoch über DynDNS aufgelößt
(ddclient).
Ist es möglich die beiden genannten LAN's über FreeS/WAN, auf diesen beiden
Linux-Router, über das Internet zu verbinden ohne dabei den Clients in dem
LAN den unverschlüsselten Zugriff auf das Internet zu nehmen?
Viele Grüß
Sven Gehr
77815 Bühl/Baden
++++++++++++++++++++++++++++++++++++++++++++++++++
die Antwort:
Hallo Herr Gehr,
Leider ist die Installation von FreeS/WAN noch mit einigem Aufwand
verbunden, wie sie selbst festgestellt haben. Jedoch liefern bereits
einige Distributionen FreeS/WAN fix und fertig vorbereitet mit. Hierbei
handelt es sich meistens jedoch um die Version 1.99.
Zum zweiten Teil Ihrer Frage: Die Version 2.0, welche in dem Artikel
vorgestellt wurde, aktiviert per Default die opportunistische
Verschlüsselung (opportunistic encryption, OE). Diese versucht
grundsätzlich jedes nach außen gerichtete Paket zu verschlüsseln. Wird
diese Option nicht erwünscht, so sollte der Administrator die OE
abschalten
(http://www.freeswan.org/freeswan_trees/freeswan-2.02/doc/policygroups.html#disable_policygroups), um Verzögerungen in dem unverschlüsselten Verkehr zu vermeiden.
Zum ersten Teil Ihrer Frage: Ja es ist möglich die DynDNS-Informationen
für den Aufbau zu nutzen. Eine Anleitung hierfür ist entweder auf der
Webseite http://www.dr-lotz.de/freeSWAN-dyndns.html oder in meinem, in
wenigen Wochen erscheinenen, Buch zu finden.
Ich hoffe damit Ihre Fragen erschöpfend beantwortet zu haben.
Mit freundlichen Grüßen,
Ralf Spenneberg
--
Ralf Spenneberg
UNIX/Linux Trainer and Consultant, RHCE, RHCX
Waldring 34 48565 Steinfurt Germany
++++++++++++++++++++++++++++++++++++++++++++++++++
Nun weiß ich zumindest das es sich lohnt weiter Zeit in dies Sache zu stecken da ich weiß das es grundsätzlich geht.
Gruß Pixel
stefan-kfd
27.09.03, 09:52
Hallo,
also was du da vorhast ist kein Problem mit FreeSwan. Habe diese Konstellation seit längerem mehrfach im produktiven Einsatz. Bevor ich mir hier aber die Finger wund tippe: Hast du das Problem schon gelöst ? Wenn nicht wäre deine config und die iptables Regeln hilfreich.
Viele Grüße
Stefan
Hi@all,
Sorry das ich mich soooo spät melde. Ich habe das Problem leider noch nicht lösen können. Ich werde dir Morgen mal meine Config-Files posten.
Danke schonmal für's drüber schauen. Ich habe mir das VPN-Buch vorbestellt. Leider ist es noch nicht da.
Gruß Pixel
Hi@all,
also FreeS/WAN läuft bei mir auf der Firewall/Router wobei es wohl eben übertrieben ist bei dem System von einer Firewall zu reden, ist eher ein Linux-Softwarerouter der NAT macht.
Hier das Filterskript:
#!/bin/sh
# netfilterscript für router
echo "1" > /proc/sys/net/ipv4/ip_dynaddr
echo "1" > /proc/sys/net/ipv4/ip_forward
echo "1" > /proc/sys/net/ipv4/tcp_syncookies
iptables -F # flush aller chains (Tabelle filter)
iptables -t nat -F # flush aller chains (Tabelle nat)
iptables -X # flush aller user-chains (Tabelle filter)
iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE
iptables -I FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
und hier die ipsec.conf
version 2.0 # conforms to second version of ipsec.conf specification
# basic configuration
config setup
interfaces=%defaultroute
klipsdebug=none
plutodebug=none
conn %default
keyingtries=1
disablearrivalcheck=no
authby=rsasig
rightrsasigkey=%cert
auto=add
left=%defaultroute
leftcert=sphinxCert.pem
leftupdown=/usr/local/lib/ipsec/_updown.x509
conn p2p
right=komet.dyndns.org
conn n2n
right=komet.dyndns.org
rightsubnet=192.168.111.0/24
leftsubnet=192.168.0.0/24
conn block
auto=ignore
conn private
auto=ignore
conn private-or-clear
auto=ignore
conn clear-or-private
auto=ignore
conn clear
auto=ignore
conn packetdefault
auto=ignore
Sobald ich FreeS/WAN starte komme ich vom LAN her nicht mehr ins Internet??
Gruß Pixel
och das dürft doch nur ein routing problem sein
post doch mal deine routen
Gruß Temp
Nur als hinweis:
Mit Dyndns kannst du keine OE Verbindungen machen, da es dir der Dyndns Anbiteter nicht gestattet einen TXT Eintrag in deiner Domain vorzunehmen.
Ich empfehle dir die 'key' Einträge direkt in der ipsec.conf Datei vorzunehmen und mit x509 Zertifikaten nur zu arbeiten, wenn Win Roadwarriors ins Spiel kommen!
Ausserdem lass dir gesagt sein, das es von den Freeswan 2 Versionen keine SuperFreeswan Versionen gibt. Du wirst also auf NAT-Traversal ( und ein paar andere Features) verzichten müssen!
stimmt ;)
Aber was spricht gegen Zertifikate ??? Auch wenn nur Linuxrechner bei sind.... die bieten doch sehr gute Sicherheit. Klar ist etwas komplizierter aber schöner .... ;)
Gruß Temp
Hi@all,
so, ich wollte euch nun die Routing-Tabelle posten und habe das ganze nochmal ausprobiert.
Ich befinde mich allerdings nun am anderen Gateway, welche jedoch genau identisch eingerichtet ist. Ich habe den Router gerade mal neu gestartet und mir anschließend die Logfiles angesehn, da wird ausgegeben:
/var/log/syslog
ipsec_setup: KLIPS ipsec0 on ppp0 10.64.64.64/255.255.255.255 pointopoint 10.112.112.112
ipsec_setup: WARNING: changing route filtering on ppp0 (changing /proc/sys/net/ipv4/conf/ppp0/rp_filter from 1 to 0)
ipsec_setup: ...FreeS/WAN IPsec started
/usr/sbin/cron[260]: (CRON) INFO (pidfile fd = 3)
/usr/sbin/cron[262]: (CRON) STARTUP (fork ok)
/usr/sbin/cron[262]: (CRON) INFO (Running @reboot jobs)
ipsec__plutorun: whack error: "p2p" does not look numeric and name lookup failed "komet.dyndns.org"
ipsec__plutorun: ...could not add conn "p2p"
ipsec__plutorun: whack error: "n2n" does not look numeric and name lookup failed "komet.dyndns.org"
ipsec__plutorun: ...could not add conn "n2n"
pppd[151]: Starting link
pppd[151]: Serial connection established.
pppd[151]: Connect: ppp0 <--> /dev/pts/0
pppoe[318]: PADS: Service-Name: ''
pppoe[318]: PPP session is 4807
kernel: PPP BSD Compression module registered
kernel: PPP Deflate Compression module registered
pppd[151]: Local IP address changed to 217.84.126.168
pppd[151]: Remote IP address changed to 217.5.98.39
Läuft FreeS/WAN nun?
Aus dem Netz hinter dem Router komme ich noch ins Netz. Ausserdem vermisse ich dem Logfile den Eintrag von ddclient das die neu Adresse an den DynDNS-Server weitergegeben wurde.
Gruß Pixel
stefan-kfd
06.10.03, 10:04
Also zu deinem Syslog: So kann das nicht gehen. Du startest IPsec bevor du eine Internetverbindung hast !
1. Verbindung Herstellen (dann ist die defaultroute schon mal korrekt)
2. dyndns updaten
3. IPsec starten
Das ist erst mal die Voraussetzung. Wenn das funzt sollten wir uns über deine "Firewallregeln" unterhalten.
Habe bei mir den Start von IPsec in das ip-up Script von ppp0 eingebaut, analog das beenden in ip-down. So wird bei einem Wechsel der IP (Telekom Rausschmiss nach 24h) der Tunnel automatisch neu aufgebaut. Dies erfordert allerdings eine Anpassung der ipsec.conf, da in diesem Fall das update von dyndns nicht schnell genug erfolgt. Details dazu gerne später, bin momentan in Eile.
Gruß Stefan
Hi@all,
also ich habe nun folgendes gemacht. In den Verzeichnisen für die versch. RL's (rcx.d) habe ich die Start- (S..) bzw. End- (K..) Verknüpungen welche auf /etc/init.d/ipsec zeigten entfernt.
Für DynDNS hatte ich ja ein funktionierendes Startskript (/etc/ppp/ip-up.dyndns) angelegt. Im gleichen Verzeichnis habe ich nun noch das Skript ip-up.ipsec mit dem Inhalt:
#!/bin/sh
ipsec setup start
sowie ip-down.ipsec mit dem Inhalt:
#!/bin/sh
ipsec setup stop
angelegt. In dem Skript /etc/ppp/ip-up habe ich die Einträge:
./etc/ppp/ip-up.dyndns
./etc/ppp/ip-up.ipsec
und in /etc/ppp/ip-down den Eintrag:
./etc/ppp/ip-down.ipsec
angefügt. Wie gesagt, der Eintrag für DynDNS war bereits vorhanden und hat auch funktioniert. Wenn ich nun den Router neu starte finde ich im syslog:
pppd[167]: Local IP address changed to 80.139.219.169
pppd[167]: Remote IP address changed to 217.5.98.152
ddclient[232]: SUCCESS: updating komet.dyndns.org: good: IP address set to 80.139.219.169
ipsec_setup: Starting FreeS/WAN IPsec 2.01...
ipsec_setup: KLIPS debug `none'
ipsec_setup: KLIPS ipsec0 on ppp0 80.139.219.169/255.255.255.255 pointopoint 217.5.98.152
ipsec_setup: WARNING: changing route filtering on ppp0 (changing /proc/sys/net/ipv4/conf/ppp0/rp_filt$
ipsec_setup: ...FreeS/WAN IPsec started
modprobe: modprobe: Can't locate module char-major-5
Vom Netz her komme ich nicht mehr ins Internet. Erst wenn ich mit 'ipsec setup stop' FreeS/WAN beende komme ich wieder ins Internet.
Gruß Pixel
Hi@all,
also da ich mich im Moment auf der anderen Seite wie am WE befinde habe ich (denke ich zumindest) einen Fehler gefunden. In der ipsec.conf hat der, auf der anderen Seite vorandene Eintrag:
conn packetdefault
auto=ignore
gefehlt. Diesen habe ich eingetragen und wenn ich nun den Router neu starte komme ich vom LAN her noch ins Internet. Das syslog sieht so aus:
pppd[165]: Local IP address changed to 80.139.229.184
Opppd[165]: Remote IP address changed to 217.5.98.152
ddclient[230]: SUCCESS: updating komet.dyndns.org: good: IP address set to 80.139.229.184
ipsec_setup: Starting FreeS/WAN IPsec 2.01...
ipsec_setup: KLIPS debug `none'
ipsec_setup: KLIPS ipsec0 on ppp0 80.139.229.184/255.255.255.255 pointopoint 217.5.98.152
ipsec_setup: WARNING: changing route filtering on ppp0 (changing /proc/sys/net/ipv4/conf/ppp0/rp_filt$
ipsec_setup: ...FreeS/WAN IPsec started
modprobe: modprobe: Can't locate module char-major-5
Wie sieht das aus, sind nun die Voraussetzungen erfüllt?
Gruß Pixel
stefan-kfd
06.10.03, 12:17
Als nächstes wäre die Ausgabe von "ipsec auto --status" und "route -n" interessant.
By the way, welche Version von Free/Swan verwendest du ? Sind beide Gateways Debian Woody ?
Ergänzung:
Ok wer lesen kann ist besser dran Free/Swan 2.01
Gruß Stefan
jo auf beiden Routern ist Debian-Woody drauf mit angepasstem vanilla Kernel 2.4.22. Die Kernel sind mit ausnahme der Hardwareunterschiede (Mainboard, Chipsatz etc.) absolut identisch eingerichtet. So nun aber zur Ausgabe:
ipsec auto --status
000 interface ipsec0/ppp0 80.139.229.184
000
000 debug none
000
000 "n2n": 192.168.111.0/24===80.139.229.184[C=DE, ST=Badem-Wuerttemberg, L=Mannheim, O=Softwareschmiede, CN=sphinx.komet.net, E=gehr@kometmetall.de]---217.5.98.152...217.84.118.126===192.168.0.0/24
000 "n2n": CAs: 'C=DE, ST=Baden-Wuerttemberg, L=Mannheim, O=Softwareschmiede, CN=sphinx.komet.net, E=gehr@kometmetall.de'...'%any'
000 "n2n": ike_life: 3600s; ipsec_life: 28800s; rekey_margin: 540s; rekey_fuzz: 100%; keyingtries: 1
000 "n2n": policy: RSASIG+ENCRYPT+TUNNEL+PFS; interface: ppp0; unrouted
000 "n2n": newest ISAKMP SA: #0; newest IPsec SA: #0; eroute owner: #0
000 "p2p": 80.139.229.184[C=DE, ST=Badem-Wuerttemberg, L=Mannheim, O=Softwareschmiede, CN=sphinx.komet.net, E=gehr@kometmetall.de]---217.5.98.152...217.84.118.126
000 "p2p": CAs: 'C=DE, ST=Baden-Wuerttemberg, L=Mannheim, O=Softwareschmiede, CN=sphinx.komet.net, E=gehr@kometmetall.de'...'%any'
000 "p2p": ike_life: 3600s; ipsec_life: 28800s; rekey_margin: 540s; rekey_fuzz: 100%; keyingtries: 1
000 "p2p": policy: RSASIG+ENCRYPT+TUNNEL+PFS; interface: ppp0; unrouted
000 "p2p": newest ISAKMP SA: #0; newest IPsec SA: #0; eroute owner: #0
000
000
route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
217.5.98.152 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0
217.5.98.152 0.0.0.0 255.255.255.255 UH 0 0 0 ipsec0
192.168.111.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
0.0.0.0 217.5.98.152 0.0.0.0 UG 0 0 0 ppp0
Gruß Pixel
stefan-kfd
06.10.03, 14:05
Gut so. IPsec läuft nun, aber es ist noch kein Tunnel aufgebaut. Du solltest nun auf einer Seite den Tunnel starten. Entweder beim IPsec start in der ipsec.conf mit auto=start oder von hand mit ipsec auto --up "Tunnelname".
Bei der Ausgabe von route -n sollten dann Routen in die jeweilgen Subnetze vorhanden sein. Ist dies der Fall ping von einem Subnetz zum Anderen testen. Nicht von den Gateways !
Bei Misserfolg bitte Logauszüge.
Gruß Stefan
PS.: Verfolge auch das Thema mit den Partitionstabellen, habe aber auch noch keinen Gedankenblitz.
Hi,
also für die Netzverbindung (Router1 zu Router 2) ist doch die Verbindung:
conn n2n
right=dreampixel.dyndns.org
rightsubnet=192.168.0.0/24
leftsubnet=192.168.111.0/24
relevant, oder? und hier ergänze ich auf der einen Seite 'auto=start' und auf der anderen 'auto=add' ??
Gruß Pixel
P.S. Der Grund warum ich es jetzt nicht einach probiere und nochmal nachfrage ist der das wenn ich mich jetzt aussperre ich keine Möglichkeit mehr (bis heute Abend) habe es zu probieren.
stefan-kfd
06.10.03, 15:12
Das ist richtig. Du kannst dir ja eine SSH (über das Internet) zu der remote Seite aufmachen. Dann kannst du notfalls dort IPsec stoppen, bzw das netz neu starten. Wenn dyndns richtig arbeitet, bekommst du so auf alle Fälle wieder einen Zugang. Starte auf beiden Seiten IPsec mit auto=add.
Starte dann den Tunnel lokal mit "ipsec auto --up n2n"
Gruß Stefan
Hi,
Also ich habe in den beiden Verbindungen (n2n) die Änderungen durchgeführt
also:
In der Firma:
conn n2n
right=dreampixel.dyndns.org
rightsubnet=192.168.0.0/24
leftsubnet=192.168.111.0/24
auto=add
Zuhause:
conn n2n
right=komet.dyndns.org
rightsubnet=192.168.111.0/24
leftsubnet=192.168.0.0/24
auto=add
Wenn ich nun, egal auf welcher Seite 'ipsec auto --up n2n' eingebe erhalte ich
Ausgabe:
104 "n2n" #1: STATE_MAIN_I1: initiate
010 "n2n" #1: STATE_MAIN_I1: retransmission; will wait 20s for response
010 "n2n" #1: STATE_MAIN_I1: retransmission; will wait 40s for response
031 "n2n" #1: max number of retransmissions (2) reached STATE_MAIN_I1. No
response (or no acceptable response) to our first IKE message
Im syslog steht nichts hierzu. In /var/log/auth.log steht:
Oct 6 17:03:36 sphinx pluto[304]: "n2n" #1: initiating Main Mode
Oct 6 17:04:46 sphinx pluto[304]: "n2n" #1: max number of retransmissions (2)
reached STATE_MAIN_I1. No response (or no acceptable response) to our first
IKE message
Oct 6 17:08:01 sphinx PAM_unix[371]: (cron) session opened for user mail by
(uid=0)
Oct 6 17:08:01 sphinx PAM_unix[371]: (cron) session closed for user mail
Oct 6 17:08:42 sphinx pluto[304]: packet from 80.131.184.102:500: initial
Main Mode message received on 80.139.224.199:500 but no connection has been
authorized
Oct 6 17:08:45 sphinx pluto[304]: "n2n" #2: initiating Main Mode
Oct 6 17:08:52 sphinx pluto[304]: packet from 80.131.184.102:500: initial
Main Mode message received on 80.139.224.199:500 but no connection has been
Oct 6 17:09:12 sphinx pluto[304]: packet from 80.131.184.102:500: initial
Main Mode message received on 80.139.224.199:500 but no connection has been
Oct 6 17:09:55 sphinx pluto[304]: "n2n" #2: max number of retransmissions (2)
reached STATE_MAIN_I1. No response (or no acceptable response) to our first
IKE message
Oct 6 17:23:01 sphinx PAM_unix[383]: (cron) session opened for user mail by
(uid=0)
Oct 6 17:23:01 sphinx PAM_unix[383]: (cron) session closed for user mail
Kannst du damit etwas anfangen?
Gruß Pixel
stefan-kfd
06.10.03, 16:19
Mir fällt auf, dass du in beiden Fällen "right" verwendest. Meine ipsec.conf Dateien sind so aufgebaut, dass right und left eindeutig für das jeweilige Gateway ist. Entscheide wer left und wer right ist und ändere die .conf dementsprechend.
Gruß Stefan
Hi,
ich verwende auf beiden Seiten left für lokal und right für remote.
Also auf Router1:
conn n2n
right=dreampixel.dyndns.org
rightsubnet=192.168.0.0/24
leftsubnet=192.168.111.0/24
auto=add
wobei dies der DynDNS-Name (dreampixel.dyndns.org) sowie die Netadresse / Netmask (192.168.0.0/24) von Netzwerk 2 (Router 2) ist.
Auf Router2 ist ganze spiegelbildlich. Ich verstehe nicht ganz was ich ändern soll?
Gruß Pixel
stefan-kfd
06.10.03, 16:48
Nun da bin ich nun auch etwas am wackeln, da ich diesen Vorschlag left=local right=remote auch in einer Dokumentation zu einer Version > 2 gelesen habe. Da ich aber mehrere Gateways und Roadwarrior mit unterschiedlichen FreeS/Wan Versionen betreibe (Verwende auf Gateways ausschließlich Debian stable Pakete, auf den Laptops unstable) ist das ganze bei mir abwärtskompatibel. Daher trifft die oben erwähnte left - right definition bei mir nicht zu. Auf dem Gateway1 ist die eigene Beschreibung right, die für Gateway2 left. Auf dem Gateway2 ist die Beschreibung für Gateway1 ebenfalls right, die eigene Beschreibung left.
Nach meinem Verständniß kann es auch nicht anders funktionieren. Siehe dein Log, er bescwert sich dort, dass keine Beschreibung auf der Gegenseite für eine derartige Verbindung autorisiert sei.
Gruß Stefan
Hi,
d.h. ich vertauche right und left einfach? Mache also auf Router 1 (komet.dyndns.org / 192.168.111.0/24)
aus:
conn n2n
right=dreampixel.dyndns.org
rightsubnet=192.168.0.0/24
leftsubnet=192.168.111.0/24
auto=add
ein:
conn n2n
right=komet.dyndns.org
rightsubnet=192.168.111.0/24
leftsubnet=192.168.0.0/24
auto=add
und auf Router 2 (dreampixel.dyndns.org / 192.168.0.0/24)
aus:
conn n2n
right=komet.dyndns.org
rightsubnet=192.168.111.0/24
leftsubnet=192.168.0.0/24
auto=add
ein:
conn n2n
right=dreampixel.dyndns.org
rightsubnet=192.168.0.0/24
leftsubnet=192.168.111.0/24
auto=add
Gruß Pixel
stefan-kfd
06.10.03, 17:19
Ähm, fast
Versuchen wir es mal so:
komet.dyndns.org / 192.168.111.0/24:
conn n2n
right=%defaultroute (kann auch in conn %default stehen)
rightsubnet=192.168.111.0/24
left=dreampixel.dyndns.org
leftsubnet=192.168.0.0/24
auto=add
dreampixel.dyndns.org / 192.168.0.0/24:
conn n2n
right=komet.dyndns.org
rightsubnet=192.168.111.0/24
left=%defaultroute (kann auch in conn %default stehen)
leftsubnet=192.168.0.0/24
auto=add
damit ist eindeutig definiert: right=komet.dyndns.org left=dreampixel.dyndns.org
Jetzt mal nen Verbindungstest.
Gruß Stefan
Hi,
ok die Änderungen habe ich gemacht jedoch hat sich werder an der Fehlermeldung noch am Logfile etwas geändert.
Gruß Pixel
stefan-kfd
06.10.03, 20:03
Starte mal die Verbindung mit "ipsec auto --verbose --up n2n". Poste bitte noch mal deine aktuelle ipsec.conf
Gruß Stefan
also
Router 1, via komet.dyndns.org von extern zu erreichen das LAN hinter Router 1 ist 192.168.111.0/24
# basic configuration
config setup
interfaces=%defaultroute
klipsdebug=none
plutodebug=none
conn %default
keyingtries=1
disablearrivalcheck=no
authby=rsasig
rightrsasigkey=%cert
auto=add
left=%defaultroute
leftcert=sphinx_cert.pem
leftupdown=/usr/local/lib/ipsec/_updown.x509
conn p2p
right=dreampixel.dyndns.org
conn n2n
right=%defaultroute
rightsubnet=192.168.111.0/24
leftsubnet=192.168.0.0/24
auto=add
conn block
auto=ignore
conn private
auto=ignore
conn private-or-clear
auto=ignore
conn clear-or-private
auto=ignore
conn clear
auto=ignore
conn packetdefault
auto=ignore
Router 2, von extern über dreampixel.dyndns.org zu erreichen LAN hinter Router: 192.168.0.0/24
# basic configuration
config setup
interfaces=%defaultroute
klipsdebug=none
plutodebug=none
conn %default
keyingtries=1
disablearrivalcheck=no
authby=rsasig
rightrsasigkey=%cert
auto=add
left=%defaultroute
leftcert=sphinx_cert.pem
leftupdown=/usr/local/lib/ipsec/_updown.x509
conn p2p
right=komet.dyndns.org
conn n2n
right=komet.dyndns.org
rightsubnet=192.168.111.0/24
left=%defaultroute
leftsubnet=192.168.0.0/24
conn block
auto=ignore
conn private
auto=ignore
conn private-or-clear
auto=ignore
conn clear-or-private
auto=ignore
conn clear
auto=ignore
conn packetdefault
auto=ignore
Wenn ich auf Router 2 den Befehl 'ipsec auto --verbose --up n2n' aufrufe erhalte ich die Ausgabe:
002 "n2n" #2: initiating Main Mode
104 "n2n" #2: STATE_MAIN_I1: initiate
010 "n2n" #2: STATE_MAIN_I1: retransmission; will wait 20s for response
010 "n2n" #2: STATE_MAIN_I1: retransmission; will wait 40s for response
031 "n2n" #2: max number of retransmissions (2) reached STATE_MAIN_I1. No response (or no acceptable response) to our first
Ich sehe keinen Unterschied.
Gruß Pixel
stefan-kfd
06.10.03, 21:04
right=Komet =>
# basic configuration
config setup
interfaces=%defaultroute
klipsdebug=none
plutodebug=none
conn %default
keyingtries=1
disablearrivalcheck=no
authby=rsasig
right=%defaultroute
rightrsasigkey=%cert
rightcert=.... (bitte ergänzen)
rightsubnet=192.168.111.0/24
conn p2p
right=dreampixel.dyndns.org
conn n2n
left=dreampixel.dyndns.org
leftsubnet=192.168.0.0/24
leftrsasigkey=%cert
auto=add
conn block
auto=ignore
conn private
auto=ignore
conn private-or-clear
auto=ignore
conn clear-or-private
auto=ignore
conn clear
auto=ignore
conn packetdefault
auto=ignore
dreampixel=left =>
# basic configuration
config setup
interfaces=%defaultroute
klipsdebug=none
plutodebug=none
conn %default
keyingtries=1
disablearrivalcheck=no
authby=rsasig
left=%defaultroute
leftcert=sphinx_cert.pem
leftupdown=/usr/local/lib/ipsec/_updown.x509
leftsubnet=192.168.0.0/24
conn p2p
right=komet.dyndns.org
conn n2n
right=komet.dyndns.org
rightsubnet=192.168.111.0/24
rightrsasigkey=%cert
auto=add
conn block
auto=ignore
conn private
auto=ignore
conn private-or-clear
auto=ignore
conn clear-or-private
auto=ignore
conn clear
auto=ignore
conn packetdefault
auto=ignore
Bei den Zeilen zu den Zetifikaten bin ich nicht hundetprozent sicher, da ich RSA benutze. Das sollte aber nun wenigstens die Gegenseite ansprechen und wenn das mit den Zertifikaten klappt den Tunnel aufbauen.
Gruß Stefan
Hi,
leider hat sich sowohl am Befehlsoutput wie auch am Logfile nichts geändert:confused:
Gruß Pixel
stefan-kfd
07.10.03, 16:40
Hi,
setz mal klipsdebug=all und plutodebug=all. Gibt dies anderen Output ?
Hast du wenn die conn gestartet ist routen in das private Subnet des Gegenübers ?
Schau mal mit hilfe von tcpdump nach ob auf dem einen Gateway Pakete ankommen (sowohl ppp0 wie auch ipsec0) wenn du auf dem anderen den Tunnel startest ?
Gruß Stefan
Hi,
nach der letzten Änderung habe ich auf der komet.. Seite ein ganz anderes Problem. Der Aufruf von 'ipsec auto --up n2n' führt zu:
021 no connection named "n2n"
Im syslog finde ich:
sphinx ipsec__plutorun: ipsec_auto: fatal error in "n2n": connection has no "right" parameter specified
Hier noch mal der Eintrag für n2n in ipsec.conf:
conn n2n
left=dreampixel.dyndns.org
leftsubnet=192.168.0.0/24
leftrsasigkey=%cert
auto=add
Gruß Pixel
stefan-kfd
08.10.03, 13:45
Dann stimmt was mit der conn default nicht, da dort die Parameter für right gesetzt werden. Da die conns bis auf den Unterschied left und right eigentlich identisch sein müssten, denke ich dass die Zeilen für die Zertifikate nicht stimmen. Da ich damit allerdings selbst schon lange nicht mehr gearbeitet habe, muss ich mir das erst in der Doku ansehen.
Gruß stefan
Powered by vBulletin® Version 4.2.5 Copyright ©2024 Adduco Digital e.K. und vBulletin Solutions, Inc. Alle Rechte vorbehalten.