nintox
Goto Top

DD-WRT Router als VPN-Server hinter FritzBox - Konfigurationsproblem

Hallo zusammen, ich würde gerne einen Open VPN-Server über einen Buffalo Router mit DD-WRT betreiben.
Der Router steht hinter einer FritzBox 7490. Auf der FritzBox ist ein Port-Forward auf 1194 eingerichtet.
FritzBox hat eine DNS-Server-Adresse.

Die Easy-RSA-Konfiguration hab ich für beide Seiten (Client und Server) schon durchgeführt.
Server-Zertifikate sind im VPN-Router auch eingetragen
Client hat als remote die DNS Server-Adresse der FritzBox eingetragen

Leider funktioniert bzw. stimmt meine VPN-Konfiguration wahrscheinlich im Router nur noch nicht so ganz, das der Server nicht starten will.
Screenshot

Tendiere, dass die Push-Settings nicht ganz passen. Was müsste ich da eure Meinung eintragen, wenn der VPN-Server hinter einer FritzBox sitzt.
Bzw. was müsste noch an der FritzBox gecheckt werden, was ich noch nicht erwähnt hab?
screencapture-192-168-11-1-pptp-asp-1480852563977

Content-Key: 322887

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

Ausgedruckt am: 19.03.2024 um 03:03 Uhr

Mitglied: ashnod
ashnod 04.12.2016 um 15:45:57 Uhr
Goto Top
Zitat von @Nintox:
Client hat als remote die DNS Server-Adresse der FritzBox eingetragen

Ahoi ...

Wie meinen?

VG
Ashnod
Mitglied: Nintox
Nintox 04.12.2016 um 17:04:14 Uhr
Goto Top
Naja... der VPN Client hat in der Konfig die DNS-Server-Adresse der FritzBox eingetragen. Weil die Fritzbox ist ja der direkte Router zum WAN und den VPN-Router kennt der Client ja nicht.
Mitglied: 108012
108012 04.12.2016 um 18:26:05 Uhr
Goto Top
Hallo,

hast Du bei der AVM FB auch das VPN deaktiviert?
Sonst denkt die AVM FB jedes mal dass das VPN für sie ist und nimmt es selber an!

Gruß
Dobby
Mitglied: Nintox
Nintox 04.12.2016 um 18:39:34 Uhr
Goto Top
Wenn ich da keine VPN-Verbindung eintrage, ist es doch gleichgestellt wie deaktiviert oder?
Mitglied: 108012
108012 04.12.2016 um 18:46:03 Uhr
Goto Top
Wenn ich da keine VPN-Verbindung eintrage, ist es doch gleichgestellt wie deaktiviert oder?
Nein denn dann denkt die AVM FB immer wieder dass die VPN Verbindung für sie selber ist
und versucht sie anzunehmen und von daher kommt wohl auch nichts am VPN Server an!

Gruß
Dobby
Mitglied: orcape
orcape 04.12.2016 um 18:55:56 Uhr
Goto Top
Hi,
und wieso lässt Du das Feld für das "server.crt" frei?
Zumindest ist das so im Bild ersichtlich.
Gruß orcape
Mitglied: orcape
orcape 04.12.2016 um 19:03:34 Uhr
Goto Top
@108012,
Seit wann macht die Fritte per default denn OpenVPN? Ein Portforwarding auf den OpenVPN-Port sollte ausreichen. Hier scheint wohl etwas mehr nicht zu stimmen, denn die TLS-Auth wurde auch "eingespart".face-wink
Gruß orcape
Mitglied: Nintox
Nintox 04.12.2016 um 19:48:13 Uhr
Goto Top
Da ich ja kein IPSec tunnel, müsste das doch wie du schreibst, direkt mit einem Port-Forward 1194 zum Buffalo funktionieren.
Vielleicht hilft es noch weiter:
Wenn ich den Client starte und eine Verbindung aufbauen möchte, steht Management Waiting.... in der untersten Zeile.
Mitglied: aqui
aqui 04.12.2016 um 23:15:27 Uhr
Goto Top
Wenn denn ja das Port Forwarding UDP 1194 im Buffalo Router auf den DD-WRT konfigurieren !
Der DD-WRT agiert hier ja als OVPN Server wenn man den TO richtig versteht.
Das hiesige Tutorial erklärt es en Detail wie es geht:
OpenVPN Server installieren auf pfSense Firewall, Mikrotik. DD-WRT oder GL.inet Router
Bzw. hier genau WIE der Router in einer Routerkaskade betrieben wird mit Port Forwarding:
OpenVPN Server installieren auf pfSense Firewall, Mikrotik. DD-WRT oder GL.inet Router
Damit sollte es sofort zum Fliegen kommen....
Mitglied: 108012
108012 05.12.2016 um 02:53:43 Uhr
Goto Top
Hallo nochmal,

Da ich ja kein IPSec tunnel,........
Ok den habe ich eben überlesen!

Gruß
Dobby
Mitglied: Nintox
Nintox 10.12.2016 um 14:18:33 Uhr
Goto Top
@aqui Möchte mal wirklich ein herzliches Dankeschön an dich aussprechen.
Bis jetzt warst du in meinen Problem-Threads immer zur Stelle und konntest mir auch bei diesem Problem mit deinem ausführlichen - und denke ich zeitaufwändigen - Guide wieder mal weiterhelfen.

Client verbindet sich mit Server.
Jetzt hätte ich noch eine Erweiterung an diese Sache.
Das Setup soll nachher hinter einem Hybrid-Router der Telekom laufen. Das heißt:
Hybrid-Router verbindet Business-Netz und dahinter soll ein VPN-Client (Buffalo Router). Zuhause soll dann ein weiterer Buffalo Router, der den VPN-Server einnimmt.
Ein Kollege meinte vor kurzem, diese umgestellte, untypische Variante würde das VPN-Problem der Telekom Hybrid-Router umgehen. (wird ja leider keine WAN-Adresse den Kunden bekanntgegeben. Zumindest nicht ohne Kostenaufwand.)
Ich mach somit ein 1194 forwarding im Hybrid und pack meine sicheren Client-Schlüssel in den Client-Router. Der Rest wäre ja somit erledigt oder hab ich was vergessen?

Was meint ihr, klappt das? Bzw. was wäre noch zu beachten?
Mitglied: aqui
aqui 10.12.2016 um 20:51:06 Uhr
Goto Top
Ja, das klappt so und du hast nichts vergessen.
Mitglied: orcape
orcape 11.12.2016 um 14:08:58 Uhr
Goto Top
Ich mach somit ein 1194 forwarding im Hybrid und pack meine sicheren Client-Schlüssel in den Client-Router.
Für den OpenVPN-Client brauchst Du noch nicht mal ein Portforwarding 1194. Das wäre nur beim OpenVPN-Server notwendig. Der OpenVPN-Client findet an Hand seiner "client.cfg" per fester IP oder DynDNS sein Ziel im Internet.
Gruß orcape
Mitglied: Nintox
Nintox 22.12.2016 um 19:56:13 Uhr
Goto Top
Ich muss mich nochmals melden. Irgendwie haut das mit der Konfig noch nicht soo ganz hin.
Nochmals zum Verständnis: ich teste aktuell noch mit Windows Client und weiterhin mit dem DD-WRT Router als VPN-Server hinter der FritzBox.
Verbindung zum VPN-Server kann ausgehandelt werden. Aber alles danach funktioniert nicht so ganz.
Würde gerne den ganzen Traffic durch den Tunnel schicken. Also mit einem "redirect gateway". Bin mir aber nicht so ganz sicher was ich wirklich in die Konfigs schreiben muss, dass es klappt.

Hier mal die Client-Config:

client
dev def1
proto udp
remote dns-server name 1194
resolv-retry infinite
nobind
persist-key
persist-tun
ca pfad/ca.crt
cert pfadclient1.crt
key pfad/client1.key
ns-cert-type server
comp-lzo
verb 3

Server Config:
port 1194
proto udp
dev def1
ca pfad/ca.crt
cert pfad/cert.pem
key pfad
key.pem
dh pfad/dh.pem
server IP-Adresse des VPN-Netzes 255.255.255.0
push "redirect-gateway def1"
push "dhcp-option DNS 208.67.222.222"
keepalive 10 120
comp-lzo
persist-key
persist-tun
verb 3
management localhost 14


Server Firewall:

iptables -t nat -A POSTROUTING -o eth0 -s 192.168.11.0/24 -j SNAT --to 192.168.178.4
iptables -I FORWARD 1 --source 192.168.11.0/24 -j ACCEPT

iptables -I INPUT 1 -p udp --dport 1194 -j ACCEPT
iptables -I INPUT 3 -i tun0 -j ACCEPT
iptables -I FORWARD 3 -i tun0 -o tun0 -j ACCEPT

Hab jetzt gelesen dass man in der FritzBox neben dem PortForward auch ne Route an das VPN-Netz und das Netz hinter dem VPN-Server zu machen.
Jedoch glaub ich, dass es aktuell nur noch Einstellungssache am VPN-Server ist.
Mitglied: orcape
orcape 23.12.2016 um 16:18:19 Uhr
Goto Top
Hi,
in die server.conf sollte noch ein push "route 192.168.11.0 255.255.255.0", damit der Client weiss, wo er Dein LAN zu suchen hat.
Gruß orcape
Mitglied: Nintox
Nintox 23.01.2017 aktualisiert um 20:47:38 Uhr
Goto Top
Danke für den Tipp, das war es.

Hab den Client nun hinter dem Hybrid (Office) und zuhause den (Server) hinter der Fritze am laufen.
Handshake funktioniert auch.
Nur komm ich via VPN noch nichts vor den Hybrid. Alles dahinter lässt sich über den DDWRT-Router (VPN-Client) anpingen.
WAN ist leider unmöglich.
An was kann das noch liegen?
Firewall-Settings am Client oder Server?

