[Gelöst] Kein Portforwarding von freetz' openvpn möglich ??

[koronth]

Hi Leute,

ich bin mit meinem Latein am Ende und weiß echt nicht mehr weiter.

Ich versuche mit openvpn auf der FB einen VPN-Tunnel zum Anbieter "Perfect Privacy" für alle Geräte an der Fritzbox zu legen.
Das funktioniert auch super, wenn man mal davon absieht, daß nach ca. 2-3 MBit/s Durchsatz die CPU der 7270 dicht ist . Okay, nicht überraschend soweit.

Nun versuche ich aber als i-Tüpfelchen schon seit einer zweistelligen Anzahl von Stunden, auch das Remote Port Forwarding von Perfect Privacy zu verwenden (die leiten fünf Ports - im folgenden 40006, TCP als Beispiel - des öffentlichen Tunnel-Endes an das private Tunnelende (im folgenden Beispiel: 10.0.61.6) weiter, damit man auch in gewissem Umfang mit von außen initierte Verbindungen arbeiten kann ...)

Diese Remote Port Forwardings kriege ich einfach nicht weitergeleitet!

Hier mein tun0-Device nach Aufbau des VPN-Tunnels - alles läuft super; aller Verkehr, für den nicht eine andere Route existiert, geht auch sauber durch tun0:

tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          inet addr:10.0.61.6  P-t-P:10.0.61.5  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP ALLMULTI MULTICAST  MTU:1500  Metric:1
          RX packets:273 errors:0 dropped:0 overruns:0 frame:0
          TX packets:277 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:26092 (25.4 KiB)  TX bytes:13354 (13.0 KiB)

Spreche ich das öffentliche VPN-Tunnel-Ende auf dem für mich geforwardeten Port (in diesem Falle gerade 40006) an, dann sehe ich auch via tcpdump, wie das Paket auf dem tun0-Device (IP: 10.0.61.6) ankommt:

22:07:28.700521 IP <irgendeine oeffentliche ip>.43192 > 10.0.61.6.40006: Flags [S], seq 2362419047, win 14600, options [mss 1198,sackOK,TS val 1949240966 ecr 0,nop,wscale 6], length 0

Aber damit ist auch schon Schluß - ich kriege diese Pakete einfach nicht zu fassen! Ich versuche es auf 127.0.0.1:22, 192.168.69.35:22 oder wohin auch immer umzuleiten ... es passiert einfach nix!

Ich habe es mit allen möglichen Varianten von socat versucht, die sich versuchen an die IP des tun0-Devices (persistent oder auch nicht) und den fraglichen Port (40006) zu binden:

socat tcp-listen:40006,fork,reuseaddr,interface=tun0 tcp-connect:192.168.69.35:22
socat tcp-listen:40006,bind=10.0.61.6,fork,reuseaddr tcp-connect:192.168.69.35:22
socat tcp-listen:40006,bind=10.0.61.6,fork,reuseaddr,interface=tun0 tcp-connect:192.168.69.35:22
socat tcp-listen:40006,fork,reuseaddr tcp-connect:192.168.69.35:22

Völlig ergebnislos! socat kriegt einfach nix zum Weiterleiten.



Auch das DNAT-Target (eigentlich die erste Wahl) von iptables habe ich ausprobiert; wieder in verschiedenen Varianten:

iptables -t nat -I PREROUTING 1 -i tun0 -d 10.0.61.6 -p tcp --dport 40006 -j DNAT --to-destination 192.168.69.35:22
iptables -t nat -I PREROUTING 1 -d 10.0.61.6 -p tcp --dport 40006 -j DNAT --to-destination 192.168.69.35:22
iptables -t nat -I PREROUTING 1 -i tun0 -d 10.0.61.6 -p tcp --dport 40006 -j DNAT --to-destination 192.168.69.35:22
iptables -t nat -I PREROUTING 1 -i tun0 -d 10.0.61.6 -p tcp --dport 40006 -j DNAT --to-destination 127.0.0.1:22
...

Nichts!!

Das schärfste ist, daß die Iptables Regel sehr wohl gematcht wird, wie man z.B. hier am Pakets-Counter (Pkts) der PREROUTING-Chain sieht:

# iptables -t nat -L -nv
Chain PREROUTING (policy ACCEPT 9995 packets, 1012K bytes)
 pkts bytes target     prot opt in     out     source               destination
    3   152 DNAT       tcp  --  *      *       0.0.0.0/0            10.0.61.6           tcp dpt:40006 to:192.168.69.35:22

Chain POSTROUTING (policy ACCEPT 6634 packets, 608K bytes)
 pkts bytes target     prot opt in     out     source               destination
  305 19291 MASQUERADE  all  --  *      tun0    0.0.0.0/0            0.0.0.0/0

Chain OUTPUT (policy ACCEPT 11075 packets, 902K bytes)
 pkts bytes target     prot opt in     out     source               destination

Aber die eingehene Pakete werden weder durch iptables noch socat irgendwohin weitergeleitet.


