[geloest] ip_forward blockt vpn

starter · 9 Juni 2006

Tach, habe folgendes Problem:
wenn ich ip_forward mit 1 auf meinem suse 10.1 server belege kann sich kein Client mehr von ausserhalb per openVPN in mein Netzwerk einwählen. Habe ich ip_forward deaktiviert (also mit 0 belegt) steht die Verbindung von den Clients ausserhalb zu meinem openVPN Server.

Warum ich dann ip_forward machen möchte? Weil ich von den Clients von aussen nicht auf die Clients in meinem internen Netzwerk gelange. Und ich dachte die Lösung sei ip_forward, da ich zwei netzwerkkarten auf dem Server habe. (intern / extern)

nbkr · 9 Juni 2006

ip_forward ist nicht alles da muss auch die Routingtabelle des Servers und der Clients passen.

starter · 9 Juni 2006

.... wo wir dann doch wieder beim anderen thread wären....

O.K. mal anders.

Habe ja eth0 und eth1 (zwei reale Netzwerkkarten) im Server
zudem kommt noch tun0

wo und wie bestimme ich nun am Server, dass alle Nachrichten die an eth0 (intern) rein kommen und das Ziel 10.0.x.x haben, an tun0 weitergeleitet werden?

danke für die geduld

nbkr · 9 Juni 2006

Dafür gibts routingeinträge. So in etwa

Code:

route add 10.0.0.0/8 gw (IP Adresse des tun0 Interfaces) dev tun0

Ist aber eigentlich überflüssig da eine solche Route automatisch hinzugefügt wird wenn Du ein Interface im 10.0.0.0/8 Netz hast. Linux denkt da schon soweit mit. Es sagt sich 10.0.0.0/8 - da hab ich doch eine Netzwerkkarte die in dem Netz ist - dann brauch ich die Daten ja gar nicht an einen anderen Router schicken, das baller ich einfach über meine Netzwerkkarte raus.

Wichtig ist natürlich das nicht nur der Hinweg stimmt sonder auch der Rückweg. D.h. Du musst immer prüfen ob Du nicht nur von A nach B sondern auch von B nach A kommst.

D.h. deine Clients die im Lan hängen haben ja einer IP aus dem Bereich 192.168.x.0/24

Die Roadwarrior haben zwei IP Adressen. Eine virutelle auf tun0 und eine auf eth0.

Eth0 = 192.168.y.k/24
tun0 = 10.0.0.u/8

Wenn aus dem LAN jetzt was an die Roadwarrior geht hat das TCP Paket folgende Daten:

Ziel: 10.0.0.u
Quelle: 192.168.y.k

Da 10.0.0.u nicht im Netz der LAN Clients liegt wird es an das Default Gateway geschickt. Das sollte eth0 der VPN Servers sein. Der schaut sich das Paket an und sollte es dann an 10.0.0.u weiterleiten da er das ja über die eigene VPN tun0 erreicht.

Der Roadwarrior bekommt jetzt das Paket und muss jetzt eine Antwort schicken. Das heißt er bastelt ein neues Paket mit dem Inhalt:

Ziel: 192.168.y.k
Quelle: (kommt drauf an).

Da 192.168.y.k nicht im eingenen Netz des Roadwarriors liegt (weder im tun0 noch im eth0) muss er es ans Default Gateway schicken. Bei der Standardkonfiguration von OpenVPN ist das Defaut Gateway aber der Router welcher über eth0 erreicht werden kann. Nicht der VPN Server. Ergo kommt das Paket nicht zurück.

Das kann man jetzt auf 2 Arten lösen.

Lösung1: Man trägt bei den Roadwarriorn den VPN Server als Default Gateway ein. Das hat aber den Nachteil das eth0 u.U. die IP Adresse verliert weil der DHCP Refresh nicht mehr durchgeführt werden kann. Das lässt sich über ein paar iptables Befehle lösen.

Lösung2: Man trägt dem Roadwarrior die benötigten Routen selbst ein. Das kann man über die push Option von OpenVPN auf dem Server auch automatisieren.

Zum Zwecke des Troubleshootings empfiehlt sich die Ausgabe des route -n Kommandos auf LAN Client, Roadwarrior und VPN Server (bin gerade nicht sicher ob das nicht im anderen Thread schon steht).

starter · 12 Juni 2006