Wenn ihr noch Infos, Screenshots bräuchtet, sagt einfach bescheid. Wäre echt super, wenn ich das Ding zum laufen bekomme.
Mitglied: orcape
orcape 24.01.2017 um 06:49:04 Uhr
Goto Top
Hi,
WAN ist leider unmöglich.
Dazu benötigst Du, wenn das machbar ist, eine NAT-Regel auf dem Hybrid.
Sonst wird der Tunnel als "Fremdnetz" geblockt.
Interface WAN - Source LAN (Netz hinter dem OpenVPN-Server) - NAT-Adress WAN(Hybrid)
Gruß orcape
Mitglied: Nintox
Nintox 24.01.2017 um 09:07:55 Uhr
Goto Top
Beziehst du dich jetzt auf den Server oder den Client?
Weil hinter dem Hybrid steht der Client.

Da die tolle Hybrid-Büchse so gut wie keine Möglichkeiten zum Konfigurieren zulässt, sind mir da was NAT-Rules angeht, auch die Hände gebunden.
Einzige was geht, is Port Forwarding auf VPN-Port. Bei einem Client aber theoretisch nicht notwendig.

Sollte eben nachher ja so sein, dass der Client anstatt dem Server im Office fungiert und man vom Server aus bzw. Home auf das Firmennetzwerk (Office) zugreifen kann.
Mitglied: aqui
aqui 24.01.2017 aktualisiert um 09:41:19 Uhr
Goto Top
Da die tolle Hybrid-Büchse so gut wie keine Möglichkeiten zum Konfigurieren zulässt, sind mir da was NAT-Rules angeht, auch die Hände gebunden.
Warum beschaffst du dir dann nicht einen sinnvollen Dual WAN Balancing Router oder ne pfSense, damit hättest du diese Grundproblematik gar nicht erst.
https://www.heise.de/ct/ausgabe/2016-24-pfSense-als-Load-Balancer-345834 ...
Mitglied: Nintox
Nintox 24.01.2017 um 10:11:45 Uhr
Goto Top
Naja.... ich hab ja weiter oben gefragt:

Ein Kollege meinte vor kurzem, diese umgestellte, untypische Variante würde das VPN-Problem der Telekom Hybrid-Router umgehen. (wird ja leider keine WAN-Adresse den Kunden bekanntgegeben. Zumindest nicht ohne Kostenaufwand.)
Ich mach somit ein 1194 forwarding im Hybrid und pack meine sicheren Client-Schlüssel in den Client-Router. Der Rest wäre ja somit erledigt oder hab ich was vergessen?

Und da hieß es, das geht?
Ist denn da eine Möglichkeit noch da, mit dem DDWRT-Router hinter dem Hybrid ne Verbindung aufzubauen?


Du meinst mit einer pfSense:

Speedport-Hybrid --> pfSense (VPN-Client) --> Switch Whatever --> Hosts
Mitglied: orcape
orcape 24.01.2017 um 16:27:39 Uhr
Goto Top
Hi nintox,
Beziehst du dich jetzt auf den Server oder den Client?
Du hattest vom Hybrid gesprochen und das ist doch Client, oder etwa nicht?
Nimm ein ALIX-Board, wenn das Deinen Ansprüchen genügt, (preiswerter wie APU) "schraube" da eine pfSense drauf und folge @aqui 's Tutorial hier im Forum.
Speedport-Hybrid --> pfSense (VPN-Client) --> Switch Whatever --> Hosts
Genau so.
Auf der pfSense terminierst Du den OpenVPN-Client und erstellst die NAT-Regel und schon greifst Du auf den Speedport zu.
Gruß orcape
Mitglied: Nintox
Nintox 24.01.2017 aktualisiert um 17:06:23 Uhr
Goto Top
Danke für die Alternative.
So ganz steig ich aber immer noch nicht durch...
Was ist der Unterschied zwischen einem VPN-Client auf dem DD-WRT und einem VPN-Client auf einer pfSense. Außer das es eine Firewall ist und direkt im Netzwerk hängt und kein eigenes dahinter macht.

Anders gefragt, wäre es möglich den DDWRT Router als LAN-Switch laufen zu lassen. Somit wäre er eben nur ein VPN-Client hinter dem Hybrid.
Ich versuch eben aktuell noch irgendwie mit der Hardware die ich schon habe, das hinzubekommen. Kann man ja bestimmt verstehen.
Mitglied: orcape
orcape 24.01.2017 um 17:51:59 Uhr
Goto Top
Was ist der Unterschied zwischen einem VPN-Client auf dem DD-WRT und einem VPN-Client auf einer pfSense.
Man sollte auf dem DD-WRT eigentlich auch eine NAT-Regel erstellen können, unter Administration. Ansonsten hat die pfSense wesentlich mehr Funktionen.
Wenn sich @aqui nicht noch einmal meldet, schick Ihm eine PN, der hat da mehr Ahnung, wie und ob das auf DD-WRT zu realisieren ist.
Gruss orcape
Mitglied: Nintox
Nintox 24.01.2017 um 18:33:29 Uhr
Goto Top
Ich danke dir schon mal. Mach ich!
Mitglied: aqui
aqui 27.01.2017 um 09:43:44 Uhr
Goto Top
Was ist der Unterschied zwischen einem VPN-Client auf dem DD-WRT und einem VPN-Client auf einer pfSense.
Da ist natürlich kein Unterschied ist ja technisch vollkommen das gleiche.
Der Vorschlag bezpg sich auf den Ersatz des Hybrid Routers, also das man das die pfSense direkt machen lässt. Ein Port direkt ans DSL und den anderen ans LTE.

Letztlich ist das ja ein simples Standard Szenario. der TO schreibt ja jetzt:
er baut auch eine Verbindung zum Server auf (Handshake), aber überträgt keine Daten
D.h. um nochmal die Fakten zu beschreiben:
Der kaskadierte DD-WRT Router ist VPN Client und NICHT VPN Server ?! Ist das so richtig ?
D.h. ER baut die OVPN Verbindung zu irgendeinem Server remote auf. Stimmt das so ?
Dann ist die Sache ja noch viel einfacher und sollte in jedem Falle klappen.
Du sagst der DD-WRT als Client baut die Verbindung auf.
  • Kannst du das mit einem Log Auszug belegen ??
  • Hast du das Tutorial dazu gelesen: OpenVPN Server installieren auf pfSense Firewall, Mikrotik. DD-WRT oder GL.inet Router und den Client mal so manuell gestartet ?? Was sagt dann der CLI Output ?? Bekommst du da auch ein Initialization Sequence Completed
  • Du solltest bitte hier nochmal genau diese Outputs des Clients hier posten. Ebenso wichtig ist ein ifconfig bei aktivem Client um zu sehen das das virtuelle Tunnel Interface zum Server wirklich aktiv ist.
  • Ein Ping auf die virtuelle Server IP, also die, die du in der Server Konfig Datei mit server 172.16.2.0 255.255.255.0 definiert hast ! Hier im Beispiel hat der Server die 172.16.2.1. Dieser Ping MUSS immer möglich sein !
Wenn das klappt dann steht auch der Tunnel und der Rest ist dann ein sehr einfaches Routing Problem was mit einer simplen statischen Route zu lösen ist.
All diese Outputs und Infos hat der TO bis hierher noch NICHT geliefert. Wir müssten sie für eine zielgerichtete Hilfe aber wissen !!
Mitglied: Nintox
Nintox 27.01.2017, aktualisiert am 14.03.2023 um 10:59:45 Uhr
Goto Top
Danke, dass du dich dem nochmals annimmst.


Der kaskadierte DD-WRT Router ist VPN Client und NICHT VPN Server ?! Ist das so richtig ?

Richtig, ist ein VPN-Client hinter dem Hybrid-Router am Firmenstandort.

D.h. ER baut die OVPN Verbindung zu irgendeinem Server remote auf. Stimmt das so ?

Genau, korrekt.

Du sagst der DD-WRT als Client baut die Verbindung auf.
Kannst du das mit einem Log Auszug belegen ??

Kann ich machen, müsste heute Abend nochmals vor Ort und die Daten kurz auslesen. Poste sie dann direkt hier rein.

Hast du das Tutorial dazu gelesen: OpenVPN Server installieren auf pfSense Firewall, Mikrotik. DD-WRT oder GL.inet Routerund den Client mal so manuell gestartet ?? Was sagt dann der CLI Output ??

Manuell hab ich den Client jetzt noch nicht gestartet, weil er im DD-WRT Webpanel jedes mal auch richtig gestartet hat und auf dem Server auch als Client aufschlägt.


Bekommst du da auch ein Initialization Sequence Completed?

Ja, bekomme ich.


Du solltest bitte hier nochmal genau diese Outputs des Clients hier posten. Ebenso wichtig ist ein ifconfig bei aktivem Client um zu sehen das das virtuelle Tunnel Interface zum Server wirklich aktiv ist.

Mach ich.

Ein Ping auf die virtuelle Server IP, also die, die du in der Server Konfig Datei mit server 172.16.2.0 255.255.255.0 definiert hast ! Hier im Beispiel hat der Server die 172.16.2.1. Dieser Ping MUSS immer möglich sein !

Ping auf Server im Tunnel-Netz geht leider nicht. Aktuell nur Ping bis Hybrid-Router möglich.

Wenn das klappt dann steht auch der Tunnel und der Rest ist dann ein sehr einfaches Routing Problem was mit einer simplen statischen Route zu lösen ist.

Statische Routen kann ich im Hybrid leider schwer setzen. Außer eben über ein Port Forward zu einem Ziel-Client (In dem Fall der VPN-Client)
Mitglied: aqui
aqui 27.01.2017 um 14:39:41 Uhr
Goto Top
weil er im DD-WRT Webpanel jedes mal auch richtig gestartet hat und auf dem Server auch als Client aufschlägt.
OK, es würde auch das Server Log reichen was eindutig dann anzeigen sollte das der Tunnel aktiv ist ohne Fehler.

