[Frage] FB als Gateway über OpenVPN: Routing Problem

Sidebar Sidebar
Upgrade 3CX to v18 and get it hosted free!
Bernd_das_Brot

Bernd_das_Brot

Neuer User
Mitglied seit
9 Apr 2005
Beiträge
20
Punkte für Reaktionen
0
Punkte
0
Hallo,

ich möchte meine box über lan1 an einen router anschließen. die box soll über openvpn eine verbindung zu einem vpn-root-server herstellen. der vpn-server ist als internet-gateway konfiguriert und funktioniert. der gesamte traffic hinter der box (wlan, ip-telefonie, lan) soll die box durch den tunnel leiten.

was bisher funktioniert:
- server funktioniert als gateway und leitet alles weiter ins www (ip 123.40.123.XX)
- fb verbindet sich mit vpn-server (ip 192.168.XXX.1)
- fb erhält die korrekten ip-adressen vom vpn-tunnel

was nicht funktioniert:
das Routing

wenn ich mit der box surfe, benutzt sie immer noch den router als gateway und nicht den vpn-tunnel. ich hänge einmal die ausgabe von netstat -nr an.

Code: 
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
123.40.123.XX   192.168.XXX.1   255.255.255.255 UGH       0 0          0 lan
10.8.0.1        10.8.0.9        255.255.255.255 UGH       0 0          0 tun0
10.8.0.9        0.0.0.0         255.255.255.255 UH        0 0          0 tun0
192.168.XXX.0   0.0.0.0         255.255.255.0   U         0 0          0 lan
169.254.0.0     0.0.0.0         255.255.0.0     U         0 0          0 lan
0.0.0.0         10.8.0.9        128.0.0.0       UG        0 0          0 tun0
128.0.0.0       10.8.0.9        128.0.0.0       UG        0 0          0 tun0
0.0.0.0         0.0.0.0         0.0.0.0         U         0 0          0 tun0
0.0.0.0         192.168.XXX.1   0.0.0.0         UG        0 0          0 lan

nachdem ich mich eine nacht damit herumgeschlagen hab, bin ich mit meinem latein am ende.

hat jemand eine idee?

vielen dank im voraus!!!
 
Du hast viel zu viele Defaultgateways ;)
Eigentlich sollte nur eine Hostroute für die offizielle IP des VPN-Servers zum Internetrouter existieren, und dann eine Defaultroute zum VPN-Server über die VPN-IP des Servers.
Was “verkehrt“ ist, könnte man aber nur mit den Konfigs erkennen...
 
Zuletzt bearbeitet:
Danke für die Antwort!

Ok, dann poste ich hier mal die server.conf

Code: 
port 4242
proto tcp

dev tun

ca ca.crt
cert server.crt
key server.key  

dh dh1024.pem

server 10.8.0.0 255.255.255.0

ifconfig-pool-persist ipp.txt
push "redirect-gateway def1 bypass-dhcp"

keepalive 10 120
comp-lzo

max-clients 2

user openvpn
group openvpn

persist-key
persist-tun

status openvpn-status.log

verb 3

Und die client.conf

Code: 
client
dev tun
dev-node /var/tmp/tun
proto tcp
remote 123.XX.XXX.51 4242
resolv-retry infinite
nobind
persist-key
persist-tun
ca ca.crt
cert fritzbox.crt
key fritzbox.key
comp-lzo
verb 3
mute 20
ns-cert-type server

Ich muss tcp nutzen, da ich später durch einen Proxy über Port 443 durch muss.

Die Fritzbox vergibt immer noch ip-Adressen im Raum des Routers. Kann man das auch trennen, so dass die Fritzbox ein eigenes lokales Netz aufmacht?
 
Und diese Configs erzeugen die vielen Gateways? Dann müsste man das Log vom Start sehen...
Die Frage mit dem Vergeben der IPs habe ich nicht verstanden. Wenn die FB per LAN1 am Netz hängt, sollte LAN der FB und die Verbindung zum Router verschieden sein (können).
 
Das ist die log-file vom openvpn-start der fritzbox