hey nbkr, danke für die ausführliche Beschreibung. Ich bin nun nochmal auf die Suche der verlorengegangenen ICMP-Packete gegangen. Ich habe bemerkt, dass der VPN-Router die Packete von tun0 nicht an eth0 weiterleitet und ebenfalls von eth0 nicht an tun0 sobald es sich bei den Packeten um solche handelt, die für einen Client in dem jeweiligen Adressraum der Schnittstelle bestimmt sind.

So lässt sich zwar über den Tunnel auf eth0 (10.0.0.1) und tun0 (192.168.x.s) pingen, nicht jedoch auf den Client (192.168.x.k) der an eth0 hängt.

Umgekehrt: Pinge ich vom basagten Client (192.168.x.k) auf eth0 (192.168.x.s) sowie auf tun0 (10.0.0.1) erhalte ich auch eine Antwort --> :!: sofern ich ip_forward auf '0' habe!! :!:
Möchte ich aber über den Tunnel auf 10.0.0.2 pingen, fühlt sich tun0 wohl nicht dafür zuständig.

Denn ich habe heraus gefunden, dass die Packete bei den jeweiligen Zielen erst gar nicht ankommen und daher auch nicht zrück gesendet werden kann.

Ich würde behaupten dass das Problem eben zwischen eth0 und tun0 liegt. Was aber ein erfolgreicher ping direkt auf eth0 über den Tunnel diese Theorie nicht generalisieren lässt.

Was kann das sein?
Warum erhält ein Client keine Antwort mehr, wenn ip_forward aktiviert ist?
Wie kann ich die Anzahl der ICMP-Packete einer Schnittstelle herausfinden? (ifconfig eth0 bringt ja alle, und das ist weng viel)

nbkr · 12 Juni 2006

Bevor wir weiter ins Blaue rummutmaßen liefer doch erstmal die Ausgabe von route -n von den LAN Clients, dem VPN Server und den Roadwarrior Clients. Wenn auf einem davon Win statt was richtig läuft, kannst Du route PRINT statt route -n nutzen.

starter · 13 Juni 2006

o.k. hast recht

Code:

route print Client im LAN (192.168.10.1)

===========================================================================
Schnittstellenliste
0x1 ........................... MS TCP Loopback interface
0x20002 ...00 0f 20 38 5a fa ...... Broadcom NetXtreme Gigabit Ethernet for hp -
 Paketplaner-Miniport
===========================================================================
===========================================================================
Aktive Routen:
     Netzwerkziel    Netzwerkmaske          Gateway   Schnittstelle  Anzahl
          0.0.0.0          0.0.0.0       192.168.0.6     192.168.10.1    20
         10.0.0.0    255.255.255.0       192.168.0.9     192.168.10.1     1
        127.0.0.0        255.0.0.0         127.0.0.1        127.0.0.1     1
      192.168.0.0      255.255.0.0      192.168.10.1     192.168.10.1    20
     192.168.10.1  255.255.255.255         127.0.0.1        127.0.0.1    20
  192.168.255.255  255.255.255.255      192.168.10.1     192.168.10.1    20
        224.0.0.0        240.0.0.0      192.168.10.1     192.168.10.1    20
  255.255.255.255  255.255.255.255      192.168.10.1     192.168.10.1     1
Standardgateway:        192.168.0.6
===========================================================================
Ständige Routen:
  Netzwerkadresse          Netzmaske  Gatewayadresse  Anzahl

Code:

route -n openVPN-Server (192.168.0.9)

Kernel IP Routentabelle
Ziel            Router          Genmask         Flags Metric Ref    Use Iface
10.0.0.2        0.0.0.0         255.255.255.255 UH    0      0        0 tun0
193.99.165.184  0.0.0.0         255.255.255.248 U     0      0        0 eth1
192.168.0.0     0.0.0.0         255.255.0.0     U     0      0        0 eth0
169.254.0.0     0.0.0.0         255.255.0.0     U     0      0        0 eth0
127.0.0.0       0.0.0.0         255.0.0.0       U     0      0        0 lo
0.0.0.0         193.99.165.185  0.0.0.0         UG    0      0        0 eth1

Code:

route print Client on the Road (172.16.10.233)