Wenn direkt vom VPN Client kein Ping auf die interen OVPN Server IP möglich ist dann ist :
  • entweder der Tunnel nicht aufgebaut
  • oder irgendwo noch ne Firewall aktiv
Wichtig ist das du hier auf dem DD-WRT einmal den Telnet oder SSH Zugang aktivierst und dich mit PuTTY aml einloggst auf dem CLI.
Hier wäre jetzt ein ifconfig Output bei aktivem VPN mal sehr hilfreich um zu sehen ob das virtuelle Tunnel Interface aufgebaut ist und es vom OVPN Server eine korrekte IP Adresse bekommen hat.
Dann mal außer ifconfig mal ein netstat -r ziehen um die Routing Tabelle zu sehen.
Sollte das alles passen MUSS ein direkter Ping vom CLI des DD-WRT auf die Server VPN IP klappen.

Ob du statische Routen brauchst oder nicht hängt einzig und allein davon ab WIE deine Infrastruktur aussieht.
Betreibst du das DD-WRT VPN in einer Kaskade mit dem Hybridrouter ist das kein Thema.
Betreibst du es aber "one armed" also nur einbeinig angeschlossen sind statische Routen zwingend.
Das muss dann nicht unbedinbt auf dem Hybrid Router sein. Wenn er es nicht supportet, dann musst du es auf deinem Client direkt machen.
Bei einem Winblows Client geht das dann so:
route add <vpn_zielnetz> mask <maske_ziel> <gateway_ip_dd-wrt> -p
Dann routet der Client gleich diese Pakete direkt an das VPN Client Gateway statt an den Hybrid Router.
Bei Winblows zeigt dann ein route print die lokale Routing Tabelle an.
Mitglied: Nintox
Nintox 27.01.2017 um 18:17:11 Uhr
Goto Top
if_config:

ba0       Link encap:Ethernet  HWaddr CC:E1:D5:DF:08:E4
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
          Interrupt:4

br0       Link encap:Ethernet  HWaddr CC:E1:D5:DF:08:E0
          inet addr:192.168.11.1  Bcast:192.168.11.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:6908 errors:0 dropped:442 overruns:0 frame:0
          TX packets:8953 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:1193963 (1.1 MiB)  TX bytes:9274245 (8.8 MiB)

br0:0     Link encap:Ethernet  HWaddr CC:E1:D5:DF:08:E0
          inet addr:169.254.255.1  Bcast:169.254.255.255  Mask:255.255.0.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

eth0      Link encap:Ethernet  HWaddr CC:E1:D5:DF:08:E0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:85862 errors:0 dropped:0 overruns:0 frame:0
          TX packets:54583 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:18375888 (17.5 MiB)  TX bytes:52598230 (50.1 MiB)
          Interrupt:5

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING MULTICAST  MTU:65536  Metric:1
          RX packets:1536 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1536 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:203165 (198.4 KiB)  TX bytes:203165 (198.4 KiB)

ra0       Link encap:Ethernet  HWaddr CC:E1:D5:DF:08:E0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
          Interrupt:6

tun1      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          inet addr:172.16.3.6  P-t-P:172.16.3.5  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1400  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:14 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:0 (0.0 B)  TX bytes:1176 (1.1 KiB)

vlan1     Link encap:Ethernet  HWaddr CC:E1:D5:DF:08:E0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:6929 errors:0 dropped:7 overruns:0 frame:0
          TX packets:8949 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:1196314 (1.1 MiB)  TX bytes:9272170 (8.8 MiB)

vlan2     Link encap:Ethernet  HWaddr CC:E1:D5:DF:08:E1
          inet addr:192.168.2.50  Bcast:192.168.2.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:78784 errors:0 dropped:20478 overruns:0 frame:0
          TX packets:35211 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:15628054 (14.9 MiB)  TX bytes:42518473 (40.5 MiB)


netstat -r :

Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
default               172.16.3.5      128.0.0.0       UG        0 0          0 tun1
default               speedport.ip    0.0.0.0         UG        0 0          0 vlan2
127.0.0.0                    *               255.0.0.0       U         0 0          0 lo
128.0.0.0          172.16.3.5      128.0.0.0       UG        0 0          0 tun1
169.254.0.0              *               255.255.0.0     U         0 0          0 br0
172.16.3.0        172.16.3.5      255.255.255.0   UG        0 0          0 tun1
172.16.3.1        172.16.3.5      255.255.255.255 UGH       0 0          0 tun1
172.16.3.5         *               255.255.255.255 UH        0 0          0 tun1
178.5.204.106   speedport.ip    255.255.255.255 UGH       0 0          0 vlan2
192.168.2.0       *               255.255.255.0   U         0 0          0 vlan2
192.168.11.0     *               255.255.255.0   U         0 0          0 br0
192.168.12.0    172.16.3.5      255.255.255.0   UG        0 0          0 tun1

Mitschnitt aus dem Syslog über SSH:

