luciver1981
Goto Top

Openvpn Routing Problem

Hallo und guten Morgen,

ich habe ein Problem mit dem Routing von meinen Openvpn Site to Site.

Haupstandort:
Server Debian in VM
lokales Netzwerk 192.168.0.0/24

Server Config
server 10.10.10.0 255.255.255.0
port 55603
  proto udp
  dev tun
  client-to-client
  float
  ca /etc/openvpn/easy-rsa2/keys/ca.crt
  dh /etc/openvpn/easy-rsa2/keys/dh2048.pem
  cert /etc/openvpn/easy-rsa2/keys/VPN_SERVER.crt
  key /etc/openvpn/easy-rsa2/keys/VPN_SERVER.key
  tls-auth /etc/openvpn/easy-rsa2/keys/ta.key 0
#route 172.17.0.0 255.255.0.0
#push "route 10.10.10.0 255.255.255.0" 
push "route 192.168.0.0 255.255.255.0"  
  push "route 172.17.0.0 255.255.0.0"  
  log-append /etc/openvpn/openvpn2.log
  push "dhcp-option DNS 192.168.0.7"  
  cipher AES-256-CBC
  resolv-retry infinite
  persist-key
  persist-tun
  keepalive 10 120
  comp-lzo
  verb 3  
status openvpn-status.log

Aussenstelle
Pfsense
lokales Netzerk ziwschen Router und PFSense 192.168.2.0/24
lokales Netwerk für Clients (hinter Pfsense) 172.17.0.0/24

client
dev tun

proto udp
remote server 55603
resolv-retry infinite
nobind
persist-key
persist-tun
ca CA.crt
cert client.crt
key client.key
;ns-cert-type server
tls-auth ta.key 1 
cipher AES-256-CBC 
comp-lzo
verb 3
PFsense Config:
remote Netzwerk 192.168.0.0/24

Ich kann vom Client bis zur eth0 192.168.0.140 des Servers pingen aber nur diese Adresse, der Rest des Netzwerkes ist vom Client aus nicht erreichbar, jemand eine Idee?

Gruß Luciver

Content-ID: 288502

Url: https://administrator.de/contentid/288502

Ausgedruckt am: 22.11.2024 um 04:11 Uhr

djfflow
djfflow 16.11.2015 um 10:25:32 Uhr
Goto Top
Hallo,

sind denn am Hauptstandort die Routen für die Aussenstelle am Router eingetragen? Kennen also die Geräte am Hauptstandort die Route zur Aussenstelle?
Luciver1981
Luciver1981 16.11.2015 um 12:22:37 Uhr
Goto Top
Ja denke schon

1. Route 10.10.10.0/24 (Transfernetz) GW 192.168.0.140(VPN Server)
2. Route 172.17.0.0/24(LAN Aussenstelle)GW 192.168.0.140(VPN Server)
aqui
aqui 16.11.2015 um 12:27:58 Uhr
Goto Top
der Rest des Netzwerkes ist vom Client aus nicht erreichbar, jemand eine Idee?
Welches Default Gateway hat denn dieser "Rest" konfiguriert ??
Ist das evtl. ein Router im Netzwerk wo auch der Server steht. ? Wenn ja ist es dann klar, das es nicht klappt, denn die Clients kommen ja mit einer anderen Absender IP (192.168.0.0 /24) an diesen Geräten an.
Rückpakete gehen dann dirkt auf den Router der als Default Gateway dort konfiguriert ist und hat dieser keine spezifische Route eingetragen auf den OVPN Server, der ja Gateway in dieses Netz ist), dann gehen diese Pakete zum Provider und damit ins Nirwana !
Du musst also eine statische Route ins 192.168.0.0er Netz auf diesem Router eintragen, die als next Hop Gateway IP die lokale IP des OVPN Servers hat.
Traceroute oder Pathping ist hier wie immer dein bester Freund das zu troubleshooten !!!
Ist der OVPN Server und der Router ein und dasselbe Gerät also z.B. eine pfSense FW, dann hast du vermutlich falsche FW Regeln auf dem OVPN Virtual Interface installiert die den Zugriff blocken. Ping ist das ICMP protokoll, was du explizit freigeben musst um pingen zu können !
Weitere Details erklärt dir das hiesige Tutorial:
OpenVPN Server installieren auf pfSense Firewall, Mikrotik. DD-WRT oder GL.inet Router
Luciver1981
Luciver1981 16.11.2015 aktualisiert um 13:26:30 Uhr
Goto Top
Also der Standart Gateway für das Haupstandort Netz ist 192.168.0.250, dieses hat auch der eth0 Anschluss des OpenVPN Server, also ja es ist ein Router in dem Netzwerk in dem der Openvpn Server steht. Nein der Server ist ein anderes Gerät als der Router.
Wie ich soll in den Router eine Route eintragen für das 192.168.0.0er Netz? der Router ist doch für das Netzwerk zuständig?
Ich sehe den Weg wie folgt
LAN-Client 172.17.0.0 GW 172.17.1 -> Openvpn Tunnel 10.10.10.6 GW 10.10.10.1 ->10.10.10.1 GW 192.168.0.140(VPN SERVER) -> VPN Server GW eth0 192.168.0.140 GW 192.168.0.250

