FreeS/WAN Problem/Verständnisfrage unter SuSE 8.1
skb->len=75 hard_header_len:0 Apr 1 17:52:05 router01 kernel: klips_debug: IP: ihl:20 ver:4 tos:0 tlen:75 id:37059 DF frag_off:0 tt l:54 proto:6 (TCP) chk:11594 saddr:xxx.xxx.xxx.xxx:pppp daddr:192.168.1.250:3518 Apr 1 17:52:05 router01 kernel: klips_debug:ipsec_findroute: xxx.xxx.xxx.xxx->192.168.1.250 Apr 1 17:52:05 router01 kernel: klips_debug:rj_match: * See if we match exactly as a host destination Apr 1 17:52:05 router01 kernel: klips_debug:rj_match: ** try to match a leaf, t=0xc17124c0 Apr 1 17:52:05 router01 kernel: klips_debug:rj_match: *** start searching up the tree, t=0xc17124c0 Apr 1 17:52:05 router01 kernel: klips_debug:rj_match: **** t=0xc17124d8 Apr 1 17:52:05 router01 kernel: klips_debug:rj_match: **** t=0xc3f8c3e0 Apr 1 17:52:05 router01 kernel: klips_debug:rj_match: ***** cp2=0xc276acf8 cp3=0xc0b11510 Apr 1 17:52:05 router01 kernel: klips_debug:rj_match: ***** not found. Apr 1 17:52:05 router01 kernel: klips_debug:ipsec_tunnel_start_xmit: checking for local udp/500 IKE pac ket saddr=c3ee000f, er=00000000, daddr=c0a801fa, er_dst=0, proto=6 sport=0 dport=0 Apr 1 17:52:05 router01 kernel: klips_debug:ipsec_tunnel_start_xmit: Original head,tailroom: 84,1441 Apr 1 17:52:05 router01 kernel: klips_debug:ipsec_tunnel_start_xmit: shunt SA of DROP or no eroute: dro
Hallo zusammen!
Ich beschäftige mich nun schon seit einigen Tagen damit, mein Heim-Netz
und das Heim-Netz eines Freundes per FreeS/WAN VPN zusammenzubringen.
Die Situation ist folgende:
Mein Netz:
Hauptserver (DNS, DHCP, Samba, FTP) 192.168.1.250/255.255.255.0
Router (+VPN) 192.168.1.254/255.255.255.0
1 WinXP Client 192.168.1.1
DSL-Verbindung zum Internet ppp0, dyn. IP
Netz von meinem Kollegen:
Hauptserver und Router (+VPN) (1 PC) 192.168.1.1/255.255.255.0
2 Clients WinXP 192.168.1.25 und .26 /255.255.255.0
DSL-Verbindung zum Internet ppp0, dyn. IP
Beide Internetverbindungen machen Masquerading über SuSE-FW2. UDP-500,
50,51 habe ich freigeschaltet.
Die Konfigurationsdatei /etc/ipsec.conf sieht auf beiden Seiten so aus:
---schnipp---
config setup
interfaces=%defaultroute
klipsdebug=all
plutodebug=all
plutoload=%search
plutostart=%search
uniqueids=no
conn %default
keyingtries=0
compress=yes
disablearrivalcheck=no
authby=secret
conn vpn
left=<Dynamic-DNS ICH>
leftsubnet=192.168.1.0/24
leftnexthop=%defaultroute (bei Kollegen steht hier meine ppp0
P-t-P IP)
right=<Dynamic-DNS KOLLEGE>
rightsubnet=192.168.1.0/24
rightnexthop=<P-t-P IP von ppp0> (bei Kollegen steht hier auch
%defaultroute)
type=tunnel
auto=add
authby=secret
---schnapp---
/etc/ipsec.secrets sieht so aus:
---schnipp
Dennis, In einer Gateway2Gateway Lösung kannst Du AFAIK die VPNServer nicht gegenseitig erreichen, Du kannst aber trotzdem den Tunnel ins andere Netz nutzen. Versuch mal ein Host2Host vpn zu basteln, außer, Du gibst Dich damit wie es jetzt ist zufrieden ;-) Stefan
Ich beschäftige mich nun schon seit einigen Tagen damit, mein Heim-Netz und das Heim-Netz eines Freundes per FreeS/WAN VPN zusammenzubringen. Die Situation ist folgende:
Mein Netz: Hauptserver (DNS, DHCP, Samba, FTP) 192.168.1.250/255.255.255.0 Router (+VPN) 192.168.1.254/255.255.255.0 1 WinXP Client 192.168.1.1 DSL-Verbindung zum Internet ppp0, dyn. IP
Netz von meinem Kollegen: Hauptserver und Router (+VPN) (1 PC) 192.168.1.1/255.255.255.0 2 Clients WinXP 192.168.1.25 und .26 /255.255.255.0 DSL-Verbindung zum Internet ppp0, dyn. IP
Beide Internetverbindungen machen Masquerading über SuSE-FW2. UDP-500, 50,51 habe ich freigeschaltet.
Die Konfigurationsdatei /etc/ipsec.conf sieht auf beiden Seiten so aus: ---schnipp--- config setup interfaces=%defaultroute klipsdebug=all plutodebug=all plutoload=%search plutostart=%search uniqueids=no
conn %default keyingtries=0 compress=yes disablearrivalcheck=no authby=secret
conn vpn left=<Dynamic-DNS ICH> leftsubnet=192.168.1.0/24 leftnexthop=%defaultroute (bei Kollegen steht hier meine ppp0 P-t-P IP) right=<Dynamic-DNS KOLLEGE> rightsubnet=192.168.1.0/24 rightnexthop=<P-t-P IP von ppp0> (bei Kollegen steht hier auch %defaultroute) type=tunnel auto=add authby=secret ---schnapp---
/etc/ipsec.secrets sieht so aus:
---schnipp
: PSK "passphrase" ---schnapp--- Wenn ich nun IPSec durch "rcipsec start" starte und danach auf einer Seite die Verbindung durch "ipsec --auto vpn" starten will, kann ich nach einigen Sekunden meinen Router nicht mehr pingen und muss ihn neustarten....
Ich denke die Konfigurationsdateien müsseten in Ordnung sein, da er mir in /var/log/messages anzeigt: router01 pluto[16209]: added connection description "vpn" router01 pluto[16209]: | 192.168.1.0/24===<IP ppp0>---<IP ppp0 P-t-P>... ...<IP ppp0 P-t-P>---<IP ppp0>===192.168.1.0/24
Nach dem Verbindungsstart durch "ipsec --auto vpn" taucht in /var/log/messages u.A. folgendes auf: ---schnipp--- Apr 1 17:50:43 router01 kernel: klips_debug:pfkey_address_process: Apr 1 17:50:43 router01 kernel: klips_debug:pfkey_address_process: found address family=2, AF_INET, 217 .225.222.28. Apr 1 17:50:43 router01 kernel: klips_debug:pfkey_address_process: found src address. Apr 1 17:50:43 router01 kernel: klips_debug:pfkey_address_process: successful. Apr 1 17:50:43 router01 kernel: klips_debug:pfkey_msg_interp: processing ext 6 c17129f8 with processor c3c4c240. Apr 1 17:50:43 router01 kernel: klips_debug:pfkey_address_process: Apr 1 17:50:43 router01 kernel: klips_debug:pfkey_address_process: found address family=2, AF_INET, 80. 135.110.228. Apr 1 17:50:43 router01 kernel: klips_debug:pfkey_address_process: found dst address. Apr 1 17:50:43 router01 kernel: klips_debug:pfkey_address_process: tdb_said.dst set to 80.135.110.228. Apr 1 17:50:43 router01 kernel: klips_debug:pfkey_address_process: successful. Apr 1 17:50:43 router01 kernel: klips_debug:pfkey_msg_interp: processing ext 21 c1712a10 with processor c3c4c240. ---schnapp---
skb->len=75 hard_header_len:0 Apr 1 17:52:05 router01 kernel: klips_debug: IP: ihl:20 ver:4 tos:0 tlen:75 id:37059 DF frag_off:0 tt l:54 proto:6 (TCP) chk:11594 saddr:xxx.xxx.xxx.xxx:pppp daddr:192.168.1.250:3518 Apr 1 17:52:05 router01 kernel: klips_debug:ipsec_findroute: xxx.xxx.xxx.xxx->192.168.1.250 Apr 1 17:52:05 router01 kernel: klips_debug:rj_match: * See if we match exactly as a host destination Apr 1 17:52:05 router01 kernel: klips_debug:rj_match: ** try to match a leaf, t=0xc17124c0 Apr 1 17:52:05 router01 kernel: klips_debug:rj_match: *** start searching up the tree, t=0xc17124c0 Apr 1 17:52:05 router01 kernel: klips_debug:rj_match: **** t=0xc17124d8 Apr 1 17:52:05 router01 kernel: klips_debug:rj_match: **** t=0xc3f8c3e0 Apr 1 17:52:05 router01 kernel: klips_debug:rj_match: ***** cp2=0xc276acf8 cp3=0xc0b11510 Apr 1 17:52:05 router01 kernel: klips_debug:rj_match: ***** not found. Apr 1 17:52:05 router01 kernel: klips_debug:ipsec_tunnel_start_xmit: checking for local udp/500 IKE pac ket saddr=c3ee000f, er=00000000, daddr=c0a801fa, er_dst=0, proto=6 sport=0 dport=0 Apr 1 17:52:05 router01 kernel: klips_debug:ipsec_tunnel_start_xmit: Original head,tailroom: 84,1441 Apr 1 17:52:05 router01 kernel: klips_debug:ipsec_tunnel_start_xmit: shunt SA of DROP or no eroute: dro
Und nach einiger Zeit noch folgendes: (was dann immer wieder so weiter geht, bis zum Neustart *g*) ---schnipp--- Apr 1 17:52:04 router01 kernel: NET: 3 messages suppressed. Apr 1 17:52:04 router01 kernel: martian source 192.168.1.254 from 192.168.1.250, on dev eth0 Apr 1 17:52:04 router01 kernel: ll header: ff:ff:ff:ff:ff:ff:00:04:76:0b:93:f9:08:06 Apr 1 17:52:05 router01 kernel: klips_debug:ipsec_tunnel_start_xmit: pping. ---schnapp
Hat jemand eine Idee oder einen Tipp, wo mein Problem liegt? Liegt es vielleicht daran, dass wir beide ein lok. Netz 192.168.1.* haben und die Rechner mit den Routen durcheinanderkommen? Habe mich schon die ganze Zeit gefragt, ob das geht, aber leider nichts gefunden.
Hallo Stefan,
In einer Gateway2Gateway Lösung kannst Du AFAIK die VPNServer nicht gegenseitig erreichen, Du kannst aber trotzdem den Tunnel ins andere Netz nutzen.
Versuch mal ein Host2Host vpn zu basteln, außer, Du gibst Dich damit wie es jetzt ist zufrieden ;-)
bei der ganzen VPN Geschichte ist mein Ziel eigentlich, dass ich u.a Netzwerkspiele (die nicht Internetfähig sind) über Internet gegen meinen Kollegen spielen kann. Es wäre mir auch nicht so wichtig, die Server bzw. Router durch das VPN zu erreichen, aber ich kann meinen Router von meinem LOKALEN Netzwerk aus auch nicht mehr erreichen. Gruß, Dennis
Hi! Hmmm. Versuch es doch mal mit Vtun? Ist bei SuSE dabei und easy zu installieren. Dabei kann ich Dir auf jeden Fall helfen, ist zwar nicht auf BAsis Ipsec aber zum Tunneln funktionierts sauber. Stefan Dennis Bendowski schrieb:
Hallo Stefan,
In einer Gateway2Gateway Lösung kannst Du AFAIK die VPNServer nicht gegenseitig erreichen, Du kannst aber trotzdem den Tunnel ins andere Netz nutzen.
Versuch mal ein Host2Host vpn zu basteln, außer, Du gibst Dich damit wie es jetzt ist zufrieden ;-)
bei der ganzen VPN Geschichte ist mein Ziel eigentlich, dass ich u.a Netzwerkspiele (die nicht Internetfähig sind) über Internet gegen meinen Kollegen spielen kann. Es wäre mir auch nicht so wichtig, die Server bzw. Router durch das VPN zu erreichen, aber ich kann meinen Router von meinem LOKALEN Netzwerk aus auch nicht mehr erreichen.
Hallo Stefan, Vtun kenne ich wohl - ich hatte es vor FreeS/WAN ausprobiert, mir daran allerdings auch die Zähne ausgebissen. Ich hab es danach dann mit FreeS/WAN probiert, weil es da meiner Meinung nach wesentlich mehr Doku zu im Netz gibt und weil es irgendwie einfacher aussieht und mehr möglichkeiten bietet. Aber im Endeffekt ist mir egal, welche Lösung ich nun verwende, Hauptsache ist, dass ich unsere beiden Netzwerke verbinden kann :) Wäre sehr nett von Dir, wenn Du mir bei vtun vielleicht mal helfen könntest. (Auch per PM)(Wie gesagt ich hab da auch fast gar keine Doku im Netz zu gefunden...) Bei mir ist es glaube ich immer daran gescheitert, dass ich ein Device nicht hatte, weiss nicht mehr ob es tun0 oder tap0 war... Würde die Geschichte mit ipsec denn funktionieren, wenn ich einen weiteren PC (den ich noch in der Ecke rum stehen habe) ausschließlich zur Verbindung der Netzwerke verwende und die benötigten Protokolle dann auf der Firewall an diesen PC umleite? Eigentlich ist das kein Problem, denn mein Kollege hat auch noch eine alte Kiste rumstehen.... Und habe ich das jetzt richtig verstanden? Wenn ich also zwei separate VPN-Gateways installiere (auf beiden Seiten), kommen unsere Server und PCs von dem einem in das andere Netz, aber man kommt weder intern, noch extern auf die Gatewayrechner? Irgendwie kommt mir das komisch vor, denn wie soll man das Gateway dann fernwarten können? Kann der Fehler nicht vielleicht damit zu tun haben, dass wir beide lokal 192.168.1.* haben? Hatte gestern noch versucht, in den Konfigurationsdateien auf beiden Seiten mal andere Netzwerke zu nehmen (201.* und 202.*), allerdings erfolglos... Welche IP-Adresse in meinem Netzwerk bekommt eigentlich der Server meines Kollegen, wenn der sich verbindet? Oder ist das gleich dem Router, wo IPSEC läuft? Fragen über Fragen... :-) Danke und gruß Dennis
Hmmm. Versuch es doch mal mit Vtun? Ist bei SuSE dabei und easy zu installieren. Dabei kann ich Dir auf jeden Fall helfen, ist zwar nicht auf BAsis Ipsec aber zum Tunneln funktionierts sauber.
Stefan
Dennis Bendowski schrieb:
Hallo Stefan,
In einer Gateway2Gateway Lösung kannst Du AFAIK die VPNServer nicht gegenseitig erreichen, Du kannst aber
trotzdem
den Tunnel ins andere Netz nutzen.
Versuch mal ein Host2Host vpn zu basteln, außer, Du gibst Dich damit wie es jetzt ist zufrieden ;-)
bei der ganzen VPN Geschichte ist mein Ziel eigentlich, dass ich u.a Netzwerkspiele (die nicht Internetfähig sind) über Internet gegen meinen Kollegen spielen kann. Es wäre mir auch nicht so wichtig, die Server bzw. Router durch das VPN zu erreichen, aber ich kann meinen Router von meinem LOKALEN Netzwerk aus auch nicht mehr erreichen.
On Wed, Apr 02, 2003 at 02:01:01PM +0200, Dennis Bendowski wrote:
Kann der Fehler nicht vielleicht damit zu tun haben, dass wir beide lokal 192.168.1.* haben?
Das ist genau das Problem. Du musst auf beiden Seiten unterschiedliche IP-Nummern vergeben, und dann entsprechende Routen aufsetzen. Der Rechner Deines Kollegen erhält genau die IP-Nummer, die er hat. Du setzt schließlich einen Tunnel auf, und kein NAT oder so etwas. Die Pakete an den Rechner Deines Kollegen werden vom FreeSWAN dann in Pakete eingepackt, die als Absender Deine externe IP haben und als Empfänger seine externe IP. Das FreeSWAN auf seiner Seite packt das dann wieder aus. Kristian
Hallo Kristian,
-----Ursprüngliche Nachricht----- Von: Kristian Koehntopp [mailto:kris@koehntopp.de] Gesendet: Mittwoch, 2. April 2003 21:44
Das ist genau das Problem.
Du musst auf beiden Seiten unterschiedliche IP-Nummern vergeben, und dann entsprechende Routen aufsetzen.
Der Rechner Deines Kollegen erhält genau die IP-Nummer, die er hat. Du setzt schließlich einen Tunnel auf, und kein NAT oder so etwas.
Wie meinst Du "erhält genau die IP, die we hat" denn jetzt? Was ich leider immer noch nicht verstanden habe, ist, was jetzt ganz genau mit left, right, leftnexthop, rightnexthop gemeint ist... Ich habe es bisher so verstanden: Left = Mein dynamischer DNS Name Leftsubnet = 192.168.1.0/24 Leftnexthop = %defaultroute bzw. IP des P-t-P von ppp0 Right = DDNS vom Kollegen Rightsubnet = 192.168.2.0/24 (hab ich gerade geändert) Rightnexthop = IP P-t-P von ppp0 beim Kollegen Ist Left/Right jetzt die ext. Oder int. IP des VPN-Gateways und Ist Left-/Rightnexthop die P-t-P IP oder einfach nur jeweils die ext. IP der Gateways (also der DDNS)? Danke und Gruß Dennis
-----Ursprüngliche Nachricht----- Von: Dennis Bendowski [mailto:dennis@dbendowski.de] Gesendet: Mittwoch, 2. April 2003 23:09
Hallo zusammen, Ich habe jetzt folgendes gemacht: /etc/ipsec.conf bei mir und Kollegem: router01:/etc # cat ipsec.conf # basic configuration config setup interfaces=%defaultroute klipsdebug=all plutodebug=all plutoload=%search plutostart=%search uniqueids=no conn %default keyingtries=0 compress=yes disablearrivalcheck=no authby=secret #authby=rsakey #leftrsasigkey=%cert #rightrsasigkey=%cert #leftid="xxxxmail" #rightid="xxxxport" conn vpn left=sid67.compress.to leftsubnet=192.168.1.0/24 leftnexthop=%defaultroute (bei Kollege geändert) leftfirewall=yes right=silencer.ddns.info rightsubnet=192.168.2.0/24 rightnexthop=217.5.98.67 (bei Kollege geändert) rightfirewall=yes type=tunnel auto=add #authby=rsasig authby=secret #leftcert=mail.xxx.de.pem #rightcert=port.xxx.de.pem #keyexchange=ike rcipsec startet auch soweit und zeigt mir als bekannte Verbindung an: router01 pluto[8202]: | *received whack message router01 pluto[8202]: added connection description "vpn" router01 pluto[8202]: | 192.168.1.0/24===80.135.xxx.xxx---217.5.xxx.xxx....... .......217.5.xxx.xxx---217.81.xxx.xxx===192.168.2.0/24 Nach einem ipsec auto --up vpn auf einer der Seiten passiert folgendes: (Allerdings kann ich meinen Router jetzt noch per ssh ansprechen, das ging ja vorher nicht...) 104 "vpn" #1: STATE_MAIN_I1: initiate 106 "vpn" #1: STATE_MAIN_I2: sent MI2, expecting MR2 108 "vpn" #1: STATE_MAIN_I3: sent MI3, expecting MR3 004 "vpn" #1: STATE_MAIN_I4: ISAKMP SA established 112 "vpn" #2: STATE_QUICK_I1: initiate 003 "vpn" #2: up-client command exited with status 127 032 "vpn" #2: STATE_QUICK_I1: internal error 010 "vpn" #2: STATE_QUICK_I1: retransmission; will wait 20s for response 003 "vpn" #2: up-client command exited with status 127 032 "vpn" #2: STATE_QUICK_I1: internal error << dann hab ich mit Strg-C abgebrochen :) >> Und in den Logs: Apr 2 23:27:18 fslx01 kernel: klips_debug:pfkey_sendmsg: . Apr 2 23:27:18 fslx01 kernel: klips_debug:pfkey_sendmsg: msg sent for parsing. Apr 2 23:27:18 fslx01 kernel: klips_debug:pfkey_msg_interp: parsing message ver=2, type=13, errno=0, satype=10(COMP), len=13, res=0, seq=30, pid=11995. Apr 2 23:27:18 fslx01 kernel: klips_debug:pfkey_alloc_ipsec_sa: allocated tdb struct=c2effe68. Apr 2 23:27:18 fslx01 kernel: klips_debug:pfkey_msg_interp: allocated extr->tdb=c534b800. Apr 2 23:27:18 fslx01 kernel: klips_debug:pfkey_msg_interp: satype 10 lookups to proto=108. Apr 2 23:27:18 fslx01 kernel: klips_debug:pfkey_msg_interp: processing ext 1 c6591bd0 with processor c0dcbfb0. Apr 2 23:27:18 fslx01 kernel: klips_debug:pfkey_sa_process: . Apr 2 23:27:18 fslx01 kernel: klips_debug:pfkey_msg_interp: processing ext 6 c6591be0 with processor c0dcc280. Apr 2 23:27:18 fslx01 kernel: klips_debug:pfkey_address_process: Apr 2 23:27:18 fslx01 kernel: klips_debug:pfkey_address_process: found address family=2, AF_INET, 80.135.xxx.xxx. Apr 2 23:27:18 fslx01 kernel: klips_debug:pfkey_address_process: found dst address. Apr 2 23:27:18 fslx01 kernel: klips_debug:pfkey_address_process: tdb_said.dst set to 80.135.xxx.xxx. Apr 2 23:27:18 fslx01 kernel: klips_debug:pfkey_address_process: successful. Apr 2 23:27:18 fslx01 kernel: klips_debug:pfkey_msg_interp: processing ext 18 c6591bf8 with processor c0dccb00. Apr 2 23:27:18 fslx01 kernel: klips_debug:pfkey_x_satype_process: . Apr 2 23:27:18 fslx01 kernel: klips_debug:pfkey_alloc_ipsec_sa: allocated tdb struct=c2effe6c. Apr 2 23:27:18 fslx01 kernel: klips_debug:pfkey_x_satype_process: protocol==50 decoded from satype==3(ESP). Apr 2 23:27:18 fslx01 kernel: klips_debug:pfkey_msg_interp: processing ext 19 c6591c00 with processor c0dcbfb0. Apr 2 23:27:18 fslx01 kernel: klips_debug:pfkey_sa_process: . Apr 2 23:27:18 fslx01 kernel: klips_debug:pfkey_alloc_ipsec_sa: tdb struct already allocated Apr 2 23:27:18 fslx01 kernel: klips_debug:pfkey_msg_interp: processing ext 20 c6591c10 with processor c0dcc280. Apr 2 23:27:18 fslx01 kernel: klips_debug:pfkey_address_process: Apr 2 23:27:18 fslx01 kernel: klips_debug:pfkey_address_process: found address family=2, AF_INET, 80.135.xxx.xxx. Apr 2 23:27:18 fslx01 kernel: klips_debug:pfkey_address_process: found 2nd dst address. Apr 2 23:27:18 fslx01 kernel: klips_debug:pfkey_alloc_ipsec_sa: tdb struct already allocated Apr 2 23:27:18 fslx01 kernel: klips_debug:pfkey_address_process: tdb_said.dst set to 80.135.xxx.xxx. Apr 2 23:27:18 fslx01 kernel: klips_debug:pfkey_address_process: successful. Apr 2 23:27:18 fslx01 kernel: klips_debug:pfkey_msg_interp: parsing message type 13 with msg_parser c0dcfc10. Apr 2 23:27:18 fslx01 kernel: klips_debug:pfkey_x_grpsa_parse: . Apr 2 23:27:18 fslx01 kernel: klips_debug:gettdb: linked entry in tdb table for hash=147 of SA:comp0x4dea@80.135.xxx.xxx requested. Apr 2 23:27:18 fslx01 kernel: klips_debug:gettdb: linked entry in tdb table for hash=196 of SA:esp0xdbc257a2@80.135.xxx.xxx requested. Apr 2 23:27:18 fslx01 kernel: klips_debug:pfkey_msg_hdr_build: Apr 2 23:27:18 fslx01 kernel: klips_debug:pfkey_msg_hdr_build: on_entry &pfkey_ext=c2effd48 pfkey_ext=c2effdd8 *pfkey_ext=00000000. Apr 2 23:27:18 fslx01 kernel: klips_debug:pfkey_msg_hdr_build: on_exit &pfkey_ext=c2effd48 pfkey_ext=c2effdd8 *pfkey_ext=c8237ae0. Apr 2 23:27:18 fslx01 kernel: klips_debug:pfkey_safe_build: error=0 Apr 2 23:27:18 fslx01 kernel: klips_debug:pfkey_safe_build:success. Apr 2 23:27:18 fslx01 kernel: klips_debug:pfkey_sa_build: spi=00004dea replay=0 sa_state=0 auth=0 encrypt=0 flags=0 Apr 2 23:27:18 fslx01 kernel: klips_debug:pfkey_safe_build: error=0 Apr 2 23:27:18 fslx01 kernel: klips_debug:pfkey_safe_build:success. Apr 2 23:27:18 fslx01 kernel: klips_debug:pfkey_address_build: exttype=6 proto=0 prefixlen=0 Apr 2 23:27:18 fslx01 kernel: klips_debug:pfkey_address_build: found address family AF_INET. Apr 2 23:27:18 fslx01 kernel: klips_debug:pfkey_address_build: found address=80.135.xxx.xxx:500. Apr 2 23:27:18 fslx01 kernel: klips_debug:pfkey_address_build: successful. Apr 2 23:27:18 fslx01 kernel: klips_debug:pfkey_safe_build: error=0 Apr 2 23:27:18 fslx01 kernel: klips_debug:pfkey_safe_build:success. Apr 2 23:27:18 fslx01 kernel: klips_debug:pfkey_x_satype_build: Apr 2 23:27:18 fslx01 kernel: klips_debug:pfkey_safe_build: error=0 Apr 2 23:27:18 fslx01 kernel: klips_debug:pfkey_safe_build:success. Apr 2 23:27:18 fslx01 kernel: klips_debug:pfkey_sa_build: spi=dbc257a2 replay=0 sa_state=0 auth=0 encrypt=0 flags=0 Apr 2 23:27:18 fslx01 kernel: klips_debug:pfkey_safe_build: error=0 Apr 2 23:27:18 fslx01 kernel: klips_debug:pfkey_safe_build:success. Apr 2 23:27:18 fslx01 kernel: klips_debug:pfkey_address_build: exttype=20 proto=0 prefixlen=0 Apr 2 23:27:18 fslx01 kernel: klips_debug:pfkey_address_build: found address family AF_INET. Apr 2 23:27:18 fslx01 kernel: klips_debug:pfkey_address_build: found address=80.135.xxx.xxx:500. Apr 2 23:27:18 fslx01 kernel: klips_debug:pfkey_address_build: successful. Apr 2 23:27:18 fslx01 kernel: klips_debug:pfkey_safe_build: error=0 Apr 2 23:27:18 fslx01 kernel: klips_debug:pfkey_safe_build:success. Apr 2 23:27:18 fslx01 kernel: klips_debug:pfkey_msg_build: pfkey_msg=c6591ec0 allocated 104 bytes, &(extensions[0])=c2effdd8 Apr 2 23:27:18 fslx01 kernel: klips_debug:pfkey_msg_build: copying 16 bytes from extensions[1]=c8237d80 to=c6591ed0 Apr 2 23:27:18 fslx01 kernel: klips_debug:pfkey_msg_build: copying 24 bytes from extensions[6]=c8237ea0 to=c6591ee0 Apr 2 23:27:18 fslx01 kernel: klips_debug:pfkey_msg_build: copying 8 bytes from extensions[18]=c8237f60 to=c6591ef8 Apr 2 23:27:18 fslx01 kernel: klips_debug:pfkey_msg_build: copying 16 bytes from extensions[19]=c8237fa0 to=c6591f00 Apr 2 23:27:18 fslx01 kernel: klips_debug:pfkey_msg_build: copying 24 bytes from extensions[20]=c8237ee0 to=c6591f10 Apr 2 23:27:18 fslx01 kernel: klips_debug:pfkey_msg_build: extensions permitted=001c0043, seen=001c0043, required=00000043. Apr 2 23:27:18 fslx01 kernel: klips_debug:pfkey_upmsg: allocating 104 bytes... Apr 2 23:27:18 fslx01 kernel: klips_debug:pfkey_upmsg: ...allocated at d1dac0c0. Apr 2 23:27:18 fslx01 kernel: klips_debug:pfkey_x_grpsa_parse: sending up x_grpsa reply message for satype=10(COMP) to socket=da989554 succeeded. Apr 2 23:27:18 fslx01 kernel: klips_debug:pfkey_x_grpsa_parse: succeeded in sending x_grpsa reply message. Apr 2 23:27:18 fslx01 pluto[11995]: | 02 00 01 f4 50 87 61 66 00 00 00 00 00 00 00 00 Apr 2 23:27:18 fslx01 pluto[11995]: | 03 00 15 00 00 00 00 00 02 00 00 00 c0 a8 02 00 Apr 2 23:27:18 fslx01 pluto[11995]: | 78 d7 ff bf 83 6d 0d 40 03 00 16 00 00 00 00 00 Apr 2 23:27:18 fslx01 pluto[11995]: | 02 00 00 00 c0 a8 01 00 78 d7 ff bf 83 6d 0d 40 Apr 2 23:27:18 fslx01 pluto[11995]: | 03 00 17 00 00 00 00 00 02 00 00 00 ff ff ff 00 Apr 2 23:27:18 fslx01 pluto[11995]: | 00 00 00 00 00 00 00 00 03 00 18 00 00 00 00 00 Apr 2 23:27:18 fslx01 pluto[11995]: | 02 00 00 00 ff ff ff 00 40 38 30 2e 31 33 35 2e Apr 2 23:27:18 fslx01 pluto[11995]: | pfkey_get: SADB_X_ADDFLOW message 31 Any Ideas? Dennis
On Wed, Apr 02, 2003 at 11:08:58PM +0200, Dennis Bendowski wrote:
Der Rechner Deines Kollegen erhält genau die IP-Nummer, die er hat. Du setzt schließlich einen Tunnel auf, und kein NAT oder so etwas.
Wie meinst Du "erhält genau die IP, die we hat" denn jetzt?
Gegeben dieses Netzwerk: .3 Spielrechner | |--+-+------- 192.168.200.0/24 ----| <- Kollege | .1 Router | 195.244.233.33 +=========== Tunnel ==============+ 195.244.233.49 | .1 Router | |--+---- 192.168.100.0/24 ----------------+----| <- Du | .3 Spielrechner Dann kannst Du von 192.168.100.3 aus den Rechner 192.168.200.3 anpingen, so der Tunnel funktioniert. Zwischen dem Router 195.244.233.49 (Dein Router) und dem Router 195.244.233.33 (Router Deines Freundes) sieht Du Protocol 50 (ESP Tunnel Mode) Pakete mit der Absenderadresse 195.244.233.49 und der Zieladresse 195.244.233.33. Darin sind, verschluesselt und nicht erkennbar, die IP-Pakete mit der Absenderadresse 192.254.200.3 und der Zieladresse 192.168.100.3 enthalten. Auf 192.168.100.3 muss eine Route zu 192.168.200.0/24 eingerichtet werden, mit 192.168.100.1 als Gateway. Entsprechend muss 192.168.200.3 eine Route auf die 192.168.100.0/24 bekommen mit 192.168.200.1 als Gateway.
Was ich leider immer noch nicht verstanden habe, ist, was jetzt ganz genau mit left, right, leftnexthop, rightnexthop gemeint ist...
left und right stehen austauschbar für local und remote Side des Tunnels, man hat nicht local und remote genommen, weil die Konfigurationsdatei des FreeSWAN für beide Seiten austauschbar (d.h. gleich) sein soll. left und right sind die Tunnelendadressen, leftsubnet und rightsubnet sind die Netze hinter dem Tunnel. leftnexthop und rightnexthop sind Kludges, die notwendig sind, weil sich KLIPS (die FreeSWAN-Kernelschicht) nicht richtig in die Routinglayer des Kernels einfügt und daher nicht weiß, wo die ESP-Pakete hinzusenden sind. Es ist das Gateway, an das die ESP-Pakete zu senden sind, also in Deinem Fall in jedem Fall %defaultrouter (Es ist immer %defaultrouter einzutragen, wenn das Netzwerk ein Blattnetz ist, also nur einen Ausgang ins Internet hat. Es ist immer die Tunnelendadresse der Gegenseite einzutragen, wenn beide Tunnelenden auf demselben shared media (d.h. demselben Ethernetsegment) liegen, also in allen Testaufbauten für FreeSWAN). Zum Debuggen brauchst Du außerdem ein ping von 192.168.100.3 nach 192.168.200.3 und dann die Ausgaben von tcpdump -i eth0 und tcpdump -i ppp0 auf 195.244.233.49/192.168.100.1. Kristian
Hallo Kristian,
-----Ursprüngliche Nachricht----- Von: Kristian Koehntopp [mailto:kris@koehntopp.de] Gesendet: Donnerstag, 3. April 2003 10:01
Also ich habe jetzt gestern zwei unterschiedliche Subnetze eingerichtet (1. bei mir, 2. beim Kollegen). Die Router sind jetzt nach einem Start der VPN-Verbindung noch erreichbar (besser *g*). Wenn ich nun die VPN Verbindung starte, erhalte ich auf der Konsole router01:/etc # ipsec auto --up vpn 104 "vpn" #1: STATE_MAIN_I1: initiate 106 "vpn" #1: STATE_MAIN_I2: sent MI2, expecting MR2 108 "vpn" #1: STATE_MAIN_I3: sent MI3, expecting MR3 004 "vpn" #1: STATE_MAIN_I4: ISAKMP SA established
bis hier scheint meiner Meinung nach alles i.O.
112 "vpn" #2: STATE_QUICK_I1: initiate 003 "vpn" #2: route-client command exited with status 7 032 "vpn" #2: STATE_QUICK_I1: internal error 010 "vpn" #2: STATE_QUICK_I1: retransmission; will wait 20s for response 003 "vpn" #2: route-client command exited with status 7 032 "vpn" #2: STATE_QUICK_I1: internal error qrouter01:/etc # ipsec auto --up vpn 112 "vpn" #3: STATE_QUICK_I1: initiate 003 "vpn" #3: route-client command exited with status 7 032 "vpn" #3: STATE_QUICK_I1: internal error 010 "vpn" #3: STATE_QUICK_I1: retransmission; will wait 20s for response 003 "vpn" #3: route-client command exited with status 7 032 "vpn" #3: STATE_QUICK_I1: internal error 003 "vpn" #3: route-client command exited with status 7 032 "vpn" #3: STATE_QUICK_I1: internal error 010 "vpn" #3: STATE_QUICK_I1: retransmission; will wait 40s for response 031 "vpn" #3: max number of retransmissions (2) reached STATE_QUICK_I1. No acceptable response to our first Quick Mode message: perhaps peer likes no proposal 000 "vpn" #3: starting keying attempt 2 of an unlimited number, but releasing whack Ich habe mal nach den Routen geschaut.... router01:/etc # route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface xxx.xxx.xxx.xxx * 255.255.255.255 UH 0 0 0 ppp0 xxx.xxx.xxx.xxx * 255.255.255.255 UH 0 0 0 ipsec0 192.168.1.0 * 255.255.255.0 U 0 0 0 eth0 192.168.10.0 * 255.255.255.0 U 0 0 0 eth1 default xxx.xxx.xxx.xxx 0.0.0.0 UG 0 0 0 ppp0 Ist das so richtig? Eigentlich müsste ipsec0 doch eine interne IP haben und dann eine Gateway IP, oder? Konfigs sind jetzt so aufgebaut: router01:/etc # cat ipsec.conf # basic configuration config setup interfaces=%defaultroute klipsdebug=all plutodebug=all plutoload=%search plutostart=%search uniqueids=no conn %default keyingtries=0 compress=yes disablearrivalcheck=no authby=secret #authby=rsakey #leftrsasigkey=%cert #rightrsasigkey=%cert #leftid="xxxxmail" #rightid="xxxxport" conn vpn left=ich_ddns leftsubnet=192.168.1.0/24 #leftnexthop=%defaultroute #leftid=@router01.dbendowski.do #leftfirewall=yes right=kollege_ddns rightsubnet=192.168.2.0/24 #rightnexthop=kollegenexthop #rightfirewall=yes #rightid=@fsmw01.local.ips type=tunnel auto=add #authby=rsasig authby=secret #leftcert=mail.xxx.de.pem #rightcert=port.xxx.de.pem #keyexchange=ike Habe auch schon versucht, als left und right mal die internen Ips der Router zu nehmen, dann sagt er, er hätte kein passendes ipsec Device zum Ziel. Firewall an od. aus, nexthops weg hab ich auch schon versucht, bringt alles nix, er hängt jetzt immer an der Stelle STATE_QUICK_I1... Langsam verzweifle ich... Ich weiss nicht wo der Fehler noch sein kann...... Hoffe Du hast noch Ideen. Danke und mit freundlichen Grüßen Dennis
Hi Dennis! Hier mal schnell meine Vtun Configs: Server: Aus der Datei vtund.conf löscht Du die ersten einträäge bis hier: # ----- CUT HERE --- Server config --- CUT HERE ----- # #Dann sollte die Datei so aussehen: options { port 5000; # Listen on this port. # Path to various programs ppp /usr/sbin/pppd; ifconfig /sbin/ifconfig; route /sbin/route; firewall /sbin/ipchains; } # Default host options default { compress no; # Compression is off by default speed 0; # By default maximum speed, NO shaping } #Das waren die globalen ooptionen. #Jetzt kommen die einzelnen VPN-User: # Offenau vpn-1 { pass irgendeinkennwort; # Password comp yes; # ZLIB compression level 1 encr yes; # Encryption up { # Connection is Up (established) ppp "192.168.91.1:192.168.91.2"; route "add -net 2.0.0.0 netmask 255.0.0.0 gw 192.168.91.2"; }; #persist yes; } #Zu beachten: 1.0.0.0 ist Dein Netz. 2.0.0.0 ist das Netz deines Freundes #als Beispiel. #Nun starten wir den Server. In der Konsole gibst Du einfach #/usr/local/sbin/vtund -s -n #ein. Damit lauscht er auf Port 5000 und wartet auf dem Client. #Nun die Clientconfig :-) #Beim Client ebenfalls die Datei vtund.conf öffnen. #Hier alles löschen bis # # ----- CUT HERE --- Client config --- CUT HERE ----- # #Nun zu den Globalen OPtionen: options { port 5000; # Connect to this port. # persist yes; # Persist mode timeout 60; # General timeout # Path to various programs ppp /usr/sbin/pppd; ifconfig /sbin/ifconfig; route /sbin/route; firewall /sbin/ipchains; } #Und nun die Optionen, die er zum connecten brauch: vpn-1 { pass irgendeinkennwort; up { ppp"192.168.91.2:192.168.91.1"; route "add -net 1.0.0.0 netmask 255.0.0.0 gw 192.168.91.1"; } } #Das wars auch eigendlich. #Jo, jetzt noch den Client starten: #/usr/sbin/vtund -n vpn-1 DeineExterneServerIp # Das wars! Hoffe es ist OK so. Was Du n och machen musst ist Deine Netzwerkangaben hier einfügen. Am besten macht ihr zwei getrennte Netze, Du nimmst die 192.168.1.0/255.255.255.0 und Dein Kollege 192.168.2.0/255.255.255.0 Wenn noch Probleme sind, mail einfach, am besten per PM bitte!! (noch besser an stefan.eggert@exel.com) Stefan
participants (3)
-
Dennis Bendowski -
Kristian Koehntopp -
Stefan Eggert