Jan 27 17:54:33 Frank Motorgeraete 2 daemon.notice openvpn[3805]: /sbin/route del -net 128.0.0.0 netmask 128.0.0.0
Jan 27 17:54:33 Frank Motorgeraete 2 daemon.notice openvpn[3805]: Closing TUN/TAP interface
Jan 27 17:54:33 Frank Motorgeraete 2 daemon.notice openvpn[3805]: /sbin/ifconfig tun1 0.0.0.0
Jan 27 17:54:33 Frank Motorgeraete 2 daemon.notice openvpn[3805]: SIGTERM[hard,] received, process exiting
Jan 27 17:54:33 Frank Motorgeraete 2 daemon.notice openvpn[3040]: OpenVPN 2.3.12 mipsel-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [MH] [IPv6] built on Nov 14 2016
Jan 27 17:54:33 Frank Motorgeraete 2 daemon.notice openvpn[3040]: library versions: OpenSSL 1.0.2j  26 Sep 2016, LZO 2.09
Jan 27 17:54:33 Frank Motorgeraete 2 daemon.notice openvpn[3041]: MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:16
Jan 27 17:54:33 Frank Motorgeraete 2 daemon.warn openvpn[3041]: WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.
Jan 27 17:54:33 Frank Motorgeraete 2 daemon.warn openvpn[3041]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Jan 27 17:54:33 Frank Motorgeraete 2 daemon.warn openvpn[3041]: WARNING: file '/tmp/openvpncl/client.key' is group or others accessible  
Jan 27 17:54:33 Frank Motorgeraete 2 daemon.warn openvpn[3041]: WARNING: normally if you use --mssfix and/or --fragment, you should also set --tun-mtu 1500 (currently it is 1400)
Jan 27 17:54:33 Frank Motorgeraete 2 daemon.notice openvpn[3041]: Socket Buffers: R=[172032->172032] S=[172032->172032]
Jan 27 17:54:33 Frank Motorgeraete 2 daemon.notice openvpn[3041]: UDPv4 link local: [undef]
Jan 27 17:54:33 Frank Motorgeraete 2 daemon.notice openvpn[3041]: UDPv4 link remote: [AF_INET]178.5.204.106:1194
Jan 27 17:54:33 Frank Motorgeraete 2 daemon.notice openvpn[3041]: TLS: Initial packet from [AF_INET]178.5.204.106:1194, sid=eb0d0aeb 12c126d8
Jan 27 17:54:33 Frank Motorgeraete 2 daemon.notice openvpn[3041]: VERIFY OK: depth=1, C=DE, ST=BAWUE, L=REMSHALDEN, O=FRANK, OU=ADMIN_CA, CN=changeme, name=changeme, emailAddress=info@frank-motorgeraete.de
Jan 27 17:54:33 Frank Motorgeraete 2 daemon.notice openvpn[3041]: VERIFY OK: depth=0, C=DE, ST=BAWUE, L=REMSHALDEN, O=FRANK, OU=ADMIN, CN=server, name=changeme, emailAddress=info@frank-motorgerate.de
Jan 27 17:54:34 Frank Motorgeraete 2 daemon.warn openvpn[3041]: WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1442', remote='link-mtu 1441'  
Jan 27 17:54:34 Frank Motorgeraete 2 daemon.warn openvpn[3041]: WARNING: 'comp-lzo' is present in local config but missing in remote config, local='comp-lzo'  
Jan 27 17:54:34 Frank Motorgeraete 2 daemon.notice openvpn[3041]: Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key  
Jan 27 17:54:34 Frank Motorgeraete 2 daemon.warn openvpn[3041]: WARNING: this cipher's block size is less than 128 bit (64 bit).  Consider using a --cipher with a larger block size.  
Jan 27 17:54:34 Frank Motorgeraete 2 daemon.notice openvpn[3041]: Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication  
Jan 27 17:54:34 Frank Motorgeraete 2 daemon.notice openvpn[3041]: Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key  
Jan 27 17:54:34 Frank Motorgeraete 2 daemon.warn openvpn[3041]: WARNING: this cipher's block size is less than 128 bit (64 bit).  Consider using a --cipher with a larger block size.  
Jan 27 17:54:34 Frank Motorgeraete 2 daemon.notice openvpn[3041]: Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication  
Jan 27 17:54:34 Frank Motorgeraete 2 daemon.notice openvpn[3041]: Control Channel: TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
Jan 27 17:54:34 Frank Motorgeraete 2 daemon.notice openvpn[3041]: [server] Peer Connection Initiated with [AF_INET]178.5.204.106:1194
Jan 27 17:54:36 Frank Motorgeraete 2 daemon.notice openvpn[3041]: SENT CONTROL [server]: 'PUSH_REQUEST' (status=1)  
Jan 27 17:54:36 Frank Motorgeraete 2 daemon.notice openvpn[3041]: PUSH: Received control message: 'PUSH_REPLY,redirect-gateway def1,route 192.168.12.0 255.255.255.0,route 172.16.3.0 255.255.255.0,dhcp-option DNS 8.8.8.8,dhcp-option DNS 8.8.4.4,route 172.16.3.1,topology net30,ifconfig 1  
Jan 27 17:54:36 Frank Motorgeraete 2 daemon.notice openvpn[3041]: OPTIONS IMPORT: --ifconfig/up options modified
Jan 27 17:54:36 Frank Motorgeraete 2 daemon.notice openvpn[3041]: NOTE: --mute triggered...
Jan 27 17:54:36 Frank Motorgeraete 2 daemon.notice openvpn[3041]: 2 variation(s) on previous 3 message(s) suppressed by --mute
Jan 27 17:54:36 Frank Motorgeraete 2 daemon.notice openvpn[3041]: TUN/TAP device tun1 opened
Jan 27 17:54:36 Frank Motorgeraete 2 daemon.notice openvpn[3041]: TUN/TAP TX queue length set to 100
Jan 27 17:54:36 Frank Motorgeraete 2 daemon.notice openvpn[3041]: do_ifconfig, tt->ipv6=1, tt->did_ifconfig_ipv6_setup=0
Jan 27 17:54:36 Frank Motorgeraete 2 daemon.notice openvpn[3041]: /sbin/ifconfig tun1 172.16.3.6 pointopoint 172.16.3.5 mtu 1400
Jan 27 17:54:36 Frank Motorgeraete 2 daemon.notice openvpn[3041]: /sbin/route add -net 178.5.204.106 netmask 255.255.255.255 gw 192.168.2.1
Jan 27 17:54:36 Frank Motorgeraete 2 daemon.notice openvpn[3041]: /sbin/route add -net 0.0.0.0 netmask 128.0.0.0 gw 172.16.3.5
Jan 27 17:54:36 Frank Motorgeraete 2 daemon.notice openvpn[3041]: /sbin/route add -net 128.0.0.0 netmask 128.0.0.0 gw 172.16.3.5
Jan 27 17:54:36 Frank Motorgeraete 2 daemon.notice openvpn[3041]: /sbin/route add -net 192.168.12.0 netmask 255.255.255.0 gw 172.16.3.5
Jan 27 17:54:36 Frank Motorgeraete 2 daemon.notice openvpn[3041]: /sbin/route add -net 172.16.3.0 netmask 255.255.255.0 gw 172.16.3.5
Jan 27 17:54:36 Frank Motorgeraete 2 daemon.notice openvpn[3041]: /sbin/route add -net 172.16.3.1 netmask 255.255.255.255 gw 172.16.3.5
Jan 27 17:54:36 Frank Motorgeraete 2 daemon.notice openvpn[3041]: Initialization Sequence Completed
Jan 27 17:55:20 Frank Motorgeraete 2 authpriv.notice dropbear[3070]: Password auth succeeded for 'root' from 192.168.2.106:53715  
Jan 27 17:56:36 Frank Motorgeraete 2 daemon.notice openvpn[3041]: [server] Inactivity timeout (--ping-restart), restarting
Jan 27 17:56:36 Frank Motorgeraete 2 daemon.notice openvpn[3041]: SIGUSR1[soft,ping-restart] received, process restarting
Jan 27 17:56:36 Frank Motorgeraete 2 daemon.notice openvpn[3041]: Restart pause, 2 second(s)
Jan 27 17:56:39 Frank Motorgeraete 2 daemon.warn openvpn[3041]: WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.
Jan 27 17:56:39 Frank Motorgeraete 2 daemon.warn openvpn[3041]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Jan 27 17:56:39 Frank Motorgeraete 2 daemon.warn openvpn[3041]: WARNING: normally if you use --mssfix and/or --fragment, you should also set --tun-mtu 1500 (currently it is 1400)
Jan 27 17:56:39 Frank Motorgeraete 2 daemon.notice openvpn[3041]: Socket Buffers: R=[172032->172032] S=[172032->172032]
Jan 27 17:56:39 Frank Motorgeraete 2 daemon.notice openvpn[3041]: UDPv4 link local: [undef]
Jan 27 17:56:39 Frank Motorgeraete 2 daemon.notice openvpn[3041]: UDPv4 link remote: [AF_INET]178.5.204.106:1194
Jan 27 17:56:39 Frank Motorgeraete 2 daemon.notice openvpn[3041]: TLS: Initial packet from [AF_INET]178.5.204.106:1194, sid=f3dc945e 7ee55dbf
Jan 27 17:56:39 Frank Motorgeraete 2 daemon.notice openvpn[3041]: VERIFY OK: depth=1, C=DE, ST=BAWUE, L=REMSHALDEN, O=FRANK, OU=ADMIN_CA, CN=changeme, name=changeme, emailAddress=info@frank-motorgeraete.de
Jan 27 17:56:39 Frank Motorgeraete 2 daemon.notice openvpn[3041]: VERIFY OK: depth=0, C=DE, ST=BAWUE, L=REMSHALDEN, O=FRANK, OU=ADMIN, CN=server, name=changeme, emailAddress=info@frank-motorgerate.de
Jan 27 17:56:41 Frank Motorgeraete 2 daemon.warn openvpn[3041]: WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1442', remote='link-mtu 1441'  
Jan 27 17:56:41 Frank Motorgeraete 2 daemon.warn openvpn[3041]: WARNING: 'comp-lzo' is present in local config but missing in remote config, local='comp-lzo'  
Jan 27 17:56:41 Frank Motorgeraete 2 daemon.notice openvpn[3041]: Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key  
Jan 27 17:56:41 Frank Motorgeraete 2 daemon.warn openvpn[3041]: WARNING: this cipher's block size is less than 128 bit (64 bit).  Consider using a --cipher with a larger block size.  
Jan 27 17:56:41 Frank Motorgeraete 2 daemon.notice openvpn[3041]: Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication  
Jan 27 17:56:41 Frank Motorgeraete 2 daemon.notice openvpn[3041]: Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key  
Jan 27 17:56:41 Frank Motorgeraete 2 daemon.warn openvpn[3041]: WARNING: this cipher's block size is less than 128 bit (64 bit).  Consider using a --cipher with a larger block size.  
Jan 27 17:56:41 Frank Motorgeraete 2 daemon.notice openvpn[3041]: Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication  
Jan 27 17:56:41 Frank Motorgeraete 2 daemon.notice openvpn[3041]: Control Channel: TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
Jan 27 17:56:41 Frank Motorgeraete 2 daemon.notice openvpn[3041]: [server] Peer Connection Initiated with [AF_INET]178.5.204.106:1194
Jan 27 17:56:44 Frank Motorgeraete 2 daemon.notice openvpn[3041]: SENT CONTROL [server]: 'PUSH_REQUEST' (status=1)  
Jan 27 17:56:44 Frank Motorgeraete 2 daemon.notice openvpn[3041]: PUSH: Received control message: 'PUSH_REPLY,redirect-gateway def1,route 192.168.12.0 255.255.255.0,route 172.16.3.0 255.255.255.0,dhcp-option DNS 8.8.8.8,dhcp-option DNS 8.8.4.4,route 172.16.3.1,topology net30,ifconfig 1  
Jan 27 17:56:44 Frank Motorgeraete 2 daemon.notice openvpn[3041]: OPTIONS IMPORT: --ifconfig/up options modified
Jan 27 17:56:44 Frank Motorgeraete 2 daemon.notice openvpn[3041]: NOTE: --mute triggered...
Jan 27 17:56:44 Frank Motorgeraete 2 daemon.notice openvpn[3041]: 2 variation(s) on previous 3 message(s) suppressed by --mute
Jan 27 17:56:44 Frank Motorgeraete 2 daemon.notice openvpn[3041]: Preserving previous TUN/TAP instance: tun1
Jan 27 17:56:44 Frank Motorgeraete 2 daemon.notice openvpn[3041]: Initialization Sequence Completed
Mitglied: orcape
orcape 28.01.2017 um 09:12:28 Uhr
Goto Top
Hi Nintox,
was Dir wohl fehlt ist ein File auf dem Server, welches sich CCD (Client-Config-Directory) nennt.
In diese Datei muss ein iroute Eintrag, als Hinweis auf Dein remotes Netz, in folgender Form (Bsp.-IP) ...
iroute 192.168.55.0 255.255.255.0;
.
In die Server.conf gehört dann der entsprechende Hinweis auf diese Datei...
client-config-dir /Pfad zur CCD
Existiert diese Datei nicht, macht OpenVPN hier wohl einen Multiclienttunnel mit 2 Client Ip 's...
tun1      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 
                               inet addr:172.16.3.6  P-t-P:172.16.3.5  Mask:255.255.255.255 
                               UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1400  Metric:1 
                               RX packets:0 errors:0 dropped:0 overruns:0 frame:0 
                               TX packets:14 errors:0 dropped:0 overruns:0 carrier:0 
                               collisions:0 txqueuelen:100 
                               RX bytes:0 (0.0 B)  TX bytes:1176 (1.1 KiB)
...hier bei Dir 172.16.3.5 und .6.
Eigentlich sollte die Ifconfig-Ausgabe des Tunnels in etwa so aussehen.
tun1      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
          inet addr:172.16.3.2  P-t-P:172.16.3.1  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1342  Metric:1
          RX packets:1567 errors:0 dropped:0 overruns:0 frame:0
          TX packets:59 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100 
          RX bytes:62060 (60.6 KiB)  TX bytes:5570 (5.4 KiB)
