VPN bleibt in der Firewall haengen

[roli]

Hallo,

ich habe ein Problem mit VPN.
Zur Geschichte, bislang hingen alle Rechner im Office in einem 192.168'er Netz. Das habe ich die letzten zwei Tage umgestellt. Es gibt jetzt ein Server-Netz (eth1 10.1.1.x) und ein Client-Netz (eth2 10.1.2.x) diese Netze haengen hinter meinem Gateway, dieses ist per eth0 10.1.0.x an das INet angebunden. Soweit sogut.
Im Server-Netz steht ein OpenVPN Server, wenn man dann dochmal von ausserhalb einen Zugriff braucht. Ich denke zwar das ich an dem VPN Server alles richtig umgestellt habe (IP-Adr., Routing, VPN-Konfig, DNS) aber ich kann keine Verbindung aufbauen. Daher wollte ich jetzt mal vom Gateway aus die Packete verfolgen. Hierzu habe ich die Firewall mit folgenden Regeln erweitert:

Code: Alles auswählen

    iptables -A INPUT -i eth0 -p udp --dport 1194 -j LOG --log-prefix "INPUT LOG "
    iptables -A FORWARD -i eth0 -p udp --dport 1194 -j LOG --log-prefix "FORWARD LOG "
    iptables -A PREROUTING -i eth0 -p udp --dport 1194 -j LOG --log-prefix "PREROUTING LOG "

Allerdings bekomme ich hiermit keine Logeintraege. Wenigstens die auf eth0 eingehenden Packete haette ich erwartet zu sehen, dann koennte ich schauen, ob sie richtig an den VPN-Server weitergeleitet werden, um hiernach den Rueckweg zu checken.
Hat jemand einen Tip fuer mich?

[DynaBlaster]

Allerdings bekomme ich hiermit keine Logeintraege. Wenigstens die auf eth0 eingehenden Packete haette ich erwartet zu sehen ...

Da ich davon ausgehe, das "/proc/sys/net/ipv4/ip_forward" aktiviert ist - sonst könnte das Gateway ja grundsätzlich nicht routen, fallen mir spontan zwei Möglichkeit ein, warum die Pakete für UDP 1194 nicht in den Logs auftauchen könnten. Entwerder werden sie schon "gedropt", bevor sie zur iptables-Regel mit der LOG-Anweisung kommen - kommt halt darauf an, an welcher Stelle deines iptables-Scripts die Anweisung steht - um sicher zu gehen am besten mal an den Anfang stellen. Die andere Möglichkeit wäre, dass die Pakete gar nicht erst zum Gateway durchgereicht werden: du schreibst, dass das eth0-Interface des Gateways zeigt ins Internet. Wie gehts von da denn weiter? Per DSL und PPPOE? Oder ist da noch ein anderer (DSL-)Router im Netz 10.1.0.x, der die Internetverbindung herstellt? Evtl. liegt es ja an falschen/mangelhaften Routen bei diesem 2. Router.

[roli]

Hi,

Da ich davon ausgehe, das "/proc/sys/net/ipv4/ip_forward" aktiviert ist

Jep, aber auch wenn nicht, so muesste ich die eingehenden Packete doch sehen, auch wenn ich sie dann nicht weiterreichen koennte.

sonst könnte das Gateway ja grundsätzlich nicht routen, fallen mir spontan zwei Möglichkeit ein, warum die Pakete für UDP 1194 nicht in den Logs auftauchen könnten.

Ich habe die Regeln jetzt auch mal fuer tcp eingebaut

Entwerder werden sie schon "gedropt", bevor sie zur iptables-Regel mit der LOG-Anweisung kommen - kommt halt darauf an, an welcher Stelle deines iptables-Scripts die Anweisung steht - um sicher zu gehen am besten mal an den Anfang stellen.

Die sind schon ganz oben.

Die andere Möglichkeit wäre, dass die Pakete gar nicht erst zum Gateway durchgereicht werden: du schreibst, dass das eth0-Interface des Gateways zeigt ins Internet. Wie gehts von da denn weiter? Per DSL und PPPOE? Oder ist da noch ein anderer (DSL-)Router im Netz 10.1.0.x, der die Internetverbindung herstellt? Evtl. liegt es ja an falschen/mangelhaften Routen bei diesem 2. Router.

Da steht ein "Managed Router" von unserem Provider. Ich habe denen zwar heute Mittag schon gesagt, das sie Port 1194 auf mein Gateway weiterleiten sollen, aber vielleicht haben die's doch noch nicht gemacht. Wenn das der Fall ist, sollte ich spaetestens Morgen von denen was hoeren.

Danke

[daFreak]

Ich habe denen zwar heute Mittag schon gesagt, das sie Port 1194 auf mein Gateway weiterleiten sollen, aber vielleicht haben die's doch noch nicht gemacht. Wenn das der Fall ist, sollte ich spaetestens Morgen von denen was hoeren.

Hät ich jetzt auch spontan drauf getippt.
Kannst du denn überhaupt von außerhalb auf den Server zugreifen? Vielleicht dyndns? Oder hast du eine statische IP?

[roli]

Hi,

der "managed Router" hat eine Statische IP. Von dort wird u.a. SSH, natuerlich nicht Port 22, auf mein Gateway weitergeleitet, das klappt auch ganz hervorragend.

[roli]

Hi,

wenigstens brauch ich jetzt nicht mehr an mir zu zweifeln, unser Provider hatte das Portforwarding noch nicht geschaltet, erst heute morgen, und schon geht's, jedenfalls fast.
Die VPN Verbindung wird jetzt richtig aufgebaut, allerdings bekommen die Clients noch die alte IP-Adresse unseres DNS-Servers, so das sie auf das interne Netz doch nicht zugreifen koennen. Bislang habe ich allerdings noch nicht die Stelle gefunden, an der der OpenVPN Server dem Client den DNS zuweist. Haette hierzu jemand einen Tipp?

[Danielx]

Bislang habe ich allerdings noch nicht die Stelle gefunden, an der der OpenVPN Server dem Client den DNS zuweist. Haette hierzu jemand einen Tipp?

Schau mal in "man openvpn" unter
"Windows-Specific Options:"
und dann
"--dhcp-option type [parm]"
Dort findest du unter anderem "DNS addr"...

In der Server-Config trägst du dann so etwas ein:

Code: Alles auswählen

push "dhcp-option DNS 10.1.2.3"

Und in der Client-Config dann:

Code: Alles auswählen

pull

Aber das funktioniert erstmal nur mit Windows-Clients:

Note that if --dhcp-option is pushed via --push to a non-windows client, the option will be saved in the client’s en‐
vironment before the up script is called, under the name "foreign_option_{n}".

Bei Linux-Clients brauchst du ein extra Skript, welches "foreign_option_{n}" auswertet, entweder selbst schreiben oder im Internet suchen, da wirst du fündig.
Das läuft dann über "resolvconf".

Die Infos beziehen sich auf Etch, vielleicht ist in Lenny so ein Skript schon vorhanden?

edit: Unter Windows gibt es manchmal auch Probleme, siehe hier, samt Lösung:
http://openvpn.net/faq.html#dhcpcaveats
"Are there any issues related to pushing DHCP options to Windows clients?"

edit2: Habe gerade mal nachgesehen, in Lenny gibt es tatsächlich schon solch ein Skript und zwar unter "/etc/openvpn/update-resolv-conf"!

Gruß,
Daniel