Routing mit IPTables, OpenVPN...

h^2

hat ne Keule +1
Ja, ein wenig OT hier, aber vielleicht kennt sich ja jemand aus. Das Ding läuft leider nur mit Linux, sonst hätte ich die Probleme nicht -.- Leider kenn ich mich mit iptables ziemlich schlecht aus :'(

Ich habe folgendes Setup (vereinfacht):

Code:
               Internetz
                    |
  Internetz       NetzB
        |           |
 +------o-----------o------+
 |     eth0       tun0     |
 |          eth1           |
 +-----------o-------------+
             |
            LAN


Also ein physisches device nach innen mit subnetz 192.168.3.0 und eins nach Außen zum Internet. Zusätzlich ein OpenVPN-Tunnel tun0 über eth0 nach "NetzB". Der OpenVPN-Tunnel bekommt eine statische IP-Adresse und das NetzB sind auch Rechner mit öffentlichen, statischen IPs, die auch direkt ins Internet können.
Über den VPN-Tunnel werden standard-mäßig nur die Routen für NetzB gepusht, so dass der Router Anfragen aus dem LAN je nach Ziel entweder über eth0 oder tun0 NATet. Das funktioniert auch soweit alles.

Man kann auch mit ping -I oder traceroute -i vom Router aus explizit über tun0 rausgehen (an Adressen außerhalb von NetzB), dann kommen die Antworten auch über tun0 zurück, alles wie erwartet.

ABER wenn man von außen auf die IP von von tun0 zugreifen möchte klappt es nicht. Das heißt wenn ich von NetzB auf die (statische) IP von tun0 zugreife, dann geht alles, aber wenn ich aus dem Internet versuche, dann kommen keine Antworten zurück.
Paradoxerweise sehe ich sogar auf dem Router per TCPdump, dass ICMP echo reply von tun0-Adresse zur anfragenden IP gesendet wird. Leider kommt davon aber nichts an. Ich weiß aber auch nicht nach/vor dem Anwenden welcher Regeln tcpdump mir das anzeigt.

Ich habe mal manuell aus den IPTables fast alle drop Anweisungen entfernt und explizit eine ACCEPT Regel für ICMP hinzugefügt, trotzdem ist das Verhalten dasselbe.

Hier die IPTables:
Code:
Chain INPUT (policy ACCEPT)
num  target  prot opt source  destination   
1  ACCEPT  0  --  anywhere  anywhere   
2  ACCEPT  0  --  anywhere  anywhere  state RELATED,ESTABLISHED
3  ACCEPT  icmp --  anywhere  anywhere   
4  ACCEPT  udp  --  anywhere  anywhere  udp dpt:route
5  ACCEPT  0  --  anywhere  anywhere  state NEW
6  ACCEPT  0  --  anywhere  anywhere  state NEW
7  ACCEPT  icmp --  anywhere  anywhere 

Chain FORWARD (policy ACCEPT)
num  target  prot opt source  destination   
1  ACCEPT  0  --  anywhere  anywhere  state RELATED,ESTABLISHED
2  ACCEPT  gre  --  192.168.3.0/24  anywhere   
3  ACCEPT  tcp  --  192.168.3.0/24  anywhere  tcp dpt:1723
4  lan2wan  0  --  anywhere  anywhere   
5  ACCEPT  0  --  anywhere  anywhere   
<--- einige weitere forwards --->
14  ACCEPT  tcp  --  anywhere  192.168.3.204  tcp dpts:5000:5100
15  ACCEPT  udp  --  anywhere  192.168.3.204  udp dpts:5000:5100
16  DROP  tcp  --  anywhere  0.0.0.0  tcp spt:0
17  DROP  udp  --  anywhere  0.0.0.0  udp dpt:0
18  TRIGGER  0  --  anywhere  anywhere  TRIGGER type:in match:0 relate:0
19  trigger_out  0  --  anywhere  anywhere   
20  ACCEPT  0  --  anywhere  anywhere  state NEW

Chain OUTPUT (policy ACCEPT)
num  target  prot opt source  destination   

Chain advgrp_1 (0 references)
num  target  prot opt source  destination   

Chain advgrp_10 (0 references)
num  target  prot opt source  destination   

Chain advgrp_2 (0 references)
num  target  prot opt source  destination   

Chain advgrp_3 (0 references)
num  target  prot opt source  destination   

Chain advgrp_4 (0 references)
num  target  prot opt source  destination   

Chain advgrp_5 (0 references)
num  target  prot opt source  destination   