Code: 
Sun Jul 31 16:47:37 2011 OpenVPN 2.1_rc1 mipsel-linux [SSL] [LZO2] [EPOLL] built on Jan  5 2007
Sun Jul 31 16:47:37 2011 WARNING: file 'fritzbox.key' is group or others accessible
Sun Jul 31 16:47:37 2011 LZO compression initialized
Sun Jul 31 16:47:37 2011 Control Channel MTU parms [ L:1544 D:140 EF:40 EB:0 ET:0 EL:0 ]
Sun Jul 31 16:47:37 2011 Data Channel MTU parms [ L:1544 D:1450 EF:44 EB:135 ET:0 EL:0 AF:3/1 ]
Sun Jul 31 16:47:37 2011 Local Options hash (VER=V4): '69109d17'
Sun Jul 31 16:47:37 2011 Expected Remote Options hash (VER=V4): 'c0103fa8'
Sun Jul 31 16:47:37 2011 Attempting to establish TCP connection with 123.XXX.XXX.51:4242 [nonblock]
Sun Jul 31 16:47:38 2011 TCP connection established with 123.XXX.XXX.51:4242
Sun Jul 31 16:47:38 2011 Socket Buffers: R=[87380->131072] S=[16384->131072]
Sun Jul 31 16:47:38 2011 TCPv123.XXX.XXX.514_CLIENT link local: [undef]
Sun Jul 31 16:47:38 2011 TCPv4_CLIENT link remote: 123.XXX.XXX.51:4242
Sun Jul 31 16:47:38 2011 TLS: Initial packet from 123.XXX.XXX.51:4242, sid=98946d6d 8141677d
Sun Jul 31 16:47:39 2011 VERIFY OK: depth=1, /C=DE/ST=DE/L=XXX/O=unknown/CN=togo/emailAddress=XXXX
Sun Jul 31 16:47:39 2011 VERIFY OK: nsCertType=SERVER
Sun Jul 31 16:47:39 2011 VERIFY OK: depth=0, /C=DE/ST=DE/L=XXXX/O=unknown/CN=server/emailAddress=XXX
Sun Jul 31 16:47:40 2011 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Sun Jul 31 16:47:40 2011 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Sun Jul 31 16:47:40 2011 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Sun Jul 31 16:47:40 2011 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Sun Jul 31 16:47:40 2011 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Sun Jul 31 16:47:40 2011 [server] Peer Connection Initiated with 123.XXX.XXX.51:4242
Sun Jul 31 16:47:41 2011 SENT CONTROL [server]: 'PUSH_REQUEST' (status=1)
Sun Jul 31 16:47:41 2011 PUSH: Received control message: 'PUSH_REPLY,redirect-gateway def1 bypass-dhcp,route 10.8.0.1,topology net30,ping 10,ping-restart 120,ifconfig 10.8.0.10 10.8.0.9'
Sun Jul 31 16:47:41 2011 OPTIONS IMPORT: timers and/or timeouts modified
Sun Jul 31 16:47:41 2011 OPTIONS IMPORT: --ifconfig/up options modified
Sun Jul 31 16:47:41 2011 OPTIONS IMPORT: route options modified
Sun Jul 31 16:47:41 2011 TUN/TAP device tun0 opened
Sun Jul 31 16:47:41 2011 TUN/TAP TX queue length set to 100
Sun Jul 31 16:47:41 2011 /sbin/ifconfig tun0 10.8.0.10 pointopoint 10.8.0.9 mtu 1500
Sun Jul 31 16:47:41 2011 /sbin/route add -net 123.XXX.XXX.51 netmask 255.255.255.255 gw 192.168.178.1
Sun Jul 31 16:47:41 2011 /sbin/route add -net 0.0.0.0 netmask 128.0.0.0 gw 10.8.0.9
Sun Jul 31 16:47:41 2011 /sbin/route add -net 128.0.0.0 netmask 128.0.0.0 gw 10.8.0.9
Sun Jul 31 16:47:41 2011 /sbin/route add -net 10.8.0.1 netmask 255.255.255.255 gw 10.8.0.9
Sun Jul 31 16:47:41 2011 Initialization Sequence Completed

zur Frage mit dem Netzwerk hinter der Fritzbox:
Der Router gibt ein Netz à la 192.168.178.0 vor. Die Fritzbox hängt daran über LAN1. Wenn ich nun an der Box weitere Geräte anschließe, bekommen diese automatisch auch eine 192.168.178.0 Adresse. Meine Frage lautet, ob ich der Fritzbox auch einen eigenen Adressraum geben kann bzw. wie funktioniert das? Die entpsrechende Einstellung über Heimnetz -> Netzwerkeinstellungen ist nicht mehr vorhanden. Außer natürlich es gibt einen telnet-Trick :)
 