===========================================================================
Schnittstellenliste
0x1 ........................... MS TCP Loopback interface
0x2 ...00 ff 9f 5d d2 9b ...... TAP-Win32 Adapter V8
0x10004 ...00 0b cd 6e 18 27 ...... Broadcom NetXtreme Gigabit Ethernet for hp #
2
===========================================================================
===========================================================================
Aktive Routen:
     Netzwerkziel    Netzwerkmaske          Gateway   Schnittstelle  Anzahl
          0.0.0.0          0.0.0.0         10.0.0.1        10.0.0.2       1
         10.0.0.0  255.255.255.252         10.0.0.2        10.0.0.2       30
         10.0.0.2  255.255.255.255        127.0.0.1       127.0.0.1       30
   10.255.255.255  255.255.255.255         10.0.0.2        10.0.0.2       30
   62.153.165.188  255.255.255.255     172.16.10.50   172.16.10.233       1
        127.0.0.0        255.0.0.0        127.0.0.1       127.0.0.1       1
       172.16.0.0      255.255.0.0    172.16.10.233   172.16.10.233       20
    172.16.10.233  255.255.255.255        127.0.0.1       127.0.0.1       20
   172.16.255.255  255.255.255.255    172.16.10.233   172.16.10.233       20
       172.20.0.0      255.255.0.0    172.16.30.210   172.16.10.233       1
       172.30.0.0      255.255.0.0    172.16.30.200   172.16.10.233       1
        224.0.0.0        240.0.0.0         10.0.0.2        10.0.0.2       30
        224.0.0.0        240.0.0.0    172.16.10.233   172.16.10.233       20
  255.255.255.255  255.255.255.255         10.0.0.2        10.0.0.2       1
  255.255.255.255  255.255.255.255    172.16.10.233   172.16.10.233       1
Standardgateway:          10.0.0.1
===========================================================================
Ständige Routen:
  Netzwerkadresse          Netzmaske  Gatewayadresse  Anzahl
       172.20.0.0      255.255.0.0    172.16.30.210       1
       172.30.0.0      255.255.0.0    172.16.30.200       1

nbkr · 13 Juni 2006

Beim OpenVPN Server stimmt was nicht. Der weiß nicht wie er die Clients im LAN erreichen soll. Normalerweise müsste da eine Route für 192.168.0.0/24 auftauchen. Ist aber nicht drin.

starter · 13 Juni 2006

habe ich eingetragen .... gleiches ergebnis

siehe oben

nbkr · 13 Juni 2006

Da kann aber was nicht stimmen. Die Route musst Du normalerweise nicht eintragen wenn der eth0 an das Netz angeschlossen ist. Das erkennt er schon selbst. Bei dem Server ist was ganz arg strubbelig. Denn laut jetzigen Routinginfos ist die Netzwerkkarte eth0 an 2 Netze angeschlossen. Man kann zwar zwei IP Adressen auf eine Netzwerkkarte legen aber die müssen meines Wissens nach aus dem gleichen Netz sein.

starter · 13 Juni 2006

Warum sind an der eth0 zwei netze angeschlossen? Die 169.254.0.0 ist doch 'link-local'. Das setzt der nur beim Kopieren in eine IP um.

aber du hast recht, dass da irgendetwas nicht so richtig stimmt.
Meine Frage, warum ich von einem Client im LAN eth0 und tun0 nur dann anpingen kann, wenn ich ip_forward deaktiviert habe könnte da ja auch mit einspielen, oder?

starter · 14 Juni 2006

hey nbkr zerbreche dir nicht weiter den kopf .... ich habs. iptables war schuld... oder bessergesagt ich war schuld weil ich mich mit iptables nicht auskenne. Kennst du, oder Kennst du jemanden der gute links über iptables kennt? Sowas für Dummies und am besten auf Deutsch :lol:

Danke dir für die hartnäckige Hilfe

nbkr · 14 Juni 2006

Ich muss zugeben ich hätte inzwischen auch aufgeben müssen.
Iptables Howto findet sich hier:

http://iptables-tutorial.frozentux.net/

[geloest] ip_forward blockt vpn

starter

Newbie

nbkr

Guru

starter

Newbie

nbkr

Guru

starter

Newbie

nbkr

Guru

starter

Newbie

nbkr

Guru

starter

Newbie

nbkr

Guru

starter

Newbie

starter

Newbie

nbkr

Guru