Die Tunnelendpunkte sind dann Server 172.16.3.1 und Client 172.16.3.2
dann sollten eigentlich auch die Tunnelprobleme Geschichte sein.
Gruss orcape
Mitglied: Nintox
Nintox 28.01.2017 um 10:48:47 Uhr
Goto Top
Danke für den Tipp. Wie lege ich denn am besten die Datei an.
Hab mal im offiziellen DD-WRT Forum gesucht, da wird eine Möglichkeit mit Startup-Script genannt und gezeigt:


Beispiel-Code:
OVPN_CCD_DIR="/tmp/openvpn/ccd"
mkdir -p $OVPN_CCD_DIR
echo 'push "route 192.168.1.0 255.255.255.0"' > $OVPN_CCD_DIR/JOHN

Aber würde sehr gerne die Datei via SSH erstellen und beschreiben. Mir fehlt zurzeit nur der nötige Syntax für DD-WRT

Die Remote-Adresse, die da unter iroute eingetragen werden muss wäre das Netz des Client-Routers?
Mitglied: orcape
orcape 28.01.2017 aktualisiert um 11:16:36 Uhr
Goto Top
Danke für den Tipp. Wie lege ich denn am besten die Datei an.
Bei DD-WRT sind die Daten von OpenVPN unter /tmp gespeichert. Bei Neustart also wieder weg. Du solltest Sie also nicht per ssh als Datei unter /tmp abspeichern, sondern im GUI eintragen. Leider habe ich keinen OpenVPN-Server unter DD-WRT am laufen, so das ich Dir hier auch nicht weiter helfen kann.
Mit einem Startscript sollte das aber funktionieren.
Die Remote-Adresse, die da unter iroute eingetragen werden muss wäre das Netz des Client-Routers?
Richtig, dessen LAN.
Gruss orcape
Mitglied: Nintox
Nintox 28.01.2017 um 11:51:01 Uhr
Goto Top
Dacht ich mir schon fast, das /tmp nachher wieder weg is.

Hab mal auf dem Server von Daemon zu Server umgestellt und da gibt auch ne Config Box mit der CCD.
Jedoch startet nach eintragung der Settings der Server nicht mehr. Bei Daemon gehts einwandfrei.
Mitglied: orcape
orcape 28.01.2017 um 13:35:42 Uhr
Goto Top
Jedoch startet nach eintragung der Settings der Server nicht mehr.
Wie sieht da Dein Eintrag aus ?
Wenn das nicht funktioniert, wirst Du wohl ein Script auf dem GUI hinterlegen müssen. Oder den Versuch machen, das File in einem anderen Ordner zu legen und den Pfad entsprechend anpassen. Keine Ahnung ob das machbar ist.
Mitglied: Nintox
Nintox 25.02.2017 aktualisiert um 14:39:58 Uhr
Goto Top
Kurzes Update: Hab mich nun doch für die pfSense Variante entschieden und mir ein APU-Board gekauft.
Alles soweit installiert und würde es nun so ins Netz einbinden:

Speedport Hybrid <--> WAN Port-- pfSense Firewall mit OVPN-Client -- LAN Port <--> Switch <--> Hosts

Macht es Sinn, die pfSense hinter dem Hybrid zu bridgen, dass man weiterhin nur ein Netz hat.
Wäre demjenigen, für den ich die ganze Sache einrichte am liebsten.
Oder sollten es schon 2 Netze werden. z.B 192.168.2.0 als WAN und LAN (hinter der pfSense) 192.168.1.0 ?
Mitglied: aqui
aqui 25.02.2017 aktualisiert um 14:51:13 Uhr
Goto Top
und mir ein APU-Board gekauft.
Eine weise Entscheidung face-wink
und würde es nun so ins Netz einbinden:
Alles richtig !
Macht es Sinn, die pfSense hinter dem Hybrid zu bridgen,
Nein ! Das würde die Firewall dann sinnlos machen.
Oder sollten es schon 2 Netze werden.
Ja.
Du musst die Tatsache des Transfernetzes dem Besitzer ja gar nicht groß erklären. Ist ja eh ein Punkt zu Punkt Netz mit einer Strippe.
Der brauch nur sein 192.168.1.0 Netz kennen und gut iss.
Vergiss in den pfSense Setup nicht den Haken zu entfernen bei "Block RFC1918 private networks" am WAN Port.
Bei OVPN musst du zudem ein Port Forwarding auf dem Speedport einrichten von UDP 1194 auf die WAN IP Adresse der pfSense so das der Speedport eingehende OVPN Requests auf die FW forwardet.
Alternativ kann man die pfSense WAN IP auch im SP als Exposed Host setzen.
Achte deshalb darauf das das dann eine statische IP ist und keine dynamische per DHCP. Denn sollte die sich mal ändern ists aus mit dem VPN.
Mitglied: orcape
orcape 26.02.2017 um 09:58:49 Uhr
Goto Top
@aqui
Bei OVPN musst du zudem ein Port Forwarding auf dem Speedport einrichten von UDP 1194 auf die WAN IP Adresse der pfSense so das der Speedport eingehende OVPN Requests auf die FW forwardet.
Ist beim OpenVPN-Client auf der pfSense nicht notwendig. Nur wenn er auf der pfSense einen OpenVPN-Server betreibt. face-wink
Gruss orcape
Mitglied: aqui
aqui 27.02.2017 um 12:19:31 Uhr
Goto Top
OK, das stimmt, da hast du natürlich Recht das das nur für die Server Seite gilt. Sorry für die Verwirrung.
Mitglied: Nintox
Nintox 01.04.2017 aktualisiert um 13:21:31 Uhr
Goto Top
So ...OpenVPN war aus Zeitgründen wieder bisschen auf Eis gelegt. Aber das klingt ja nach deiner Aussage auch schon sehr gut.
Block RFC1918 ist natürlich entfernt. Und VPN Verbindung (Handshake) funktioniert auch. Client schlägt beim Server auf.
Ping ist aber trotz dessen noch nicht möglich.

Auch wenn das hier nicht die schönsten Verschlüsselungen sind hier mal die Logs des Clients:
(Die Verschlüsselung bekommt ein Update mit AES256, sobald alles rennt.)


Apr 1 08:48:47 openvpn 77603 MANAGEMENT: Client disconnected
Apr 1 08:48:47 openvpn 77603 MANAGEMENT: CMD 'status 2'
Apr 1 08:48:47 openvpn 77603 MANAGEMENT: CMD 'state 1'
Apr 1 08:48:47 openvpn 77603 MANAGEMENT: Client connected from /var/etc/openvpn/client1.sock
Apr 1 08:41:15 openvpn 77603 MANAGEMENT: Client disconnected
Apr 1 08:41:15 openvpn 77603 MANAGEMENT: CMD 'status 2'
Apr 1 08:41:15 openvpn 77603 MANAGEMENT: CMD 'state 1'
Apr 1 08:41:15 openvpn 77603 MANAGEMENT: Client connected from /var/etc/openvpn/client1.sock
Apr 1 08:40:52 openvpn 77603 Initialization Sequence Completed
Apr 1 08:40:52 openvpn 77603 /sbin/route add -net 172.16.2.1 172.16.2.5 255.255.255.255
Apr 1 08:40:52 openvpn 77603 /sbin/route add -net 192.168.178.0 172.16.2.5 255.255.255.0
Apr 1 08:40:52 openvpn 77603 /sbin/route add -net 128.0.0.0 172.16.2.5 128.0.0.0
Apr 1 08:40:52 openvpn 77603 /sbin/route add -net 0.0.0.0 172.16.2.5 128.0.0.0
Apr 1 08:40:52 openvpn 77603 /sbin/route add -net 146.60.176.124 192.168.1.1 255.255.255.255
Apr 1 08:40:52 openvpn 77603 /usr/local/sbin/ovpn-linkup ovpnc1 1500 1545 172.16.2.6 172.16.2.5 init
Apr 1 08:40:52 openvpn 77603 /sbin/ifconfig ovpnc1 172.16.2.6 172.16.2.5 mtu 1500 netmask 255.255.255.255 up
Apr 1 08:40:52 openvpn 77603 do_ifconfig, tt->ipv6=1, tt->did_ifconfig_ipv6_setup=0
Apr 1 08:40:52 openvpn 77603 TUN/TAP device /dev/tun1 opened
Apr 1 08:40:52 openvpn 77603 TUN/TAP device ovpnc1 exists previously, keep at program end
Apr 1 08:40:52 openvpn 77603 ROUTE_GATEWAY 192.168.1.1
Apr 1 08:40:52 openvpn 77603 OPTIONS IMPORT: adjusting link_mtu to 1545
Apr 1 08:40:52 openvpn 77603 OPTIONS IMPORT: peer-id set
Apr 1 08:40:52 openvpn 77603 OPTIONS IMPORT: route options modified
Apr 1 08:40:52 openvpn 77603 OPTIONS IMPORT: --ifconfig/up options modified
Apr 1 08:40:52 openvpn 77603 OPTIONS IMPORT: timers and/or timeouts modified
Apr 1 08:40:52 openvpn 77603 Options error: Unrecognized option or missing parameter(s) in [PUSH-OPTIONS]:2: dhcp-options (2.3.14)
Apr 1 08:40:52 openvpn 77603 PUSH: Received control message: 'PUSH_REPLY,redirect-gateway def1,dhcp-options DNS 8.8.4.4,route 172.16.2.1,topology net30,ping 10,ping-restart 120,ifconfig 172.16.2.6 172.16.2.5,peer-id 1'
Apr 1 08:40:52 openvpn 77603 SENT CONTROL [server]: 'PUSH_REQUEST' (status=1)
Apr 1 08:40:49 openvpn 77603 [server] Peer Connection Initiated with [AF_INET]146.60.176.124:1194
Apr 1 08:40:49 openvpn 77603 Control Channel: TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
Apr 1 08:40:49 openvpn 77603 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Apr 1 08:40:49 openvpn 77603 WARNING: INSECURE cipher with block size less than 128 bit (64 bit). This allows attacks like SWEET32. Mitigate by using a --cipher with a larger block size (e.g. AES-256-CBC).
Apr 1 08:40:49 openvpn 77603 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Apr 1 08:40:49 openvpn 77603 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Apr 1 08:40:49 openvpn 77603 WARNING: INSECURE cipher with block size less than 128 bit (64 bit). This allows attacks like SWEET32. Mitigate by using a --cipher with a larger block size (e.g. AES-256-CBC).
Apr 1 08:40:49 openvpn 77603 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Apr 1 08:40:49 openvpn 77603 VERIFY OK: depth=0, C=DE, ST=BAWUE, L=, O=, OU=ADMIN, CN=server, name=changeme, emailAddress= (GEKÜRZT!)
Apr 1 08:40:49 openvpn 77603 VERIFY OK: depth=1, C=DE, ST=BAWUE, L=, O=, OU=ADMIN_, CN=changeme, name=changeme, emailAddress= (GEKÜRZT!)
Apr 1 08:40:49 openvpn 77603 TLS: Initial packet from [AF_INET]146.60.176.124:1194, sid=099cb01f 9a7ad5fc
Apr 1 08:40:49 openvpn 77603 UDPv4 link remote: [AF_INET]146.60.176.124:1194
Apr 1 08:40:49 openvpn 77603 UDPv4 link local: [undef]
Apr 1 08:40:49 openvpn 77603 Socket Buffers: R=[42080->42080] S=[57344->57344]
Apr 1 08:40:49 openvpn 77603 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Apr 1 08:40:49 openvpn 77603 WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
Apr 1 08:40:49 openvpn 77603 WARNING: using --pull/--client and --ifconfig together is probably not what you want
Apr 1 08:40:49 openvpn 77603 MANAGEMENT: unix domain socket listening on /var/etc/openvpn/client1.sock
Apr 1 08:40:49 openvpn 77568 library versions: OpenSSL 1.0.1s-freebsd 1 Mar 2016, LZO 2.09
Apr 1 08:40:49 openvpn 77568 OpenVPN 2.3.14 amd64-portbld-freebsd10.3 [SSL (OpenSSL)] [LZO] [MH] [IPv6] built on Feb 15 2017
Apr 1 08:40:49 openvpn 91998 SIGTERM[hard,] received, process exiting
Apr 1 08:40:48 openvpn 91998 /usr/local/sbin/ovpn-linkdown ovpnc1 1500 1544 172.16.2.6 172.16.2.5 init