Zuletzt bearbeitet:
Gemäß dem Log sollte es schon korrekt laufen, die Route für das Defaultgateway über das VPN mit der Maske 0.0.0.0 müsste von woanders kommen.
Somit sollte das Surfen von der Box aus (mit welchem Browser auf der Box testes du denn?) durch den Tunnel gehen. Ein Trace (z.B. “traceroute -n heise.de“) müsste auch als ersten Hop die VPN-IP des Servers zeigen. Tut er das auch?
Zur DHCP Frage: Sind die Netze auch getrennt? Also “eigene Verbindung aufbauen“ ausgewählt?
Oder hast du etwa “vorhandene Verbindung mitbenutzen“ gewählt? Dann vergibt sowieso der “erste“ Router die IPs und nicht die VPN-Clientbox.
 
Du hast viel zu viele Defaultgateways
Zum Vergrößern anklicken....
They will be overruled by following more specific routes and thus never be used!
0.0.0.0 10.8.0.9 128.0.0.0 UG 0 0 0 tun0
128.0.0.0 10.8.0.9 128.0.0.0 UG 0 0 0 tun0
Zum Vergrößern anklicken....

My german reading is limited, I guess fritbox is vpn server, then remote tunnel destination route should point to internet (dsl interface?) instead of FB internal address:
Sun Jul 31 16:47:41 2011 /sbin/route add -net 123.XXX.XXX.51 netmask 255.255.255.255 gw 192.168.178.1
Zum Vergrößern anklicken....
 
