"Routingproblem" mit ipsec (OpenS/WAN)

[Matthias Borrack]

Hallo Christoph

Danke für Deine Antwort, aber ...

Christoph Wickert schrieb:
> Am Freitag, den 09.05.2008, 15:08 +0200 schrieb Matthias Borrack:
>> Hallo zusammen
>>
>> Ich habe zwei Server die per ipsec miteinander verbunden sind 
>> (net-to-net). Auf dem einen (ServerA) läuft u. a. ein OpenVPN-Server, 
>> der die Benutzer über die AD authentifizieren soll. Dummer Weise ginge 
>> das nur, wenn ich, wie beim Ping, das Interface mit angebe, da 
>> Verbindungen von ServerA in das Subnetz hinter ServerB sonst mit der 
>> öffentlichen IP-Adresse weggehen bzw. ankommen
>>
>> # tcpdump -i eth0 icmp
>> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
>> listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
>> 15:01:09.297502 IP vpn2.server.de > 192.168.1.68: ICMP echo request, id 
>> 28444, seq 43, length 64
>> 15:01:10.297494 IP vpn2.server.de > 192.168.1.68: ICMP echo request, id 
>> 28444, seq 44, length 64
>> 15:01:11.297493 IP vpn2.server.de > 192.168.1.68: ICMP echo request, id 
>> 28444, seq 45, length 64
>>
>> Ein
>> ping -I 172.20.1.1 192.168.1.68
>> wird dann auch beantwortet.
>>
>> Daran scheitert dann auch alle lokalen Dienste, die ich nicht auf ein 
>> anderes als das öffentliche Interface binden kann. Nicht nur das 
>> ldapsearch und dapwhoami, sondern auch sowas banales wie portforwarding 
>> funktionier nur mit SNAT.
>>
>> Jemand Idee oder einen Workaround?
> 
> Eine Bridge, wie Alexey Kuznetsov es in seinem Blog beschreibt:
> http://blog.axet.ru/2008/04/openvpn-with-fedora-8.html
> (leider auf Russisch, aber die Skripts kann man lesen.)
>> Danke und Grüße,
>> Matthias
> 
> Christoph
... was sollte sich dann ändern? Ob er jetzt die öffentlich IP-Adresse 
auf dem physikalischen Interface oder auf einer Bridge hat, es ist immer 
noch die öffentliche IP-Adresse.

Ich stolper hier gerade über das "Zwei-Gateways-Syndrom". Alle Anfragen 
von ClientA1, der per OpenVPN mit ServerA verbunden ist und an ServerB1 
im internen LAN gerichtet sind, gehen über den ipsec-Tunnel zum ServerB, 
weil dieser aufgrund des SiteToSite-ipsec für den ServerA und damit für 
ClientA1 der Gateway zum LAN B ist. Vom LAN A zum LAN B funktioniert ja 
auch alles, aber von ServerA zu LAN B geht nicht, weil dieser ja mit der 
öffentlichen IP-Adresse rein kommt und die Hosts im LAN B dann die 
Antwort an die öffentliche IP-Adresse schicken. Wieso sollte ServerA 
diese Antworten wahrnehmen? Wenn ich meiner Frau eine Frage stelle und 
ihre Mutter antwortet, interessierts mich ja auch nicht ;)

Einziger Workaround der mir dazu einfällt, wäre offensichtlich nur 
Vergewaltigung über [S,D]NAT oder Routing. Darum mag ich kein ipsec, 
weil es solch trivialen Dinge wohl nicht kann :(
Dummerweise kann die Gegenstelle (eine ASG) keine Net-to-Net-OpenVPN, 
dass würde alle Probleme mit einem Schlag beseitigen. Und Statt 
Net-To-Net ein Roadwarrior mit ipsec wäre auch keine Lösung, oder weiß 
jemand, wie man ein Netz als Roadwarrior definiert?

Dank & Grüße,
Matthias