Hi, thank you very much bleve and letoto from #openswan (irc.freenode.net)! Short story about -j SNAT -o ipsec0: usually just omit the "-o ipsec0", pass --source and --destination. This works, because applied before considering tunneling. So an example rule for "SNAT before IPSec" could be: iptables -t nat -A POSTROUTING -j SNAT \ -d 192.168.88.0/24 --to-source 192.168.87.4 (Attention: the anonymized IP addresses in this posting are not consistent.) The URL that solved this was: http://lists.openswan.org/pipermail/users/2006-March/008819.html * Steffen Dettmer wrote on Wed, Jan 17, 2007 at 00:49 +0100:

Hi,

ich bastel gerade an einem auf SuSE 10.2 basierenden Homerouter. Der soll dabei etliche Aufgaben des jetzigen 8.2 Servers übernehmen.

Nun hab ich endlich DSL und Freunde erstmal an und die /etc/sysconfig/SuSEfirewall Konfiguration per Hand "gemergt".

Ich hab die ipsec-configs (FreeS/WAN freeswan-1.99_0.9.34-93) kopiert und "interface=%defaultroute" entfernt.

Völlig überraschenderweise bekomme ich auch gleich eine SA :-)

Dazu muss ich inzwischen leider hinzufügen, dass IPSec via dialup immernoch ne Krücke ist. SuSE komisches ip-up.d/freeswan script half bei mir nix. Ich hatte mir damals auch einen ip-up.d-Mechanismus gebastelt. Da wurden die Dateien der Reihenfolge nach gestartet. Die hab ich in ip-up.d nach dem Schema S01 usw benannt und in down K01 usw. Die Idee ist geklaut, OK, aber geht. Warum SuSE das in ip-up.d anders macht? Keine Ahnung, noch nicht weiter geguckt. chmod -x freeswan und ein rsync half :) (Bin ja seit SuSE 5.3 oder wann das mit dem ISDN losging gewohnt, /etc/ppp/ip-up und Freunde selbst zu machen... Irgrendwann wird es funktionieren :)) in ip-up mach ich jetzt: o sound effect S01fx.sh o IPSec kram S02vpn.sh - /etc/rc.d/ipsec stop - /sbin/route del default - /sbin/route add default device $INTERFACE gw $REMOTEIP - sleep 1 - /etc/rc.d/ipsec start - /usr/sbin/ipsec auto --up issjaauch-egal o traffic shaping S08qdis_low o dyn DNS S10dynname.sh o fetchmail --monitor S50fetchmail.sh (gibt inzwischen ne Warnung, mag nicht root sein, "su - mailuser -C") o /usr/sbin/sendmail -q (Ja, geht auch mit postfix - bin nich sicher, obs das gleiche tut, weil ich noch einen postfix flush cron hab) Falls jemand Interesse hat, mail /dev/null. Ähh, mail me :)

$ rcipsec start $ ipsec auto --up me-placeholder 117 "me-placeholder" #3: STATE_QUICK_I1: initiate 004 "me-placeholder" #3: STATE_QUICK_I2: sent QI2, IPsec SA established {ESP=>0xcccccccc <0xcccccccc xfrm=3DES_0-HMAC_SHA1 NATD=none DPD=none}

(sah beim ersten Mal natürlich etwas ausführlicher aus, wollte nur zeigen, dass es klappt :))

Etwas in der Art von rcipsec start brauch ich immer noch im ip-up.

Im Internet fand ich wenig hilfreiche Hinweise, dass es ipsec0 (und so weiter) nicht mehr gibt. hum. Und nu?

ipsec0 gab es bei KLIPS (i.d.R. 2.4er kernel), bei 2.6er gibts NETKEY und das hat kein so'n dev mehr, sondern reinjected the packets.

Nun weiss ich nichtmal, wie ich PING testen soll. Das -I 192.168.87.4 kommt natürlich mit "cannot assign requested address" zurück, weil es ja für diese "VPN-IP" gar kein Interface mehr gibt!

Das kriegt man hin, in dem man z.B. ans interne interface dies als alias hängt und's PING ist glücklich. Sehr gut geht auch nmap -vvv -sT -P0 10.a.b.c -p 22 -S 10.a.b.dd (ssh kann man ja keine Quell-IP angeben, oder?)

Ich hab sowas wie

/usr/sbin/iptables -t nat -A POSTROUTING -j SNAT \ --to-source 192.168.87.4 -d 192.168.88.0/24

gemacht. Da war früher (bei 8.2) noch ein "-o ipsec0" dran.

Und das ist genau so richtig!!!! JAHA! Drei Tage Arbeit, aber der erste Versuch war richtig! Herzlichen Glückwunsch, Steffen! loooooool Im Fall wie oben kann man das "-o ipsec0" tatsächlich einfach weglassen, die Regel wird vor dem tunneln angewendet und funktioniert damit. Ich hab das jetzt übrigens in /etc/sysconfig/scripts/SuSEfirewall2-`hostname` in fw_custom_before_antispoofing geschrieben. Funktioniert! :) Am Ende war es eine Kombination von einem Problemchen mit SuSEfirewall, dem Fakt, dass SuSEfirewall stop auch gleich mal das ip_forward abschaltet, selbst wenn man konfiguriert, dass es angeschaltet sein soll, dem Fakt, dass LOG_ALL_REJECT=yes natürlich nicht alles loggt, sondern ein limit hat, was heute im inet natürlich sofort voll ist und dem Problem, dass ich bei meinen Tests von den drei Problemen immer nur maximal zwei gleichzeitig gelöst hatte.

Der Hammer ist nun ein "tcpdump -n -i dsl0 icmp":

00:26:14.794304 IP 100.200.100.77 > 192.168.88.29: ICMP echo request, id 48945, seq 3, length 64

Wobei 100.200.100.77 meine lokale IP von dsl0 (vom Provider) und 192.168.88.0/24 das entfernte Netz sei.

Wenn mich meine trüben Augen nicht trügen werden da meine vertraulichen 192.168er Daten brutalst im Klartext ins Internet geballert. ARGHHHHHHHHHHHH Super. Ich erwarte hier aber ESP (protocol 50) Pakete. Verschlüsselt!

Dass man da Klartextpakete sieht, die da "nicht hingehören", ist korrektes Verhalten. Die Antworten werden sowohl als ESP als auch als Klartext gedumpt. Daher besser immer "icmp or proto 50" tracen (es ist heute also nicht mehr exklusiv nur eines da). Achtung, das oben gezeigte Beispiel eines AUSgehenden PINGs passiert SO NICHT! Man würde ein echo REPLY sehen. Das Beispiel oben war wohl gerade mit falscher NAT Regel oder so, da haben die Pakete nicht auf den Tunnel gematcht, wurden danach geNATet (ich glaub, die NAT Regel wird zweimal probiert, bin aber nicht sicher, geht ja jetzt, bloss nich anfassen :)). Bei PING ist also zu erwarten: you > peer ESP(spi=0xballerballer) peer > you ESP(spi=0xdeadbeef) 192.1 > 192.2 echo reply, id 1, seq 2143121 (you: lokale routebare IP [vom ISP], peer IP des peergateways, 192.1 und 192.2 symbolisch für das virPriv Netz selbst)

Wie trace ich Klartext (falls ESP dann mal läuft), wo ich doch kein ipsec0 habe?

Ausgehenden Klartext kann man anscheinend nicht tracen (!). oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel. -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org