Oder denke ich da Falsch?
Luciver1981
Luciver1981 17.11.2015 um 09:13:33 Uhr
Goto Top
Hat einer eine Idee?
aqui
aqui 17.11.2015 aktualisiert um 09:34:32 Uhr
Goto Top
Also der Standart Gateway für das Haupstandort Netz ist 192.168.0.250, dieses hat auch der eth0 Anschluss des OpenVPN Server,
OK, damit hält der Server ja dann dein OpenVPN Netz 10.10.10.0 /24
Auf diesem zentralen Router mit der 192.168.0.250er IP müssen dann zwingend zwei statische Routen eingetragen sein:
  • Zielnetz: 172.17.0.0 Maske: 255.255.255.0 Gateway: <OVPN-Server IP eth0>
  • Zielnetz: 192.168.2.0 Maske: 255.255.255.0 Gateway: <OVPN-Server IP eth0>
Hast du diese Konfiguriert ??
Und.... hast du das virtuelle OVPN Interface der pfSense so konfiguriert das diese beiden IP Netze passieren dürfen ?
Nochmal nachgefragt:
lokales Netzerk ziwschen Router und PFSense 192.168.2.0/24
Das bedeutet das der Router VOR der pfSense zwingend ein Port Forwarding für UDP 1194 konfiguriert haben muss um die VPN Pakete über dessen NAT Firewall an die pfSense forzuwarden !
Ist das entsprechend konfiguriert ? Vermutlich aber wohl ja, da du ja selber schreibst das der Tunnel sauber aufgebaut wird und wenigstens die pfSensen sich untereinander pingen können.

Ein weiterer gravierender Fehler ist da noch !!!
Du schreibst oben:
lokales Netwerk für Clients (hinter Pfsense) 172.17.0.0/24
In der Server Konfig steht dann aber push "route 172.17.0.0 255.255.0.0" ??!!
2 gravierende Fehler hier:
  • Oben gibst du eine /24 Maske des Client Netzes an, das Push Kommando ist aber mit einer /16 Maske definiert ! Das kann so natürlich nicht funktionieren
  • Abgesehen davon ist noch viel schlimmer das das ja das IP Netz auf der Client Seite ist, wenn man deine Ausführungen oben richtig deutet. Du aber propagierst dieses IP Netz von der Server ! Seite, sagst also dem Client mit dem push route Kommando das das IP Netz auf Server Seite erreichbar ist.
Das führt natürlich zu einem fatalen Routing Problem, denn der der Client sieht das 172er Netz ja nun doppelt. Als lokales Netz und es wird ihm zusätzlich noch als Route über den VPN Tunnel bekannt gemacht.
Wenn, dann musst du mit dem ip route Kommando in der Client Konfig der Server Seite sagen das HIER das 172er Netz ist !!! So wird dann ein Schuh draus !
Das push route Kommando des 172er Netzes auf der Server Seite ist also grundlegend falsch und sollte zwingend entfernt werden und mit dem ip route Kommando auf der Client Seite ersetzt werden.
Sieh unter Diagnosis im pfSense Menü immer in die Routing Tabelle !!! Dort sollten die Zielnetze immer über die richtigen Interfaces anounced werden. Das kannst du da immer sauber prüfen !