Wird openvpn hingegen auf einem normalen Linux-Rechner gestartet, führen die oben aufgeführten Wege via iptables oder socat aber sehr wohl zum Erfolg und forwarden die eingehende Pakete sauber weiter.


Daher bin ich nun völlig ratlos.

Übersehe ich irgendwas?

Verändert die Router-Situation auf der Fritzbox irgendwas daran, wie man die o.g. eingehenden Pakete forwarden muß?

Ist das openvpn-Binary von Freetz 1.2 vielleicht abgespeckt?


Wieder mal, wäre ich für jegliche Hilfe dankbar!!

Danke & Bye!

 

[RalfFriedl]

Wenn Du den SSH-Server auf der Box erreichen willst, dann lass den doch einfach auf Port 40006 laufen, dann brauchst Du die ganze Weiterleitung nicht.

Ansonsten, wie sehen Deine Filter-Regeln aus?

 

[koronth]

Hi RalfFriedl,

danke für Deine Antwort erst einmal!

Port 22 war natürlich nur ein Beispiel, weil da halt gerade ein laufender Service zur Verfügung stand.
Aber ich habe es ausprobiert. Auch nach einem

dropbear -p 40006 -FE

passiert nach einem Connect von außen auf den für mich weitergeleiteten Port 40006 nichts - obgleich ich via

tcpdump -i tun0

das Paket einschlagen sehe (siehe mein erstes Posting).

Meine iptables-Rules sind natürlich (zum Testen) völlig auf ACCEPT:

# iptables -L -nv
Chain INPUT (policy ACCEPT 71494 packets, 20M bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain FORWARD (policy ACCEPT 1514 packets, 494K bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 85354 packets, 13M bytes)
 pkts bytes target     prot opt in     out     source               destination

BTW hier die NAT-Table im dropbear-Szenario:

# iptables -t nat -L -nv
Chain PREROUTING (policy ACCEPT 1521 packets, 107K bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain POSTROUTING (policy ACCEPT 2246 packets, 272K bytes)
 pkts bytes target     prot opt in     out     source               destination         
   75 23911 MASQUERADE  all  --  *      nas0    0.0.0.0/0            0.0.0.0/0           
  212 13590 MASQUERADE  all  --  *      tun0    0.0.0.0/0            0.0.0.0/0           

Chain OUTPUT (policy ACCEPT 10494 packets, 832K bytes)
 pkts bytes target     prot opt in     out     source               destination

Wobei ich testweise auch schonmal die MASQUERADE-Rule für tun0 - ohne Ergebnis - entfernt habe, weil ich ja erstmal nur auf der Fritzbox das eingehende Paket zu fassen und zum Weitergeleitet-Werden kriegen will.

Aber ich komme einfach nicht ran an das reinkommende Paket, wenn "ich" mich an die IP des tun0-Interfaces binde (siehe socat-Zeilen oben in meinem ersten Posting) .

Mit unerwünschten Nebenwirkungen mit dem AVMs Zeugs (AVM-Firewall & - Portforwarding) sollte es ja auch nix zu tun haben, denn ich sehe, das Paket ja reinkommen (mit tun0 ja auch sowieso auf einem nicht dsld-bedientem Interface) mit tcpdump, oder??

Ich bin soweit ratlos.

An die Freetz-Leute: Lohnt es sich für mich, das openVPN-Paket nochmal selber zu übersetzen, weil Ihr da beim Compilieren z.B. irgendwelche (Platz-) Optimierungen/Weglassungen vorgenommen habt?

Danke & Bye!

 

[RalfFriedl]

OpenVPN ist ja nur dafür da, Pakete vom einen Ende zu anderen zu übertragen. Ob diese Pakete dann als TCP oder sonst etwas betrachtet werden, ist dann Sache des Kernels.

Du könntest mal Tcpdump auf das Interface "any" laufen lassen (-i any). Du schreibst oben "irgendeine oeffentliche ip". Wie sieht denn die Routing-Tabelle aus? Kann es sein, dass die Antwort an diese "irgendeine oeffentliche ip" nicht auf das tun Interface geht?

 

[koronth]

Verdammt, Du hast ja so Recht! Vielen Dank für die Beseitigung der Tomaten auf meinen Augen!

Der Testzugriff auf den am öffentlichen VPN-Ende freigegebenen Port erfolgte bei mir immer nur von einer bestimmten IP, die zufällig in einem Bereich war, für den ich manuell eine Route am VPN vorbeigelegt hatte; daher konnte - wie Du richtig vermutet hast - das vom VPN-Provider für mich geforwardete Paket mich gar nicht über das tun-Device erreichen, sondern kam anscheinend übers dsl-Interface rein :-/.

Nun - beim Test von einer IP ohne Routen-Sonderbehandlung - funktioniert das Forwarding sowohl mit dem iptables-DNAT-target als auch Tools wie socat problemlos.

Ralf, vielen herzlichen Dank für Deine Hilfe!

Danke & Bye!