openVPN Rounting Problem

[aargau]

Hallo zusammen

Ich weis, eigentlich hat das Forum hier nicht wirklich viel mit Informatik zu tun, aber da ich schon öfters gesehen habe, dass es hier auch Leute gibt die in diesem bereich Ahnung haben, möchte ich es dennoch mal versuchen ;-)

Ich baue momentan an einem Netzwerk welches über mehrere Zweigstellen läuft (RZ, Wohnung, Hobbyraum) um meine Daten darüber zu Syncen / Backupen.
Aktuell bin ich daran die Standorte via openVPN zu vernetzen.
Zum Einsatz kommen jeweils kleine Linux Router mit Alpine Linux als OS.
Als Firewall verwende ich Shorewall welches selbst auf iptables aufbaut.

Nun habe ich an Standort A (aktuell lokal im Netzwerk) auf dem Linux Router openVPN als Server am laufen.
Nutze ich eine "default" Konfig krieg ich eine Verbindung mit dem 2. Router problemlos ans laufen.

Die Konfig sieht dabei so aus:

;BASIC
port 9876
proto udp
dev tun
tls-server
; CERTS

;ADDON
mode server
server 10.20.10.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "route 10.20.10.0 255.255.255.0"
push "dhcp-option DNS 8.8.8.8" ;braucht es eig nicht
keepalive 10 120
comp-lzo
persist-key
persist-tun
status /var/log/openvpn-status.log
log-append  /var/log/openvpn1.log
verb 3

Dabei erhält der Server automatisch die IP 10.20.10.1/24 und die Clients 6-xx
Pings klappen so von a zu b wie auch von b zu a

Ich möchte aber sowohl dem Server als auch den Clients feste IP Adressen vergeben und sobald ich das mache Funktioniert das Routing nicht mehr korrekt.

Konfig dazu:

;BASIC
port 9876
proto udp
dev tun
tls-server
; CERTS

;ADDON
mode server
ifconfig 10.20.10.10 255.255.255.0
ifconfig-pool 10.20.10.20 10.20.10.30
push "route 10.20.10.0 255.255.255.0"
push "dhcp-option DNS 10.0.0.1"
keepalive 10 120
comp-lzo

Der Client bleibt dabei test weise gleich (selbes resultat auch wenn ich die IP manuell konfiguriere).
Ein Ping ist nicht mehr möglich. Ein traceroute führt ins leere, er findet also die Route nicht mehr in das 10.20.10.x Netz obwohl das tun0 Interface eindeutlig eine IP dazu besitzt.

Ein route -n ergibt:

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         80.219.46.1     0.0.0.0         UG    205    0        0 eth0.10
10.10.10.0      0.0.0.0         255.255.255.0   U     0      0        0 eth0.1
10.10.40.0      0.0.0.0         255.255.255.0   U     0      0        0 eth0.2
80.219.46.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0.10
255.255.255.0      0.0.0.0         255.255.255.255 UH    0      0        0 tun0

Also eigentlich kein Wunder das es nicht klappt.
Ein manuelles Adden der Route scheitert mit einem Fehler.

Hat jemand eine Idee was da falsch läuft?

 

[aargau]

Bin ein stückchen weiter gekommen, es muss mit dem "ifconfig" zusammenhängen, scheinbar gib ich damit nur die IPs an, nicht aber das subnetz. Er trägt mir somit 255.255.255.0 als IP Adresse für das tun0 interface ein, was natürlich so nicht klappen kann.

 

[Novulon]

Bin gerade Karnevalsmäßig unterwegs, deshalb konnte ich deinen Thread nur überfliegen und laufe gerade Gefahr Müll zu Posten .

Warum benutzt du nicht die client-config-dir Direktive?
https://thomas-leister.de/internet/openvpn-statische-ips-clients-vergeben/

Wenn du weiterhin Windows Clients mit vernetzt musst du darauf achten IPs aus dem /30 Subnetz zu vergeben.

"Each pair of*ifconfig-push*addresses represent the virtual client and server IP endpoints. They must be taken from successive /30 subnets in order to be compatible with Windows clients and the TAP-Windows driver. Specifically, the last octet in the IP address of each endpoint pair must be taken from this set:

