OpenSWAN zur Verbindung zweier geNATteter Netze

[feltel]

Ich bin gerade dabei OpenSWAN einzurichten um zwei Netzwerke miteinander zu verbinden. Bei Netzwerke haben jeweils einen Debian-Rechner als Gateway der auch NAT macht. Die Gateways laufen jeweils unter Sarge mit einem 2.4er Kernel.

Das Herstellen des VPN-Tunnels ist kein Problem; ich kann auch von einem ins andere Netz pingen (z.B. von meinem Rechner auf den Netzwerkdrucker in Netz B). Was jeder nicht geht ist das ich z.B. von Netz A aus den Apache der auf Gateway-Rechner B läuft aufrufen kann. iptables schließe ich mal als Ursache aus da ich alle iptables-Meldungen logge und während ich das alles probiert hab nix iptables-mäßiges in den Logs ankam.

Ich hab ein wenig gegoogelt und bin dabei auf die OpenSWAN-Einstellung nat_traversal=yes und den dazugehörigen Kernel-Patch [1] gestoßen. Kann es sein, das mir genau dieser Patch fehlt und das pingen geht da es über ICMP-Messages läuft?

[1] http://www.openswan.org/download/opensw ... t.patch.gz

[feltel]

Ich bin ein Stückchen weiter aber nun erst Recht verwirrt:

Code: Alles auswählen

beedo:/home/feltel# ipsec verify
Checking your system to see if IPsec got installed and started correctly:
Version check and ipsec on-path                                         [OK]
Linux Openswan U2.2.0/Kversion: (klips)
Checking for IPsec support in kernel                                    [OK]
Checking for RSA private key (/etc/ipsec.secrets)                       [OK]
Checking that pluto is running                                          [OK]
Two or more interfaces found, checking IP forwarding                    [OK]
Checking NAT and MASQUERADEing
Checking tun0x1002@xx.xxx.xxx.x from 10.0.144.0/21 to 10.0.1.0/24    [FAILED]
MASQUERADE from 10.0.145.0/24 to 0.0.0.0/0 kills tunnel 10.0.145.0/24 -> 10.0.1.0/24
Checking for 'ip' command                                               [OK]
Checking for 'iptables' command                                         [OK]

Opportunistic Encryption DNS checks:
   Looking for TXT in forward dns zone: beedo                           [MISSING]
beedo.nz1.rahn-schulen.de has no TXT record (Authoritative answer)
   Does the machine have at least one non-private address?              [OK]
   Looking for TXT in reverse dns zone: yyy.yyy.yyy.yyy.in-addr.arpa.     [MISSING]
yyy.yyy.yyy.yyy.in-addr.arpa TXT record currently not present

Aber ohne MASQUERADE kommen doch die Clients hinter dem Router nicht ins Internet raus.

[Feuerzwerg]

Wenn ich die Ausgabe richtig interpretiere, versuchst du die Pakete die ueber den Tunnel gehen sollen genau so zu maskieren, wie die Pakete die ins INET gehen sollen. Das wuerde aber wohl dazu fuehren, dass die Pakete am anderen Ende des Tunnels verworfen werden, weil sie nicht von 10.0.145.0/24 kommen.

[feltel]

Hmmm, ich hab mal das von mir benutzte Firewall-Script unter http://www.feltel.de/FirewallScript abgelegt.

[Feuerzwerg]

Ich muss leider zugeben, dass ich mich mit iptables nur recht selten direkt beschaeftige und daher kenn ich mich auch nicht besonders gut damit aus. Aber ich glaube du solltest hier

Code: Alles auswählen

   #Set up NAT so that machines on our LAN can use our DSL router:
   $IPT -t nat -A POSTROUTING -o $EXTDEV -s $INTLAN -j MASQUERADE

noch sowas wie -d ! 10.0.1.0/24 hinzufuegen.

Hmm wenn ich nochmal so darueber nachdenke macht es eigentlich doch keinen Sinn, weil ja der Traffic ins andere Netz ueber das tunnel-interface geht. ueber das $EXTDEV sollte ja nur udp-traffic mit dem router als absender gehen. Hmm naja probiers vielleicht mal.

[mistersixt]

Ja, das könnte in der Tat das Problem sein, ich mache das so: Pakete, die durch den Tunnel gehen sollen, werden einfach ACCEPTed, erst anschliessend werden alle anderen Pakete masqueriert:

Code: Alles auswählen

$IPTABLES -A POSTROUTING -t nat                -d 192.168.7.0/24    -j ACCEPT
$IPTABLES -A POSTROUTING -t nat                -d 192.168.180.0/24  -j ACCEPT
$IPTABLES -A POSTROUTING -t nat                -d 192.168.50.0/24   -j ACCEPT
...
$IPTABLES -A POSTROUTING -t nat -s 10.3.0.0/24 -o $EXTIF            -j MASQUERADE

Weil ja beim Treffer einer iptables-Rule die nachfolgenden Regeln verworfen werden, gehen also hier nur Pakete, die nicht in die VPN-Gegenseite gehen sollen, per Masquerading ins Internet.

Gruss, mistersixt.


PS: Aah, ich lese jetzt erst, dass Du von Netz A aus nicht auf den Apache vom Gateway vin Netz B zugreifen kannst. Habe ich bei mir auch gerade probiert, das geht hier auch nicht (OpenSwan 2.2, Sid, Kernel-2.6.8 ).