Chain advgrp_6 (0 references)
num  target  prot opt source  destination   

Chain advgrp_7 (0 references)
num  target  prot opt source  destination   

Chain advgrp_8 (0 references)
num  target  prot opt source  destination   

Chain advgrp_9 (0 references)
num  target  prot opt source  destination   

Chain grp_1 (0 references)
num  target  prot opt source  destination   

Chain grp_10 (0 references)
num  target  prot opt source  destination   

Chain grp_2 (0 references)
num  target  prot opt source  destination   

Chain grp_3 (0 references)
num  target  prot opt source  destination   

Chain grp_4 (0 references)
num  target  prot opt source  destination   

Chain grp_5 (0 references)
num  target  prot opt source  destination   

Chain grp_6 (0 references)
num  target  prot opt source  destination   

Chain grp_7 (0 references)
num  target  prot opt source  destination   

Chain grp_8 (0 references)
num  target  prot opt source  destination   

Chain grp_9 (0 references)
num  target  prot opt source  destination   

Chain lan2wan (1 references)
num  target  prot opt source  destination   

Chain logaccept (0 references)
num  target  prot opt source  destination   
1  ACCEPT  0  --  anywhere  anywhere   

Chain logdrop (0 references)
num  target  prot opt source  destination   
1  DROP  0  --  anywhere  anywhere   

Chain logreject (0 references)
num  target  prot opt source  destination   
1  REJECT  tcp  --  anywhere  anywhere  reject-with tcp-reset

Chain trigger_out (1 references)
num  target  prot opt source  destination

Was sollte ich mir als nächstes angucken?
 
Das Routing oder eher Firewalling in NetzB (also nicht auf dem Router aus dem Schaubild)?

Ne, das kann ich ausschließen. Ich bin mir jetzt mit folgendem sicher: die Pakete kommen korrekt an auf dem tun0, aber die Antworten werden über eth0 rausgeschickt (mit der IP von tun0). Aber wieso und weshalb, das ist noch die Frage. Bzw. ich weiß warum die Routen standard-mäßig darüber gehen, das ist ja so eingestellt, aber sollte die Antwort nicht irgendeinen State haben, der sie dafür markiert über tun0 zurück rauszugehen?
 
Dann stimmt das routing nicht

Richtig :)

bzw die Aussage, dass du den Reply auf tun0 in tcpdump siehst.
Die incoming ICMP sehe ich auf tun0, die Antwort sehe ich auf eth0 (weil das routing nicht stimmt).

Die Frage ist wie ich das Routing anders regeln kann, grundsätzlich soll ja die defaultroute für Adressen im Internet weiterhin über eth0 gehen. Nur eben Antworten auf eingehende Verbindungen auf tun0 sollen auch über tun0 wieder raus. Einfacher wäre vielleicht noch, dass alle Nachrichten von der IP von tun0, auch immer nur über tun0 rausgehen.
Mein letztes intensives Firewalling und Routing liegt schon ein paar Jahre zurück und mit dem OpenBSD PF schien mir das alles viel einfacher....
 
Paradoxerweise sehe ich sogar auf dem Router per TCPdump, dass ICMP echo reply von tun0-Adresse zur anfragenden IP gesendet wird
Auf welchem Interface hast du das mit tcpdump gesehen? http://www.slashroot.in/linux-kernel-rpfilter-settings-reverse-path-filtering
Was war die Quell-IP des echo-request und wie lautet deine Routingtabelle?

Schätze du musst mit dem ip Werkzeug dir ein paar Regeln schreiben und Pakete markieren. Aufgrund der Markierung soll dann die Rückroute gefunden werden.
https://kindlund.wordpress.com/2007/11/19/configuring-multiple-default-routes-in-linux/
 
In pf(4) wuerde ich mal in Richtung tag/tagged und received-on denken. Geht mit iptables wahrscheinlich auch "irgendwie"
 
OT: Wenn es nur Router gäbe, auf denen OpenBSD oder FreeBSD liefe mit vernünftigem modernen WLAN ;'( (und ja, das 11ac und die Kanalbündelung bringen bei dem Elektro-Smog deutliche Vorteile). In meiner nächsten Wohnung werde ich wohl Router und AP einfach trennen müssen...
 
Einfacher wäre vielleicht noch, dass alle Nachrichten von der IP von tun0, auch immer nur über tun0 rausgehen.

War dann doch einfacher als gedacht:
Code:
ip rule add from VPN_IP  table 200
ip route add default via VPN_GW dev VPN_DEV table 200
:cool:
 
Zurück
Oben