[ 1, 2] [ 5, 6] [ 9, 10] [ 13, 14] [ 17, 18]
[ 21, 22] [ 25, 26] [ 29, 30] [ 33, 34] [ 37, 38]
[ 41, 42] [ 45, 46] [ 49, 50] [ 53, 54] [ 57, 58]
[ 61, 62] [ 65, 66] [ 69, 70] [ 73, 74] [ 77, 78]
[ 81, 82] [ 85, 86] [ 89, 90] [ 93, 94] [ 97, 98]
[101,102] [105,106] [109,110] [113,114] [117,118]
[121,122] [125,126] [129,130] [133,134] [137,138]
[141,142] [145,146] [149,150] [153,154] [157,158]
[161,162] [165,166] [169,170] [173,174] [177,178]
[181,182] [185,186] [189,190] [193,194] [197,198]
[201,202] [205,206] [209,210] [213,214] [217,218]
[221,222] [225,226] [229,230] [233,234] [237,238]
[241,242] [245,246] [249,250] [253,254]"

 

[aargau]

das via client-config-dir muss ich mir mal genauer ansehen.
Kämpfe aber schon mit dem nächsten Problem.

Ich bin nicht wirklich ein Linux "Profi" und stehe nun an folgendem Problem an:
openVPN läuft via normaler Vergabe der IPs durch den Server.
Ich kann über das openVPN Netzwerk (10.100.10.x) sowohl vom client den server pingen als auch auf die andere Seite.

vom client komm ich sogar auf das Interne Netz auf der Server Seite, zumindest kann ich es anpingen.
Aber weder vom Server noch vom Netzwerk hinter dem Server komm ich auf den client...
Ich habe versucht die Route via route add -net zu setzen, das klappt auch irgend wie, aber scheinbar nicht korrekt.

Kann mir jemand sagen wie die Route aussehen müsste?

Serverseite:
"internes Netz": 10.20.10.x/24
"vpn Netz": 10.100.10.1/24

Client Seite:
"internes Netz" 10.10.10.0/24
"vpn Netz: 10.100.10.6/24

mein route befehl sah so aus:
route add -net 10.10.10.0 netmask 255.255.255.0 dev tun0
oder
route add -net 10.10.10.0 netmask 255.255.255.0 gw 10.100.10.2 (selbes wie beim 10.100.10.x Netz)

ein traceroute führt ins nirvana.

Interessant finde ich aber eben, dass der Client auch das 10.20.10.x Netz pingen kann und auch eine Antwort kriegt, somit muss die route ja eigentlich existieren?!

In der Firewall vom Client ist vpn zu client, client zu vpn, vpn zu lokalem netz, lokales netz zu vpn erlaubt, müsste also auch klappen.

Einzig: Auf der Client Seite läuft bei mir ein multiISP Routing, könnte das ev. irgend wo Probleme machen?

 

[Woo]

Moin,


nur so als Idee, hast Du ipforwarding angeschaltet auf dem Router?

Genauere Untersuchung gerne per PM.

Gruß,


Woo.

 

[aargau]

Hi Woo

Ja, ipforwarding ist aktiviert, der Router NATet auch schön die netze hinter dem Router und auch ein Routing in ein anderes Netz auf der jeweiligen Router Seite (also ohne über openVPN zu gehen) läuft wunderbar und Problemlos.
Die Firewall habe ich soeben auch nochmals geprüft.
Auf Seite A ist es erlaubt von "local, fw" zu "vpn" zu connecten. Genau so von "vpn" zu "local, fw" hier habe ich ein komplettes ACCEPT in iptables, ohne irgend welche Netze die gefiltert werden oder so.

Ich kann auch vom Router b auf die Interne IP von Router a Pingen (also nicht die openVPN IP). Aber auf die andere Seite, also von Router a zu b geht es nur über die openVPN IP, nicht aber über die des Internen Netzwerks.

Ich komme aber von einem Client vom Router b dennoch nicht auf ein den router a. Es sieht für mich also so aus, dass irgend wie die Route auf dem a Router nicht korrekt gesetzt ist, auf B jedoch schon.