Hier noch 2 Bilder der Firewall Settings:
nat_rule_firewall
rule_firewall
Mitglied: aqui
aqui 01.04.2017 aktualisiert um 14:11:09 Uhr
Goto Top
Ping ist aber trotz dessen noch nicht möglich.
Das ist auch vollkommen klar, denn es kommt KEIN OpenVPN Tunnel zustande!:
openvpn 77603 WARNING: No server certificate verification method has been enabled.

Und dann stoppt der Tunnel:
received, process exiting.... ovpn-linkdown ovpnc1
Ohne VPN Tunnel natürlich auch kein Ping...logisch !
Das hättest du ja anhand der Log Einträge doch auch selber sehen können. Man sollte halt mal lesen was da steht... face-wink

Kann das sein das du das Kommando ns-cert-type server in deiner Konfig Datei vergessen hast ?? Darauf basiert die o.a.Log Fehlermeldung.
https://openvpn.net/index.php/open-source/documentation/howto.html#mitm
Wenn ja füge die hinzu das sollte das Problem fixen und den Ping zum Fliegen bringen.
Mitglied: Nintox
Nintox 01.04.2017 aktualisiert um 15:34:00 Uhr
Goto Top
Zitat von @aqui:
Kann das sein das du das Kommando ns-cert-type server in deiner Konfig Datei vergessen hast ?? Darauf basiert die o.a.Log Fehlermeldung.
https://openvpn.net/index.php/open-source/documentation/howto.html#mitm
Wenn ja füge die hinzu das sollte das Problem fixen und den Ping zum Fliegen bringen.

Ähhm ... du hast recht. Ist in der pfSense ja mit einer CheckBox (Client-seitig) zu setzen.
Zumindest kommt nun keine solche Meldung mehr.
Aber Ping fliegt trotzdem noch nicht.
Was sagst du zur Firewall? Geht das so?

Servernetz: 192.168.178.0 255.255.255.0
Clientnetz: 192.168.2.0 255.255.255.0 --> WAN Netz zwischen Firewall und Hybrid 192.168.1.1 255.255.255.0 --> WAN Adresse Telekom

Sieht für mich zurzeit immer mehr nach einem Routing-Problem aus.
Mitglied: aqui
aqui 01.04.2017 aktualisiert um 16:43:14 Uhr
Goto Top
Aber Ping fliegt trotzdem noch nicht.
Bitte nochmal Log posten hier vom Verbindungsaufbau ! Vertrauen ist gut Kontrolle ist besser face-wink
Du musst ganz sicher sein das der VPN Tunnel steht.
  • Kannst du das interne VPN Tunnel Interface pingen ? (ICMP Regel dafür nicht vergessen !)
  • Kannst du das lokale LAN Interface der FW pingen )
  • Hast du im virtuellen VPN Interface der Firewall eine entsprechende Regel erstellt die den Zugriff aus dem internen OVPN Tunnelnetz erlaubt ?? Ggf. auch mal Screenshot posten hier zur Kontrolle.
Denk auch an die lokale Winblows Firewall wenn du mit Windows Endgeräten pingst. Wir hatten das (Windows) Drama hier kürzlich wieder mal:
Routingproblem in Homerouter-Kaskade mit Raspi
Was sagst du zur Firewall? Geht das so?
IP technisch ja, hast ja 2 unterschiedliche IP Netze (das 3te interne bei OVPN mal wieder vergessen face-sad ) also VPN seitig ist das OK.
Sieht für mich zurzeit immer mehr nach einem Routing-Problem aus.
Das wäre möglich... Leider fehlt dazu mal eine grobe Netzwerkskizze wie die IP Segmente verschaltet sind. Dann könnte man das ganz genau sagen.
OVPN in einer Routerkaskade ist hier beschrieben:
OpenVPN Server installieren auf pfSense Firewall, Mikrotik. DD-WRT oder GL.inet Router
Also ggf. mal Skizze posten hier und wie dein Routing aussieht.
Mitglied: orcape
orcape 01.04.2017 um 18:32:56 Uhr
Goto Top
Poste mal die Routingtabellen von Server und Client. Deine IP-Belegung OpenVPN-Server/Client mit 172.16.2.1/ 172.16.2.5 bzw. 172.16.2.6 sieht mir sehr danach aus, wie wenn keine Clientspezifische Datei im Server existiert bzw. ein Multiclienttunnel aufgebaut wird. Dann wird Dir zwar ein Tunnel gebaut, bekommst aber kein ping drüber.
172.16.2.1 Server
172.16.2.2 Client ....wäre Ok.
Mitglied: Nintox
Nintox 04.04.2017 aktualisiert um 18:51:07 Uhr
Goto Top
Hab hier mal die Routing Tables bei aktiver Open-VPN-Connection.
Was IP-Belegung angeht, was meinst du da genau?

Also die andere Seite kann ich auch direkt im VPN-Netz (172.16.2.0) nicht pingen. Nur lokale IP bis zum GW-Router des Clients (192.168.1.1)
2017-04-04 18_43_56-frank motorgeraete 1 (build 31221) - routing
routes2
routes1
Mitglied: aqui
aqui 05.04.2017 aktualisiert um 09:34:11 Uhr
Goto Top
Wegen der fehlenden Netzwerkskizze ist das jetzt ein kleines Ratespiel face-sad

Also beim obigen schwarzen Klotz, was vermutlich der Buffalo ist fehlen de facto Routen. Das lokale Netwerk des Routers unten (weiße Tabelle) lautet ja 192.168.1.0 /24 wenn man das richtig sieht.
Dieses IP Netz wird NICHT an den Router (schwarze Tabelle) propagiert.
Der "weiße Router" sieht auch nur das WAN Netzwerk .178.0 aber nicht das lokale LAN .12.0 am "schwarzen Router"
Das kannst du ja auch direkt selber sehen wenn du dir die beiden Routing Tabellen ansiehst !!!
Es fehlt immer das jeweils remote lokale LAN.
Ein sicheres Zeichen dafür das deine beiden Konfig Datein noch fehlerhaft sind und dort Routing Kommandos fehlen um diese Routen zu propagieren innerhalb des VPN Netzes.
Passiert das nicht gehen diese IP Netze immer in Richtung Provider und damit dann ins Nirwana.
Genau das was du also siehst mit deinen fehlschlagenden Pings.

Um sinnvoll weiterzukommen solltest du also mal deine beiden Konfig Dateien posten hier von beiden Routern. Und...ggf. eine grobe Skizze wie das Netzwerk jetzt verschaltet ist.
Mitglied: orcape
orcape 05.04.2017 aktualisiert um 10:10:19 Uhr
Goto Top
Dein Problem liegt nach wie vor bei diesem, von mir bereits geposteten Problem....
tun1      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  

02.

                               inet addr:172.16.3.6  P-t-P:172.16.3.5  Mask:255.255.255.255 
Dein Tunnel ist ein Multiclienttunnel, deshalb die nicht funktionierende Verbindung.
Lies Dir das noch mal Durch....
Mitglied: orcape
28.01.2017 um 09:12 Uhr

Bei Dir Server-IP...
172.16.3.1 / 172.16.3.2
Client-IP...
172.16.3.6 / 172.16.3.5

Dabei sollten Sich nur die IP 's 172.16.3.1 und 172.16.3.6 pingen lassen.
Ich habe da ohne CCD aber auch schon einige Probleme gehabt eine Verbindung zu bekommen.

