iptables Konfiguration für openvpn (/usr/local/sbin/post-firewall)

[hornau]

Hallo,

scheinbar werden meine Firewallregeln bei einem Systemstart nicht richtig verarbeitet.
Habe einen WL500gPv2 mit 1.9.2.7-d-r1000 nach dem Howto von wengi eingerichtet und openvpn installiert. Wenn ich nun die iptables in /usr/local/sbin/post-firewall eintrage, klappt die vpn Verbindung nicht. Lasse ich die "post-firewall"-Datei aber leer und führe meine Regeln nach einem Neustart "per Hand" aus (gleiche Datei in anderem Verzeichnis), dann gehts.
Kann es vielleicht sein, dass die angehängte USB-Festplatte etwas mit Verzögerung hochfährt und das System noch nicht vollen Zugriff auf alle Dteien hat? Zumindest dem Geräusch nach zu urteilen kommt die Festplatte etwas später.

Vielen Dank im voraus für Eure Hilfe.
hornau

[akbor]

Wenn es darum geht, die iptables zu verändern, ist die post-firewall die richtige Stelle. An der Stelle brauchst du aber noch keinen Zugriff auf die Platte, wozu auch?

Wenn du irgendetwas von der Platte starten willst, dafür gibt es die /usr/local/sbin/post-mount.

Oder noch besser, ein Startscript unter /opt/etc/init.d/, so starten auch sonst alle Dienste in der Wengis Anleitung.

Gruß

Robert

[hornau]

Hallo Robert,