Interessanterweise kann ich aber z.B. von einem Client aus Router a auf den Router b zugreiffen, es fehlt also wohl einfach der korrekte weg ins Netzwerk vom router b, wodurch natürlich ein Paket nicht mehr zurück kommt, ich aber vom anderen Router problemlos auf die openVPN IP connecten kann, denn der router b weis ja wie er in das Lokale Netz kommt.


Router A (oVPN Server)
Lokales Netz: 10.20.10.0/24
Router IP "lokales Netz" 10.20.10.10/24


Router B:
Lokales Netz: 10.10.10.0/24
Router IP "lokales Netz 10.10.10.10/24

openVPN:
Router A 10.100.10.1 (p2p gemäss ifconfig 10.100.10.2, netzmaske 255.255.255.255 ??!!)
Router B 10.100.10.6 (p2p gemäss ifconfig 10.100.10.5, netzmaske 255.255.255.255 ??!!)

Routing Table Router A:

wgrouter:~# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         192.168.0.1     0.0.0.0         UG    204    0        0 eth0.10
[B]10.10.10.0      10.100.10.2     255.255.255.0   UG    1      0        0 tun0[/B]
10.20.10.0      *               255.255.255.0   U     0      0        0 eth0.2
10.20.20.0      *               255.255.255.0   U     0      0        0 eth0.3
10.20.30.0      *               255.255.255.0   U     0      0        0 eth0.4
10.100.10.0     10.100.10.2     255.255.255.0   UG    0      0        0 tun0
10.100.10.2     *               255.255.255.255 UH    0      0        0 tun0
192.168.0.0     *               255.255.255.0   U     0      0        0 eth0.10

Routing Table Router B:

corerouter:~# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         217-162-73-1.dy 0.0.0.0         UG    204    0        0 vlan10
default         192.168.1.100   0.0.0.0         UG    206    0        0 vlan20
10.10.10.0      *               255.255.255.0   U     0      0        0 vlan1
10.10.20.0      *               255.255.255.0   U     0      0        0 vlan2
[B]10.20.10.0      10.100.10.5     255.255.255.0   UG    1      0        0 tun0[/B]
10.100.10.1     10.100.10.5     255.255.255.255 UGH   0      0        0 tun0
10.100.10.5     *               255.255.255.255 UH    0      0        0 tun0
192.168.1.0     *               255.255.255.0   U     0      0        0 vlan20
217.162.73.0    *               255.255.255.0   U     0      0        0 vlan10

ein Traceroute führt jeweils ins leere, er versucht den Traffic nicht über den default GW zu jagen, von daher gehe ich davon aus, dass er schon versucht die Route umzusetzen.
Ich denke das Problem liegt eher bei der openVPN Config, werde mich jetzt da mal nochmals etwas schlau machen

 

[Woo]

Moin,


ja, Du hast ein Routing Problem.

bitte poste mal ein ifconfig von corerouter und wgrouter.
Wenn sich die routing tables geändert haben, die bitte auch nochmal.

Gruß,

Woo.

 

[Woo]

Hi,


Problem behoben oder abgebrochen?;-)?

Gruß,


Woo.

 

[aargau]

Hi Woo
Weder noch, aber bin im Moment im Umzugsstress und muss das Problem erstmal verschieben bis alles am neuen Wohnort eingerichtet ist.

Ich kann aber sagen das ein 2 Client Setup ausser dem Routing läuft...

Auf jeden Fall vielen Dank auch für die Rückfrage! Melde mich hier wieder wenn ich Luft habe

 

[aargau]

Hallo Woo und alle anderen ;-)

Ich hab es hingekriegt, habe nur von einem TUN interface zu einem TAP interface gewechselt. Das macht einiges einfacher, braucht halt etwas mehr traffic, dafür funktionieren die Routen nun ohne zu murren.
An was es wirklich gelegen hat, das es mit dem tun interface nicht geht kann ich mir nicht erklären, ich habe genau das selbe gemacht jetzt nur halt das interface geswitcht...