Normal wäre....
Server-IP
172.16.3.1
Client-IP
172.16.3.2

Ansonsten kann ich @aqui nur recht geben...
Um sinnvoll weiterzukommen solltest du also mal deine beiden Konfig Dateien posten hier von beiden Routern.
Mitglied: Nintox
Nintox 15.04.2017 aktualisiert um 18:44:42 Uhr
Goto Top
Client Config:

Server Config:

port 1194
proto udp
dev tun0
ca /tmp/openvpn/ca.crt
cert /tmp/openvpn/cert.pem
key /tmp/openvpn/key.pem
dh /tmp/openvpn/dh.pem
server 172.16.2.0 255.255.255.0
push "route 192.168.12.0 255.255.255.0"
push "dhcp-options DNS 192.168.12.1"
keepalive 10 120
comp-lzo
persist-key
persist-tun
script-security 3
verb 3
management localhost 14
mute-replay-warnings

Aufbau Netz:
fireshot screen capture #001 - 'pandasave_localdomain - vpn_ openvpn_ clients_ edit' - 192_168_2_1_vpn_openvpn_client_php_act=edit&id=0
vpn_netzwerk_frank_motorgeraete
Mitglied: orcape
orcape 15.04.2017 um 18:51:47 Uhr
Goto Top
1. Du hast weder das Tunnelnetzwerk (172.16.2.0 255.255.255.0) noch Dein remotes Netzwerk (sprich LAN hinter dem Server) in der Client.conf eingetragen.
2. Costum Optionen (Client)
ns-cert-type server;
tun-mtu 1400; (beim Server ebenfalls, sonst hast Du Probleme bei der Stabilität der Paketübertragung)
Mitglied: Nintox
Nintox 15.04.2017 um 18:58:06 Uhr
Goto Top
Okey, ja die hatte ich drin. Habs aber wieder raus, weil ein OVPN Client Guide direkt im pfSense Forum aussagt, dass man das blanked lassen soll.
Vermutlich aber falsch.

Ich versuchs mal.
Mitglied: Nintox
Nintox 16.04.2017 aktualisiert um 10:20:37 Uhr
Goto Top
UPDATE:
Habs nun geändert und den Ping direkt auf der pfSense als auch auf dem Host dahinter getestet.
Host erreicht noch nichts. Auch via Paket Capture bekommen die Pings zum VPN Server bzw. das Netz dahinter kein Replay.
Jedoch bekomm ich mit Pings direkt auf der pfSense sowohl von Server-Netz als auch vom Lan-Netz dahinter antworten.

Irgendwie kennt der Host die Route noch nicht, kann das sein?

Firewalls (Windows als auch Software) wurde auf dem Host auch schon für den Test deaktiviert.
Mitglied: orcape
orcape 16.04.2017 um 11:03:22 Uhr
Goto Top
Hast Du denn auf der pfSense für ping eine Firewallregel erstellt? ICMP - source (host-IP) erlauben.
Kannst Du alles in den pfSense Logs nachschauen ob da was geblockt wird.
Status-Systemlogs-Firewall
Mitglied: aqui
aqui 16.04.2017 um 14:00:46 Uhr
Goto Top
Jedoch bekomm ich mit Pings direkt auf der pfSense sowohl von Server-Netz als auch vom Lan-Netz dahinter antworten.
Damit meinst du wenn du via VPN die lokalen pfSense IP Adressen des LAN Ports und des Server Netz Ports anpingst dann bekommst du eine Antwort ??
Wenn dem so ist dann funktioniert dein VPN fehlerlos.
Wenn Hosts sowohl im LAN Netz als auch im Server Netz auf Pings nicht antworten, dann ist das zu 98% deren lokale Firewall die das verhindert.
Pings (ICMP Protokoll) werden per Default geblockt in der Winblows Firewall:
https://www.windowspro.de/tipp/ping-windows-7-server-2008-r2-zulassen
Und da du einen fremde IP Absenderadresse hast werden diese Pakete auch geblockt, denn die lokale Win Firewall lässt nur IPs aus dem eigenen LAN passieren auf die internen Dienste.
Hier musst du also die Firewall anpassen.
Mitglied: Nintox
Nintox 16.04.2017 um 15:22:02 Uhr
Goto Top
Nicht ganz.

Ich hab die pfSense ja auf Client-Seite und den DDWRT Router auf Server-Seite. Von der pfSense kann ich einen erfolgreichen Ping auf den DDWRT Router (VPN Netz ) als auch das Netz dahinter (192.168.12.0) absetzen.

Aber wenn ich die Firewall (Windows) und Firewall Software deaktiviere muss doch ein Ping von einem Host hinter der pfSense genauso funktionieren wie direkt auf der Sense. Von Host auf pfSense bekomme ich ja auch ein Ping. Logisch, ist ja sein Gateway.
Mitglied: orcape
orcape 16.04.2017 um 16:04:30 Uhr
Goto Top
Ist denn ein Ping erlaubt ?
Hast Du denn auf der pfSense für ping eine Firewallregel erstellt? ICMP - source (host-IP) erlauben.
Mitglied: Nintox
Nintox 20.04.2017 um 19:43:39 Uhr
Goto Top
Ja, gerade eben nochmals mit einer extra Rule für den Test-Host hinter der PFSense getestet.

Kein Ping möglich. Das es auf der pfSense geht, sieht man im Screenshot.
2017-04-20 19_38_28-943481016 - anydesk
2017-04-20 19_38_47-943481016 - anydesk
Mitglied: orcape
orcape 21.04.2017 um 12:38:10 Uhr
Goto Top
Dann log Dich per ssh auf der pfSense ein.
Gib "netstat -r" ein und poste mal bitte die Ausgabe.
Mitglied: aqui
aqui 21.04.2017 um 12:46:36 Uhr
Goto Top
Den SSH Login muss er aber erst im Advanced Setup aktivieren face-wink
Es geht parallel auch über den Terminal Anschluss und Menüpunkt 8 (Shell)

Die Frage auch WO diese "Extra Rule" definiert wurde ?? Wenn dann muss es eine Regel am virtuellen VPN Adapter sein der FW. Der Screenshot also vom OVPN Interface wäre weit sinnvoller gewesen als ein gescheiterter Ping oder der überflüssige Shot vom LAN Interface mit der any zu any Scheunentorregel.
Das OVPN Interface ist relevant...sonst nix.
Vermutlich fehlen dort alle Regeln....?!
Mitglied: Nintox
Nintox 22.04.2017 um 09:22:51 Uhr
Goto Top
@orcape:

netstat -r
Internet:
Destination        Gateway            Flags      Netif Expire
0.0.0.0/1          172.16.2.1         UGS      ovpnc1
default            192.168.1.1        UGS        igb0
google-public-dns- 192.168.1.1        UGHS       igb0
google-public-dns- 192.168.1.1        UGHS       igb0
localhost          link#7             UH          lo0
128.0.0.0/1        172.16.2.1         UGS      ovpnc1
172.16.2.0/29      link#9             U        ovpnc1
172.16.2.2         link#9             UHS         lo0
188.104.248.190/32 192.168.1.1        UGS        igb0
192.168.1.0        link#1             U          igb0
192.168.1.1        00:0d:b9:43:27:a0  UHS        igb0
192.168.1.104      link#1             UHS         lo0
192.168.2.0        link#2             U          igb1
PandaSave          link#2             UHS         lo0
192.168.12.0       172.16.2.1         UGS      ovpnc1
192.168.178.0      172.16.2.1         UGS      ovpnc1

Internet6:
Destination        Gateway            Flags      Netif Expire
default            fe80::1%igb0       UGS        igb0
localhost          link#7             UH          lo0
p2003006A681C6C140 link#1             U          igb0
p2003006A681C6C140 link#1             UHS         lo0
p2003006A681C6C350 link#1             U          igb0
p2003006A681C6C350 link#1             UHS         lo0
p2003006A681C6C400 link#1             U          igb0
p2003006A681C6C400 link#1             UHS         lo0
p2003006A681C6C440 link#1             U          igb0
p2003006A681C6C440 link#1             UHS         lo0
p2003006A681C6C550 link#1             U          igb0
p2003006A681C6C550 link#1             UHS         lo0
fe80::1            fe80::1%igb0       UGHS       igb0
fe80::%igb0        link#1             U          igb0
fe80::20d:b9ff:fe4 link#1             UHS         lo0
fe80::%igb1        link#2             U          igb1
fe80::20d:b9ff:fe4 link#2             UHS         lo0
fe80::%lo0         link#7             U           lo0
fe80::1%lo0        link#7             UHS         lo0
fe80::2bd:c1ff:fed link#9             UHS         lo0
ff01::%igb0        fe80::20d:b9ff:fe4 U          igb0
ff01::%igb1        fe80::20d:b9ff:fe4 U          igb1
ff01::%lo0         localhost          U           lo0
ff01::%ovpnc1      fe80::2bd:c1ff:fed U        ovpnc1
ff02::%igb0        fe80::20d:b9ff:fe4 U          igb0
ff02::%igb1        fe80::20d:b9ff:fe4 U          igb1
ff02::%lo0         localhost          U           lo0
ff02::%ovpnc1      fe80::2bd:c1ff:fed U        ovpnc1

@aqui: SSH hab ich schon aktiviert gehabt, aber danke für den Hinweis face-smile
Natürlich wurde die Rule auf dem OVPN Interface festgelegt. Auf dem LAN hab ich es dann aber auch noch getestet.
Und die Scheunenregel soll das Problem jetzt einfach nicht unnötig erschweren. Läuft das Ding mal, werden die Rules sauber gesetzt. Für ein Produktivsystem ist das natürlich ein NOGO.
vpn_client_client_rule
Mitglied: orcape
orcape 24.04.2017 um 13:48:52 Uhr
Goto Top
Nur mal zum Vergleich ein netstat -r einer pfSense mit OpenVPN-Client...
[2.3.3-RELEASE][root@bengie.orca.net]/root: netstat -r
Routing tables

