"Routingproblem" mit ipsec (OpenS/WAN)

[Stephan Sachse]

On Fri, May 9, 2008 at 3:08 PM, Matthias Borrack <mailingliste at sinath.de> wrote:
> 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?

ip r a 192.168.1.68 via <GATEWAY> src 172.20.1.1

wir dafuer sorgen das 172.20.1.1 als src-ip fuer ausgehende Paket zu
192.168.1.68 genutzt wird. Das sollte vorzugsweise in
/etc/sysconfig/network-scripts/route-eth0 sthen wenn es ueber eth0
geht. Dann aber ohne das "ip r a" davor!

pruefen was Anwendung findet kannst du per

ip r g 192.168.1.68

/stephan

-- 
"Software is like sex, it's better when it's free!"