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?
Danke und Grüße, Matthias
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
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
On Fri, May 9, 2008 at 3:08 PM, Matthias Borrack mailingliste@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
de-users@lists.fedoraproject.org
-
Christoph Wickert -
Matthias Borrack -
Stephan Sachse