vielen Dank für Deine Antwort. Eigentlich geht es mir darum, openvpn zum Laufen zu bringen. Der startet auch mit /opt/etc/init.d/*S20openvpn .

Wenn ich nun meine Firewallregeln in /usr/local/sbin/*post-firewall eintrage:

#!/bin/sh
# Deleting this rule temporarily and add it again in the end
iptables -D INPUT -j DROP

# SSH access from WAN:
#iptables -A INPUT -m tcp -p tcp --dport 51901 -j ACCEPT

# Webserver access from WAN:
#iptables -A INPUT -p tcp --dport 80 -j ACCEPT
#iptables -A INPUT -p tcp --dport 443 -j ACCEPT

# OpenVPN access from WAN
iptables -A INPUT -p udp --dport 1234 -j ACCEPT
iptables -t nat -A PREROUTING -i vlan1 -p udp --dport 1234 -j DNAT --to-destination $4:1234
# Allow direct connections between VPN-Clients and Router
iptables -A INPUT -i tun+ -j ACCEPT
iptables -A OUTPUT -o tun+ -j ACCEPT
# Allow connections from VPN-Clients to LAN-Clients
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o br0 -j MASQUERADE
# Allow connections from LAN-Clients to VPN-Clients
iptables -I FORWARD -i tun+ -o br0 -s 10.8.0.0/24 -j ACCEPT
iptables -I FORWARD -i br0 -o tun+ -s 192.168.1.0/24 -j ACCEPT
# Allow forwarding to/from VPN-Clients (needed at least for ping)
iptables -A FORWARD -i tun+ -j ACCEPT
iptables -A FORWARD -o tun+ -j ACCEPT
# Allow VPN-clients to tunnel internet traffic through VPN-Server
iptables -I FORWARD -i tun+ -o vlan1 -s 10.8.0.0/24 -j ACCEPT

# Drop all other input
iptables -A INPUT -j DROP

zeigt mir das WIF nach dem reboot folgendes Portforwarding an:

Destination     Proto.  Port Range  Redirect to
all             UDP     1234        192.168.1.1

Und ich kann das vpn nicht aufbauen.

Wenn ich alternativ /usr/local/sbin/*post-firewall leer lasse und nach dem reboot die Regeln manuell ausführe, funktioniert der Aufbau des vpn. Im WIF ist dann das Portforwarding

Destination     Proto.  Port Range  Redirect to
all             UDP     1234        0.0.0.0

eingetragen.

Ich habe mir daraufhin mal die Bootscripte in /usr/local/sbin/ angeschaut und in alle eine Zeile z. B.

echo "post-firewall" >> /tmp/start

eingetragen mit dem Ergebnis in /tmp/start:

post-firewall
post-boot
post-firewall
pre-mount
post-mount

/usr/local/sbin/post-firewall wird scheinbar zweimal ausgeführt?
Gibt es eine Datei, aus der ich entnehmen kann, wann die Startscripte verarbeitet werden?

Auch habe ich festgestellt, dass die Routingtabelle erst nach Ausführung von /usr/local/sbin/post-mount vollständig aufgebaut ist. Wird dann die Variable $4 in

iptables -t nat -A PREROUTING -i vlan1 -p udp --dport 1234 -j DNAT --to-destination $4:1234

nochmal anders belegt?

Ich habe nun meine Firewallregeln an /usr/local/sbin/post-mount angehängt und jetzt geht es. Ist aber irgendwie nicht im Sinne des Erfinders, glaube ich...

Grüße
hornau

[akbor]

Eine etwas banale Frage, bitte nicht sauer sein, aber ist die /usr/local/sbin/post-firewall auch ausführbar?

Gibt es eine Datei, aus der ich entnehmen kann, wann die Startscripte verarbeitet werden?

Da geht z.B. indem du aus dem jeweiligen Script folgendes machst:

date > /tmp/post-firewal-executed

oder so ähnlich

Gruß

Robert

[hornau]

Ja, ausführbar ist die post-firewall schon. ls in /usr/local/sbin ergibt

total 24
drwxr-xr-x 2 admin root  160 Jan  1  2000 .
drwxr-xr-x 6 admin root  140 Jan  1  2000 ..
-rwxr-xr-x 1 admin root   90 Mar 14 13:35 post-boot
-rwxr-xr-x 1 admin root   45 Mar 14 14:18 post-firewall
-rwxr-xr-x 1 admin root 1368 Mar 14 14:17 post-mount
-rwxr-xr-x 1 admin root   40 Mar 14 14:23 pre-boot
-rwxr-xr-x 1 admin root  252 Mar 14 13:40 pre-mount
-rwxr-xr-x 1 admin root  170 Jan  2 23:34 pre-shutdown

Wenn ich in jedes Startscript am Anfang und am Ende ein "date" einfüge, kommt das heraus (Die Firewall-Regeln habe ich wieder in "post-firewall" eingestellt.):

post-firewall started:
Thu Jan  1 01:00:05 MEZ 1970
post-firewall executed:
Thu Jan  1 01:00:05 MEZ 1970
post-boot started:
Thu Jan  1 01:00:06 MEZ 1970
post-firewall started:
Sun Mar 14 18:19:29 MESZ 2010
post-boot executed:
Sun Mar 14 18:19:29 MESZ 2010
post-firewall executed:
Sun Mar 14 18:19:29 MESZ 2010
pre-mount started:
Sun Mar 14 18:19:38 MESZ 2010
pre-mount executed:
Sun Mar 14 18:19:39 MESZ 2010
post-mount started:
Sun Mar 14 18:19:39 MESZ 2010
post-mount executed:
Sun Mar 14 18:19:44 MESZ 2010

Zumindest nicht in Reihenfolge.

Ich meinte mit meiner Frage eigentlich: ob es eine Datei gibt, die die unter /usr/local/sbin abgelegten Startscripte aufruft und wo die zu finden ist?

Grüße
hornau

[newbiefan]

Ich meinte mit meiner Frage eigentlich: ob es eine Datei gibt, die die unter /usr/local/sbin abgelegten Startscripte aufruft und wo die zu finden ist?

Ja, diese Datei gibt es - kann aber nicht so einfach geändert werden.
Sehe dir dazu die Datei /linuxrc letzte Zeile an. Dort wird zum Schluss die /sbin/init aufgerufen. Das ist wohl die Datei, welche du suchst. Leider kann diese Datei nicht geändert werden, dennoch sollte es Abhilfe geben.

Zuerst würde ich folgendes versuchen: Jeder Aufruf von irgend einem Befehl unbedingt mit voller Pfadangabe! Am Beginn vom Booten sind die Pfade noch nicht gesetzt und deshalb kann es passieren, dass diese Befehle einfach ignoriert werden. Genau so würde ich auch den Versuch mit Date ergänzen.

Falls das alles nichts hilft, würde ich die gesamte Firmware auf den Flash-Stick oder HDD incl. /opt geben. Dadurch wird das gesamte Verzeichnis writeable. Das ist für verschiedene Einstellungen und Versuche sehr nützlich.
Die Anleitung dazu von hier:
http://oleg.wl500g.info/
Speziel die Section Root filesystem on external HDD, sowie
customizing firewall sind für dich interessant.

Ist auch die linuxrc auf der HDD kannst du ja deine eigenen Dinge starten.

Hoffe es hilft, denn es ist wahrlich nicht sauber und gut, wenn die Firewall erst nach vollständigem Routerstart funktioniert. Vermutlich hilft jedoch die volle Pfadangabe bei jedem Befehl.

LG
Newbiefan

[akbor]

@newbiefan
Pfadangabe? Welche Pfade meinst du denn? Du hast ja seine post-firewall gesehen, es manipuliert dort nur iptables und sonst ruft er gar nichts auf. Mir ist aufgefallen, dass die Variable $4 (LAN IP, soweit ich mich richtig erinnere) an einer Stelle eingesetzt wird, sonst werden aber alle Interfaces und Adressen "in Klartext" angesprochen. Ist das vielleicht ein Problem? Oder ist es so gewollt? Oder bin ich auf dem falschen Dampfer und habe das Problem nicht verstanden?

@hornau
was ist nochmal dein Problem? Bekommst du iptables nicht geändert wie du möchtest (so interpretiere ich zumindest die aktuelle Thread-Überschrift), oder startet dein VPN-Service nicht?

P.S: bedenke, dass "$4" ausserhalb von post-firewall nicht funktioniert. $4 ist innerhalb der post-firewall die LAN IP, also in deinem Fall vermutlich 192.168.1.1. Ich glaube, genau das ist deine Fehlerquelle!

P.P.S: deinen Angaben nach werden alle Scripts unter /usr/local/sbin/ richtig ausgeführt.

Gruß

Robert

[newbiefan]

Hallo Robert,

ich meinte den Pfad von iptables, also /usr/sbin/iptables einsetzen, anstatt nur iptables. Ob es hilft kann ich nicht sagen, da ich ja nur avbf auf dem Asus verwende und das starte ich vor dem vsftpd und webserver. Aber bei mir ist der Asus auch nur als AP eingesetzt.
Dennoch ist mir diese Eigenheit vor längerer Zeit aufgefallen..........

LG Helmut

[akbor]

OK, verstanden, der Pfad zu iptables sollte aber zur Laufzeit von post-firewall bekannt sein. Ob post-firewall iptables finden kann, kann man überprüfen, indem man die Ausgabe in eine Logdatei umleitet, z.B. so:

iptables [Optionen] >> /tmp/post-firewall.log 2>&1

Gruß

Robert

[Copter]

Kurze Zwischenfrage:

@hornau:

Kann ich deine post-firewall, abgeändert mit newbiefans Vorschlag:

#!/bin/sh
# Deleting this rule temporarily and add it again in the end
/usr/sbin/iptables -D INPUT -j DROP

# SSH access from WAN:
#/usr/sbin/iptables -A INPUT -m tcp -p tcp --dport 22 -j ACCEPT

# Webserver access from WAN:
#/usr/sbin/iptables -A INPUT -p tcp --dport 80 -j ACCEPT
#/usr/sbin/iptables -A INPUT -p tcp --dport 443 -j ACCEPT

# Drop all other input
/usr/sbin/iptables -A INPUT -j DROP

als Beispiel post-firewall für den Fall "Router als Gateway" betrachten?

[hornau]

Danke newbiefan für Deinen Hinweis, ich schaue mir Olegs Webseite demnächst nochmal genauer an.

Dann habe ich meine Firewallregeln um "/usr/sbin/" und "iptables [Optionen] > /tmp/post-firewall.log 2>&1" ergänzt. /usr/local/sbin/post-firewall sieht jetzt so aus:

#!/bin/sh
echo "post-firewall started:" >> /tmp/start
date >> /tmp/start

# Deleting this rule temporarily and add it again in the end
/usr/sbin/iptables -D INPUT -j DROP >> /tmp/post-firewall.log 2>&1

# OpenVPN access from WAN
/usr/sbin/iptables -A INPUT -p udp --dport 1234 -j ACCEPT >> /tmp/post-firewall.log 2>&1
/usr/sbin/iptables -t nat -A PREROUTING -i vlan1 -p udp --dport 1234 -j DNAT --to-destination $4:1234 >> /tmp/post-firewall.log 2>&1
# Allow direct connections between VPN-Clients and Router
/usr/sbin/iptables -A INPUT -i tun+ -j ACCEPT >> /tmp/post-firewall.log 2>&1
/usr/sbin/iptables -A OUTPUT -o tun+ -j ACCEPT >> /tmp/post-firewall.log 2>&1
# Allow connections from VPN-Clients to LAN-Clients
/usr/sbin/iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o br0 -j MASQUERADE >> /tmp/post-firewall.log 2>&1
# Allow connections from LAN-Clients to VPN-Clients
/usr/sbin/iptables -I FORWARD -i tun+ -o br0 -s 10.8.0.0/24 -j ACCEPT >> /tmp/post-firewall.log 2>&1
/usr/sbin/iptables -I FORWARD -i br0 -o tun+ -s 192.168.1.0/24 -j ACCEPT >> /tmp/post-firewall.log 2>&1
# Allow forwarding to/from VPN-Clients (needed at least for ping)
/usr/sbin/iptables -A FORWARD -i tun+ -j ACCEPT >> /tmp/post-firewall.log 2>&1
/usr/sbin/iptables -A FORWARD -o tun+ -j ACCEPT >> /tmp/post-firewall.log 2>&1
# Allow VPN-clients to tunnel internet traffic through VPN-Server
/usr/sbin/iptables -I FORWARD -i tun+ -o vlan1 -s 10.8.0.0/24 -j ACCEPT >> /tmp/post-firewall.log 2>&1

# Drop all other input
/usr/sbin/iptables -A INPUT -j DROP >> /tmp/post-firewall.log 2>&1

echo "post-firewall executed:" >> /tmp/start
date >> /tmp/start

Die /tmp/post-firewall.log ist nach einem Neustart dann zwar angelegt aber leer. Sollte das so sein?

Dann nochmal zu Euren Fragen, Copter und Robert: Der Asus-Router hängt an einem Kabelmodem. Am Asus sind drei Rechner angeschlossen, die USB-Festplatte und noch ein USB-Drucker, mehr ist da nicht dran. Dann habe ich noch Samba laufen und vsftp und natürlich openvpn. Nun möchte ich von unterwegs auf dieses Heimnetz durch einen vpn zugreifen. Dazu werfe ich an meinem Laptop die UMTS-Karte an.
Wenn ich nun am Laptop den vpn-client starte und mit meinem Router, auf dem die obige /usr/local/sbin/post-firewall installiert ist, verbinde, dann klappt es nicht. /opt/var/log/openvpn/openvpn.log zeigt das an:

Tue Mar 16 00:09:11 2010 MULTI: multi_create_instance called
Tue Mar 16 00:09:11 2010 109.84.131.113:1194 Re-using SSL/TLS context
Tue Mar 16 00:09:11 2010 109.84.131.113:1194 LZO compression initialized
Tue Mar 16 00:09:11 2010 109.84.131.113:1194 Control Channel MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 EL:0 ]
Tue Mar 16 00:09:11 2010 109.84.131.113:1194 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
Tue Mar 16 00:09:11 2010 109.84.131.113:1194 Local Options hash (VER=V4): '530fdded'
Tue Mar 16 00:09:11 2010 109.84.131.113:1194 Expected Remote Options hash (VER=V4): '41690919'
Tue Mar 16 00:09:11 2010 109.84.131.113:1194 TLS: Initial packet from 109.84.131.113:1194, sid=fb3d3a2c 2e2e43b8
Tue Mar 16 00:10:11 2010 109.84.131.113:1194 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Tue Mar 16 00:10:11 2010 109.84.131.113:1194 TLS Error: TLS handshake failed
Tue Mar 16 00:10:11 2010 109.84.131.113:1194 SIGUSR1[soft,tls-error] received, client-instance restarting

Wenn ich nun aber meine /usr/local/sbin/post-firewall leer lasse, den Router also ohne iptables starte und nach dem Hochfahren das post-firewall-Script (das ich vorher an eine andere Stelle kopiert habe) per Hand starte, dann klappt der Verbindungsaufbau:

Tue Mar 16 00:22:57 2010 OpenVPN 2.1.1 mipsel-linux [SSL] [LZO1] [EPOLL] built on Dec 23 2009
Tue Mar 16 00:22:57 2010 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
Tue Mar 16 00:22:58 2010 Diffie-Hellman initialized with 1024 bit key
Tue Mar 16 00:22:58 2010 TLS-Auth MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 EL:0 ]
Tue Mar 16 00:22:58 2010 TCP/UDP: Socket bind failed on local address [undef]:1234: Address already in use
Tue Mar 16 00:22:58 2010 Exiting
Tue Mar 16 00:23:11 2010 event_wait : Interrupted system call (code=4)
Tue Mar 16 00:23:11 2010 TCP/UDP: Closing socket
Tue Mar 16 00:23:11 2010 /sbin/route del -net 10.8.0.0 netmask 255.255.255.0
route: SIOCDELRT: Operation not permitted
Tue Mar 16 00:23:11 2010 ERROR: Linux route delete command failed: external program exited with error status: 1
Tue Mar 16 00:23:11 2010 Closing TUN/TAP interface
Tue Mar 16 00:23:11 2010 /sbin/ifconfig tun0 0.0.0.0
ifconfig: SIOCSIFADDR: Permission denied
Tue Mar 16 00:23:11 2010 Linux ip addr del failed: external program exited with error status: 1
Tue Mar 16 00:23:11 2010 SIGTERM[hard,] received, process exiting
Tue Mar 16 00:23:45 2010 OpenVPN 2.1.1 mipsel-linux [SSL] [LZO1] [EPOLL] built on Dec 23 2009
Tue Mar 16 00:23:45 2010 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
Tue Mar 16 00:23:45 2010 Diffie-Hellman initialized with 1024 bit key
Tue Mar 16 00:23:45 2010 TLS-Auth MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 EL:0 ]
Tue Mar 16 00:23:45 2010 ROUTE default_gateway=81.---.---.1
Tue Mar 16 00:23:45 2010 TUN/TAP device tun0 opened
Tue Mar 16 00:23:45 2010 TUN/TAP TX queue length set to 100
Tue Mar 16 00:23:45 2010 /sbin/ifconfig tun0 10.8.0.1 pointopoint 10.8.0.2 mtu 1500
Tue Mar 16 00:23:46 2010 /sbin/route add -net 10.8.0.0 netmask 255.255.255.0 gw 10.8.0.2
Tue Mar 16 00:23:46 2010 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
Tue Mar 16 00:23:46 2010 GID set to nobody
Tue Mar 16 00:23:46 2010 UID set to nobody
Tue Mar 16 00:23:46 2010 Socket Buffers: R=[108544->131072] S=[108544->131072]
Tue Mar 16 00:23:46 2010 UDPv4 link local (bound): [undef]:1234
Tue Mar 16 00:23:46 2010 UDPv4 link remote: [undef]
Tue Mar 16 00:23:46 2010 MULTI: multi_init called, r=256 v=256
Tue Mar 16 00:23:46 2010 IFCONFIG POOL: base=10.8.0.4 size=62
Tue Mar 16 00:23:46 2010 IFCONFIG POOL LIST
Tue Mar 16 00:23:46 2010 max,10.8.0.4
Tue Mar 16 00:23:46 2010 client1,10.8.0.8
Tue Mar 16 00:23:46 2010 client2,10.8.0.12
Tue Mar 16 00:23:46 2010 Initialization Sequence Completed
Tue Mar 16 00:24:16 2010 MULTI: multi_create_instance called
Tue Mar 16 00:24:16 2010 109.84.131.113:1194 Re-using SSL/TLS context
Tue Mar 16 00:24:16 2010 109.84.131.113:1194 LZO compression initialized
Tue Mar 16 00:24:16 2010 109.84.131.113:1194 Control Channel MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 EL:0 ]
Tue Mar 16 00:24:16 2010 109.84.131.113:1194 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
Tue Mar 16 00:24:16 2010 109.84.131.113:1194 Local Options hash (VER=V4): '530fdded'
Tue Mar 16 00:24:16 2010 109.84.131.113:1194 Expected Remote Options hash (VER=V4): '41690919'
Tue Mar 16 00:24:16 2010 109.84.131.113:1194 TLS: Initial packet from 109.84.131.113:1194, sid=209ce0ca 6f710e82
Tue Mar 16 00:24:18 2010 109.84.131.113:1194 VERIFY OK: depth=1, /C=DE/ST=HE/L=Frankfurt/O=Eppsteiner34/OU=OG4/CN=Weichensteller/emailAddress=mail@birgitundmax.dyndns.org
Tue Mar 16 00:24:18 2010 109.84.131.113:1194 VERIFY OK: depth=0, /C=DE/ST=HE/O=Eppsteiner34/OU=OG4/CN=client2/emailAddress=mail@birgitundmax.dyndns.org
Tue Mar 16 00:24:18 2010 109.84.131.113:1194 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Tue Mar 16 00:24:18 2010 109.84.131.113:1194 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Tue Mar 16 00:24:18 2010 109.84.131.113:1194 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Tue Mar 16 00:24:18 2010 109.84.131.113:1194 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Tue Mar 16 00:24:18 2010 109.84.131.113:1194 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Tue Mar 16 00:24:18 2010 109.84.131.113:1194 [client2] Peer Connection Initiated with 109.84.131.113:1194
Tue Mar 16 00:24:18 2010 client2/109.84.131.113:1194 MULTI: Learn: 10.8.0.14 -> client2/109.84.131.113:1194
Tue Mar 16 00:24:18 2010 client2/109.84.131.113:1194 MULTI: primary virtual IP for client2/109.84.131.113:1194: 10.8.0.14
Tue Mar 16 00:24:19 2010 client2/109.84.131.113:1194 PUSH: Received control message: 'PUSH_REQUEST'
Tue Mar 16 00:24:19 2010 client2/109.84.131.113:1194 SENT CONTROL [client2]: 'PUSH_REPLY,redirect-gateway def1,dhcp-option DNS 10.8.0.1,route 192.168.1.0 255.255.255.0,route 10.8.0.1,topology net30,ping 10,ping-restart 60,ifconfig 10.8.0.14 10.8.0.13' (status=1)

Mal laienhaft gefragt: da dürfte doch bei mir eingentlich kein Unterschied sein, ob ich meine iptables während oder nach den Startvorgang des Routers ausführe, oder? Außer vielleicht, dass die $4-Variable nicht belegt ist...
Kann mir jemand sagen, ob meine iptables denn überhaupt für meinen Anwendungsfall stimmen?
Oder habe ich mir da die "Scheunentore" aufgemacht?
Ich kenne mich mit iptables eigentlich überhaupt nicht aus; war lange auf der Suche nach einer Beispielkonfig für den WL500gPv2 und bin in diesem Beitrag fündig geworden: http://wl500g.info/showpost.php?p=134362&postcount=4

Vielen Dank schonmal vorab für Eure Hilfe
hornau

[akbor]

Die /tmp/post-firewall.log ist nach einem Neustart dann zwar angelegt aber leer. Sollte das so sein?

Das heisst, es wurden keine Fehlermeldungen ausgegeben und dass Helmuts Tipp mit /usr/sbin/iptables entweder geholfen hat, oder aber gar nicht nötig war. Das kannst du wiederum herausfinden, indem du den Pfad weg lässt.

Ich selber habe iptables noch nie ernst anwenden müssen, habe damit nur ein wenig rumgespielt. Ich habe aber gleich folgende Zeile gesehen:

iptables -t nat -A PREROUTING -i vlan1 -p udp --dport 1234 -j DNAT --to-destination $4:1234

Diese Zeile kann wegen $4 nur innerhalb von der post-firewall richtig ausgeführt werden. Der Unterschied zwischen der funktionsfähigen und der nicht-funktionsfähigen Routingtabelle macht genau die LAN-Adresse (=$4) aus. Komisch finde ich allerdings, dass ausgerechnet die von dir gewollte iptables-Konfig nicht funktioniert und die zufällig fehlerhafte (weil $4 nicht richtig aufgelöst werden konnte) zum Erfolg geführt hat. Ich würde an deiner Stelle nochmal sehr genau überlegen, was du mit iptables anstellen willst und alle Regeln nochmal überprüfen. Mit openvpn kenne ich mich überhaupt nicht aus. Vielleicht gibt es hier jemanden, der openvpn am Laufen hat und dir eine funktionsfähige iptables-Konfig zur Verfügung stellen kann. Aber deine jetzige post-firewall hast du ja auch irgenwoher.

Gruß

Robert

P.S.: ist "vlan1" in der Routing-Regel ein glücklicher Zufall? Ich frage, weil vlan1 für deinen Routeryp (WL-500gP v1) und für deine WAN-Anbindung (Kabelmodem, also höchstwahrscheinlich TCP/IP) zwar stimmt, grundsätzlich sollte man aber "$1" verwenden. Dann würde die Routing-Regel auch auf einem anderen Router (z.B. WL-500W) und/oder für die WAN-Anbindung über DSL (PPPoE) immer noch funktionieren.

[hornau]

Komisch finde ich allerdings, dass ausgerechnet die von dir gewollte iptables-Konfig nicht funktioniert und die zufällig fehlerhafte (weil $4 nicht richtig aufgelöst werden konnte) zum Erfolg geführt hat.

Hallo Robert, das hast Du gut auf den Punkt gebracht.

Ich hänge hier mal die Routingtabelle an, die mir der WIF ausgibt:

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.8.0.2        *               255.255.255.255 UH    0      0        0 WAN tun0
81.210.123.1    *               255.255.255.255 UH    0      0        0 WAN vlan1
10.8.0.0        10.8.0.2        255.255.255.0   UG    0      0        0 WAN tun0
192.168.1.0     *               255.255.255.0   U     0      0        0 LAN br0
81.210.123.0    *               255.255.248.0   U     0      0        0 WAN vlan1
default         81.210.123.1    0.0.0.0         UG    0      0        0 WAN vlan1

Und die Konfiguration der Interfaces:

br0       Link encap:Ethernet  HWaddr 00:11:22:33:44:55
          inet addr:192.168.1.1  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: fe88::222:11ff:fe66:555a/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:7924 errors:0 dropped:0 overruns:0 frame:0
          TX packets:27376 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:1464689 (1.3 MiB)  TX bytes:15315048 (14.6 MiB)

eth0      Link encap:Ethernet  HWaddr 00:11:22:33:44:55  
          inet6 addr: fe88::222:11ff:fe66:555a/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1113071 errors:0 dropped:0 overruns:0 frame:0
          TX packets:33666 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:83500941 (79.6 MiB)  TX bytes:16880709 (16.0 MiB)
          Interrupt:4 Base address:0x1000 

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING MULTICAST  MTU:16436  Metric:1
          RX packets:1 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:76 (76.0 B)  TX bytes:76 (76.0 B)

tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
          inet addr:10.8.0.1  P-t-P:10.8.0.2  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:115 errors:0 dropped:0 overruns:0 frame:0
          TX packets:4 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100 
          RX bytes:8097 (7.9 KiB)  TX bytes:224 (224.0 B)

vlan0     Link encap:Ethernet  HWaddr 00:11:22:33:44:55  
          inet6 addr: fe88::222:11ff:fe66:555a/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:7924 errors:0 dropped:0 overruns:0 frame:0
          TX packets:27380 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:1496385 (1.4 MiB)  TX bytes:15424916 (14.7 MiB)

vlan1     Link encap:Ethernet  HWaddr 00:11:22:33:44:55  
          inet addr:81.210.179.153  Bcast:81.210.183.255  Mask:255.255.248.0
          inet6 addr: fe88::222:11ff:fe66:555a/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1105143 errors:0 dropped:0 overruns:0 frame:0
          TX packets:6282 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:61969078 (59.0 MiB)  TX bytes:1455445 (1.3 MiB)

Vielleicht hat jemand einen Vorschlag für geeignete iptables für meinen WL500gPV2?
Ich möchte mich gerne aus dem WAM über vpn in mein Heimnetz einklinken und dort wie ein normaler "LAN-Rechner" arbeiten können.

...
Vielleicht sollte ich einen neuen Beitrag eröffnen: das ganze passt irgendwie nicht mehr so sehr zu der Überschrift.

Grüße
hornau

[akbor]

Vielleicht sollte ich einen neuen Beitrag eröffnen: das ganze passt irgendwie nicht mehr so sehr zu der Überschrift.

Das ist gar nicht nötig, die Überschrift habe ich angepasst

Gruß

Robert

P.S.: solltest du mit der neuen Überschrift nicht ganz zufrieden sein -> du kannst sie selber jederzeit anpassen.