From the look of the routingtable the hostroute is already present. Regarding the defaultroutes the second DG to tun0 with mask /0 seemed strage to me. I think the problem is the fact, the router acting as VPN client is just a regular LAN member but not it's default gateway.
So he must make sure, the client is defaultgateway even if not internet gateway or change the mode of “internet over LAN1“ to act as router (from use as client, sorry I don't know the english description).
 
Zuletzt bearbeitet:
DualIP schrieb:
I guess fritbox is vpn server, then remote tunnel destination route should point to internet (dsl interface?)
Zum Vergrößern anklicken....

no, fritzbox is client.

_____

Danke für den Tipp mit den getrennten Netzwerken! Jetzt wird lan1 als wan genutzt und die restlichen Anschlüsse haben ein eigenes Netz. So wollte ich das!

Diese Umstellung half auch dem Rest auf die Sprünge. Zunächst habe ich das Standard-Gateway über das wan gelöscht (#: route del default dev dsl) Danach den Connect zum VPN-Server geroutet (#: route add -host 123.XXX.XXX.51 dev dsl). Danach starte ich den vpn-Client und füge noch das default-Gateway hinzu (#: route add -net 0.0.0.0/0 dev tun0) So und dann sieht netstat -nr folgendermaßen aus:

Code: 
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
123.XXX.XXX.51   0.0.0.0         255.255.255.255 UH        0 0          0 dsl
10.8.0.1        10.8.0.9        255.255.255.255 UGH       0 0          0 tun0
192.168.180.1   0.0.0.0         255.255.255.255 UH        0 0          0 dsl
192.168.180.2   0.0.0.0         255.255.255.255 UH        0 0          0 dsl
10.8.0.9        0.0.0.0         255.255.255.255 UH        0 0          0 tun0
192.168.178.0   0.0.0.0         255.255.255.0   U         0 0          0 dsl
192.168.179.0   0.0.0.0         255.255.255.0   U         0 0          0 lan
169.254.0.0     0.0.0.0         255.255.0.0     U         0 0          0 lan
0.0.0.0         0.0.0.0         0.0.0.0         U         0 0          0 tun0


wenn ich dann traceroute -n heise.de auf der fritzbox ausführe sieht das ergebnis positiv aus

Code: 
# traceroute -n heise.de
traceroute to heise.de (193.99.144.80), 30 hops max, 38 byte packets
 1  10.8.0.1  39.653 ms  38.667 ms  38.733 ms
 2  123.XXX.XXX.81  39.476 ms  39.881 ms  38.862 ms
 3  213.239.227.129  39.332 ms 213.239.227.193  39.043 ms 213.239.227.225  39.026 ms
 4  213.239.240.230  43.448 ms  43.159 ms  43.937 ms
 5  80.81.193.132  44.408 ms  44.344 ms  45.335 ms
 6  82.98.98.98  44.615 ms !A 82.98.98.110  44.846 ms !A *

Sieht gut aus!

doch sobald ich dann am PC über Firefox oder Google Chrome eine Internet-Seite aufrufen möchte, klappt es nicht. wenn ich dann am pc traceroute -n heise.de ausführe kommt folgendes heraus:

Code: 
e-macbook-pro:~ user$ traceroute -n heise.de
traceroute to heise.de (193.99.144.80), 64 hops max, 52 byte packets
 1  192.168.179.1  1.046 ms  0.675 ms  0.695 ms
 2  * * *
 3  * * *
.... .... ...

also scheint doch am routing der fritzbox etwas nicht zu stimmen, oder?
 
I guess this problem is on VPN server side:
It should have route back to 192.168.179.0/24 over the tunnel, not using NAT

Traceroute from fritzbox works because it uses 10.8.0.9 as source
 
thanks,

guess you're right! it's about iptables of the server. I need to know, how I can do this without using masquerade, because it's kernel module isn't available. I can use snat instead.

I found a pretty good instruction on the internet. It says:

Code: 
OpenVPNserver$ # iptables -I FORWARD -i tun0 -j ACCEPT
OpenVPNserver$ # iptables -I FORWARD -o tun0 -j ACCEPT
OpenVPNserver$ # iptables -t nat -A POSTROUTING -o eth0 -s 10.8.0.0/24 -j MASQUERADE
OpenVPNserver$ # iptables -t nat -A POSTROUTING -o eth0 -s 192.168.179.0/24 -j MASQUERADE
OpenVPNserver$ # iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE

Is that right? How can I do these commands with snat instead of masquerade?
 
Bernd_das_Brot schrieb:
... How can I do these commands with snat instead of masquerade?
Zum Vergrößern anklicken....
Du hast doch schon erkannt, dass MASQUERADE der Spezialfall von SNAT ist (für dynamische IP-Adressen). D. h. MASQUERADE übernimmt die jeweilige IP-Adresse des o-Interface als Source-IP. Für SNAT, ist dann --to-source <IP-Adresse des o-Interface>
 
Before diving into NAT, first try to ping 10.8.0.1 from 192.168.179.x LAN. this will check route back to you on vpn server.

You need masquerade rule if you're using DHCP otherwise you can do without:
IPT -t nat -A POSTROUTING -s 192.168.178.0/24 -o eth0 -j SNAT --to-source $ETH0_PRIVATE_ADDRESS

but you won't need NAT on tunnel interface:
iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE
 
pinging to 10.8.0.1 from 192.168.179.x is successful.

even with "IPT -t nat -A POSTROUTING -s 192.168.178.0/24 -o eth0 -j SNAT --to-source XXX.XXX.XXX.XXX" it doesn't work. my table looks like this:

Code: 
 iptables -I FORWARD -i tun0 -j ACCEPT
iptables -I FORWARD -o tun0 -j ACCEPT
iptables -t nat -A POSTROUTING -s 192.168.179.0/24 -o venet0 -j SNAT --to-source 123.XXX.XXX.51
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -j SNAT --to-source 123.XXX.XXX.51

is this correct?
 
What is "-o venet0" ? If thats the name of your interface facing the internet, it's ok.
Also, in forwarding rules, you might need to allow traffic:
iptables -A FORWARD -s 192.168.179.0/24 (-o eth0) -j ACCEPT
 
Wie oben schon von anderen geschriben rate auch ich dir, NAT und iptables nur als letzte Notlösung zu nutzen.Du hast den Server in der Hand, also pass dort die Config so an, dass dein LAN zu deinem Client geroutet wird. Die ganze iptables Geschichte kannst du dir dann sparen.
Das gilt aber nur für die Client Seite. Der Server muss dann schon auch die Pakete aus deinem LAN auf seine offizielle IP NATten...

EDIT: Ach so, mir fällt gerade auf, dass du auf dem Server ja keinen “iroute“ Eintrag für dein LAN hast. Schau dazu mal im Forum oder auf der Openvpn-Seite, das ist jetzt für mich etwas blöd, das zu suchen
 
Zuletzt bearbeitet:
ok, ich habe eure Ratschläge befolgt und versuche es ohne iptables zwischen lan und server. ich bin nun ein paar schritte zurück und habe folgendes getan:

in der server.conf des vpn-servers habe ich folgendes eigetragen

Code: 
client-config-dir ccd
route 192.168.179.0 255.255.255.0

im openvpn Verzeichnis auf dem Server habe ich einen Ordner "ccd" erstellt und in dort eine Datei fritzbox (commonname) angelegt, in der steht

Code: 
iroute 192.168.179.0 255.255.255.0

auf der fritzbox sieht netstat -nr nach "netstat del default dev dsl", "netstat add -host 123.XXX.XXX.51 dev dsl", "netstat add -net 0.0.0.0/0 dev tun0" und openvpn-client-start so aus

Code: 
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
123.XXX.XXX.51   0.0.0.0         255.255.255.255 UH        0 0          0 dsl
10.8.0.1        10.8.0.9        255.255.255.255 UGH       0 0          0 tun0
192.168.180.1   0.0.0.0         255.255.255.255 UH        0 0          0 dsl
192.168.180.2   0.0.0.0         255.255.255.255 UH        0 0          0 dsl
10.8.0.9        0.0.0.0         255.255.255.255 UH        0 0          0 tun0
192.168.178.0   0.0.0.0         255.255.255.0   U         0 0          0 dsl
192.168.179.0   0.0.0.0         255.255.255.0   U         0 0          0 lan
169.254.0.0     0.0.0.0         255.255.0.0     U         0 0          0 lan
0.0.0.0         0.0.0.0         0.0.0.0         U         0 0          0 tun0

wenn ich jetzt mit meinem Laptop "ping -c 5 10.8.0.1" ausführe, kommt der ping am Server an (mit tcpdump dort überprüft). Wenn ich vom Laptop "traceroute -n heise.de" ausführe, sieht es auch gut aus:

Code: 
e-macbook-pro:~ user$ traceroute -n heise.de
traceroute to heise.de (193.99.144.80), 64 hops max, 52 byte packets
 1  192.168.179.1  1.214 ms  0.740 ms  0.810 ms
 2  10.8.0.1  39.759 ms  39.096 ms  39.815 ms
 3  ***
[1]+  Stopped                 traceroute -n heise.de

genauso kann ich vom Server aus mit "ping -c 5 192.168.179.20" (meine Laptop-IP) erreichen. Das heißt ich habe schon mal den Hinweg zu und Rückweg von 10.8.0.1.

dass es vom Server nicht weiter ins Internet geht ist nicht weiter verwunderlich, weil der Server noch nichts in iptables stehen hat.

Da komme ich nun zu meinen Frage:
Mit welchen Befehlen muss ich iptables jetzt füttern, damit er das tun0 device auf venet0 routet? (das fehlt ja vermutlich noch)
Bzw. muss ich dazu jetzt iptables benutzen oder geht das auch mit route add usw. ?

Und insgesamt ist das doch der richtige Weg?

Ihr seid spitze! Danke für Eure Hilfe! Ich habe das Gefühl ganz nah an der Lösung dran zu sein :)
 
Zuletzt bearbeitet:
Divide and conquer:l use tcpdump on server side, internet interface to see if your packets are sent out and being NATted. Then we know if problem is in outgoing or incoming direction

Server side should already have some nat, what rules are present?
Code: 
iptables -vL
iptables -t -vL
 
Hey,

there are no entries in iptables, because I didn't insert any. First I wanted to make sure that the routing from PC --> Fritzbox --> Server is working - it does. Now I need to know which table entries are necessary to route/nat (sorry, I don't know the difference between them) tun0 to venet0. Venet0 has a static ip (123.XXX.XXX.51).