Internet:
Destination        Gateway            Flags      Netif Expire
default            fritz.box          UGS         vr0
10.12.7.1          link#10            UH       ovpnc2
10.12.7.1/32       10.12.7.1          UGS      ovpnc2
10.12.7.2          link#10            UHS         lo0
10.15.8.0          10.12.7.1          UGS      ovpnc2
localhost          link#7             UH          lo0
172.16.7.0         10.12.7.1          UGS      ovpnc2
172.16.8.0         link#3             U           vr2                                                             
172.16.8.1         link#3             UHS         lo0                                                             
192.168.1.0        link#1             U           vr0                                                             
192.168.1.2        link#1             UHS         lo0                                                             
192.168.18.0       link#2             U           vr1
bengie             link#2             UHS         lo0
192.168.66.0       link#9             U      ath0_wla
192.168.66.1       link#9             UHS         lo0
192.168.155.0      10.12.7.1          UGS      ovpnc2

Internet6:
Destination        Gateway            Flags      Netif Expire
localhost          link#7             UH          lo0
fe80::%vr0         link#1             U           vr0
fe80::20d:b9ff:fe2 link#1             UHS         lo0
fe80::%vr1         link#2             U           vr1
fe80::20d:b9ff:fe2 link#2             UHS         lo0
fe80::%vr2         link#3             U           vr2
fe80::20d:b9ff:fe2 link#3             UHS         lo0
fe80::%lo0         link#7             U           lo0
fe80::1%lo0        link#7             UHS         lo0
fe80::%ath0_wlan0  link#9             U      ath0_wla
fe80::20b:6bff:fe2 link#9             UHS         lo0
fe80::%ovpnc2      link#10            U        ovpnc2
fe80::20d:b9ff:fe2 link#10            UHS         lo0
ff01::%vr0         fe80::20d:b9ff:fe2 U           vr0
ff01::%vr1         fe80::20d:b9ff:fe2 U           vr1
ff01::%vr2         fe80::20d:b9ff:fe2 U           vr2
ff01::%lo0         localhost          U           lo0
ff01::%ath0_wlan0  fe80::20b:6bff:fe2 U      ath0_wla
ff01::%ovpnc2      fe80::20d:b9ff:fe2 U        ovpnc2
ff02::%vr0         fe80::20d:b9ff:fe2 U           vr0
ff02::%vr1         fe80::20d:b9ff:fe2 U           vr1
ff02::%vr2         fe80::20d:b9ff:fe2 U           vr2
ff02::%lo0         localhost          U           lo0
ff02::%ath0_wlan0  fe80::20b:6bff:fe2 U      ath0_wla
ff02::%ovpnc2      fe80::20d:b9ff:fe2 U        ovpnc2

Wenn man ein /24 er Netz als Tunnelnetz verwendet, macht OpenVPN dann virtuell ein /32 er Netz, wie Du bei mir siehst....
10.12.7.1/32 10.12.7.1 UGS ovpnc2
bei Dir erscheint ein /29 er Netz.
Du solltest Deine Einstellungen hierzu noch einmal checken. Irgend etwas stimmt da noch nicht. Ich hatte bei meinen ersten OpenVPN-Versuchen auch solche Probleme und dann keine Verbindung ins remote Netz.
Mitglied: Nintox
Nintox 28.04.2017 um 18:28:32 Uhr
Goto Top
Und was hast du dann gemacht, es zu beheben?
Mitglied: aqui
aqui 28.04.2017 aktualisiert um 19:58:56 Uhr
Goto Top
...die Server.conf Datei editiert natürlich und den Fehler behoben !! face-wink
macht OpenVPN dann virtuell ein /32 er Netz
Das ist auch normal, denn das interne VPN Netz ist ein Point to Pont Netz mit /32er Hostrouten face-wink
Kann man bei dir schön sehen. .1 ist der Server. 2 der Client.
Die klassische Route beim Kollegen Orcape zeigt das 10.15.8.0 Subentz oben. So sieht eine Bilderbuch OVPN Client Routing Tabelle aus face-wink

Ganz so falsch ist die Routing Tabelle des TO im Grundsatz nicht, allerdings offenbaren da diverse Einträge das da etwas sehr im Argen liegt mit der server.conf Datei oder auch ggf. der client.conf Datei:
  • 0.0.0.0/1 Bedeutet das ja ein Default Gateway Redirect hier vorliegt. Ist der Client aktiv wird sämtlicher Traffic in den Tunnel geroutet. Siehe dazu auch HIER Setzen wir mal voraus das das auch so gewollt ist.
  • Dann ist aber das Pushen der v4 Routen:
  • 128.0.0.0/1, 192.168.12.0 und 192.168.178.0 zusätzlich ja völliger Blödsinn, denn wenn eh alles in den Tunnel geht muss man diese IP Netze ja nicht noch überflüssigerweise extra nochmal angeben. Das zeigt schon einen Fehler.
  • Die Subnetzmasle "/1" an der Default Route und dem 128er Netz deutet auch auf einen Tippfehler oder Maskenfehler irgendwo in der Konfig hin.
Möglich auch das der TO das korrigiert hat es aber versäumt hat danach den OVPN Server neu zu starten so das der diese Änderungen nicht übernommen hat....
Hier können wir aber jetzt nur wild raten und spekulieren....
Mitglied: Nintox
Nintox 29.04.2017 um 14:40:47 Uhr
Goto Top
@orcape
Internet:
Destination        Gateway            Flags      Netif Expire
default            192.168.1.1        UGS        igb0
google-public-dns- 192.168.1.1        UGHS       igb0
google-public-dns- 192.168.1.1        UGHS       igb0
localhost          link#7             UH          lo0
172.16.2.1/32      172.16.2.5         UGS      ovpnc1
172.16.2.5         link#8             UH       ovpnc1
172.16.2.6         link#8             UHS         lo0
192.168.1.0        link#1             U          igb0
192.168.1.1        00:0d:b9:43:27:a0  UHS        igb0
192.168.1.104      link#1             UHS         lo0
192.168.2.0        link#2             U          igb1
PandaSave          link#2             UHS         lo0
192.168.12.0       172.16.2.5         UGS      ovpnc1

Also das /32 hab ich schon mal. Aber Pings von Hosts hinter der Sense funktioniert immer noch nicht.
Ich muss aber nicht weitere Konfigs an den Interfaces vornehmen. Hab da eben ein WAN und ein LAN definiert.
Weil manche Guides packen da noch ein OPT1 Interface dazu auf dem der VPN läuft.

@aqui: Hab die push Rules auf dem Server rausgenommen.
Mitglied: aqui
aqui 29.04.2017 um 17:16:35 Uhr
Goto Top
Ich muss aber nicht weitere Konfigs an den Interfaces vornehmen.
Doch natürlich !
Du musst einmal die Firewall Regeln im LAN anpassen und noch viel wichtiger die Firewall Regel am virtuellen OVPN Interface in der Firewall !!
Per Default sind dort deny any any Regeln wie bei einer Firewall üblich sprich also alles verboten !
Das musst du anpassen sonst blockt die Firewall sämtlichen Traffic.
Mitglied: Nintox
Nintox 29.04.2017 aktualisiert um 17:22:49 Uhr
Goto Top
@aqui

Die Firewall Rules sind denke ich soweit gesetzt, dass es klappen sollte.
Meinte jetzt mehr die direkte Konfig der Interfaces. Das man da irgendwie noch was bridgen muss.
Mitglied: orcape
Lösung orcape 29.04.2017 um 21:16:00 Uhr
Goto Top
07.         172.16.2.1/32      172.16.2.5         UGS      ovpnc1 
08.         172.16.2.5         link#8             UH       ovpnc1 
09.         172.16.2.6         link#8             UHS         lo0 

Immer noch ein Multiclienttunnel...
Zum Vergleich...
08.         10.12.7.1/32       10.12.7.1          UGS      ovpnc2 
09.         10.12.7.2          link#10            UHS         lo0 
Das Problem liegt beim Server, CCD mit Hinweis auf Client-LAN, iroute-Befehl vorhanden?
Gruss orcape
Mitglied: Nintox
Nintox 29.04.2017, aktualisiert am 30.04.2017 um 13:10:48 Uhr
Goto Top
@aqui @orcape

So, Pings funktionieren nun.
Lag an einer NAT Einstellung an der Sense.

Nur klappt das Internet bzw. DNS Resolve noch nich ganz.
Hab auf Server-Seite push redirect-gateway def 1 drin und auch den Google DNS dort angegeben.
Muss da noch was an der pfSense gemacht werden?

UPDATE:
Jetzt wirds total strange, ich kann Google via Browser nutzen. Gibt auch die Suchergebnisse an. Aber wenn ich auf eine Website will, kommt ein DNS Timeout.
Hab die MTU mal auf 1300 gesetzt. Weil ich dachte, vielleicht sind die Pakete zu groß. Aber hat nichts geändert.
Mitglied: Nintox
Nintox 19.05.2017 um 11:00:25 Uhr
Goto Top
UPDATE: Kann dicht gemacht werden. Läuft nun alles.
Bin gerade an einem Guide für diesen Infra-Case. Sobald er fertig ist, pack ich ein Link hier rein.
Hab festgestellt, viele Tutorials/Guides sind sehr schwammig erklärt und irgendwo kommt man dann am eigenen Case nicht mehr weiter.
Mitglied: aqui
aqui 19.05.2017 um 14:45:29 Uhr
Goto Top
Cool das nun alles klappt und ein Tutorial ist immer hilfreich. Dann sind wir mal gespannt auf den Link face-wink