So how can I make the connection from tun0 to venet0? With iptables? Or route?
 
Rules you posted earlier look fine
Code: 
iptables -I FORWARD -i tun0 -j ACCEPT
iptables -I FORWARD -o tun0 -j ACCEPT
iptables -t nat -A POSTROUTING -s 192.168.179.0/24 -o venet0 -j SNAT --to-source 123.XXX.XXX.51
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -j SNAT --to-source 123.XXX.XXX.51

So how can I make the connection from tun0 to venet0?
Zum Vergrößern anklicken....
just make sure IP routing is enabled:
echo 1 > /proc/sys/net/ipv4/ip_forward
and have proper entries in routing table
 
Um antworten zu können musst du eingeloggt sein.

Zurzeit aktive Besucher

Gesamt: 480 (Mitglieder: 1, Gäste: 479)

Neueste Beiträge

Statistik des Forums

Themen
244,831
Beiträge
2,219,105
Mitglieder
371,533
Neuestes Mitglied
ipeee
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.
Ihr E-Mail-Adresse verifizieren

Ihr E-Mail-Adresse verifizieren

Wir haben Ihnen eine E-Mail geschickt. Klicken Sie auf die Schaltfläche im E-Mail-Text, um Ihre E-Mail-Adresse zu verifizieren – (Können Sie diese nicht finden können, dann überprüfen Sie Ihren Spam-Ordner).

IPPF im Überblick

Neueste Beiträge

Direktlinks Telefonanlage

Website-Sponsoren

3CX sponsor
KONTAKTIEREN SIE UNS BEI INTERESSE
| Style by ThemeHouse
XenPorta 2 PRO © Jason Axelrod of 8WAYRUN
Oben Unten
Zurück