Messages

Moin,

ich hatte extra separate Server erstellt (dadurch in den netstat auch ovpn3 und ovpn4 mit entsprechender Route).
Overrides hat er nicht genommen, egal ob ich "Force CSO Login Matching" gesetzt hab oder nicht.

Ich hab es dann auch aufgegeben, weil es mir unerklärlich war, dass in der Routing Tabelle alles gut ist, ich auch den Tunnel-Endpunkt anpingen kann, aber zum client Netz hin kein Ping durch geht. Von den Clients aus ins OPNSense Netz lief der Ping einwandfrei (da muss die OPNSense doch auch wissen, wie es wieder zurück geht?!)

und Ping ist nicht das einzige was ich getestet hab.
Auhc der Mitschnitt der Pakete zeigte auf den OVPN Interfaces, dass die Daten raus gehen..aber es kam nix zurück.

Ich vermute du hast die OVPN Server mit Site2Site nicht mit dem Shared Key Mode konfiguriert, sondern sauber mit Site2Site SSL und Zertifikaten? Wie sieht die Serverkonfiguration auf der OPNsense aus? Und hast du Client specific Overrides definiert? Da ein SSL-mode VPN Server prinzipiell mehrere Gegenstellen haben kann - nicht nur eine wie beim SharedKey - ist hier das Verhalten von OpenVPN etwas anders (und dokumentiert), da der VPN Server hier nicht genau sagen kann, an wen er welches Netz wie zurücksenden soll. Auch wenn nur eine Verbindung besteht - es könnten theoretisch mehrere sein, daher wird er nur Pakete rückrouten wenn:

* im VPN Server selbst als Remote Netz das Netz auf der anderen Seite (also hinter Raspi oder Windows GW) angegeben ist
* ein Client Specific Override konfiguriert ist, der den Client (Raspi oder Windows Kiste) identifiziert (normalerweise über den CN des Zerts) und dort nochmals als Remote Netz das entsprechende Netz drinsteht.

Die erste Angabe im Server ist quasi notwendig um dem VPN Service zu sagen "hey schicke 172.20.20.x an ovpns3" und der zweite im CSO damit er weiß, dass er das dem Client XY zurouten soll, der via ovpns3 verbunden ist.

Ist ein tick komplizierter als shared key aber wenn mans mal verstanden hat, gehts ganz einfach :)

Cheers
\jens

hab noch ein par Tests gemacht

ping auf den Tunnel Endpunkt wird vom Client Gateway registriert (tcpdump sieht die Pakete) - soweit funktioniert der ping ja auch
auf dem VPN Server selbst sehe ich die Pakete auch auf dem ovpn Interface

soweit also alles wie es sein soll


ping auf die private IP des VPN Gateway wird vom Server genauso registriert und geht auch über das interface wie beim ping auf den Tunnel Endpunkt ABER am Client Gateway kommen diese Pakete nicht an...der tcpdump bleibt leer

es gehen also beide Pakete vom Server raus auf dem entsprechenden korrekten interface
aber nur eins der Pakete erreicht das Client Gateway interface. Warum?!

Moin,

ich habe zwei OpenVPN Server erstellt. Zu dem ersten verbindet sich ein Windows Rechner und zu dem zweiten verbindet sich ein Raspi.
Beide Verbindungen stehen und ich kann vom Windows Rechner aus auf das gesamte Netz hinter der OPNSense zugreifen. Bei der Raspi Verbindung können auch die Clients hinter dem Raspi auf das Netzwerk hinter der OPNSense zugreifen.

Was auch noch funktioniert ist der Ping vom Rechner hinter der OPNSense auf die beiden IP´s des Tunnelnetzwerks (also die IP´s des Endpunktes = ich komme durch den Tunnel an die beiden Remote Gateways)

Was nun leider in beiden Fällen nicht funktioniert ist der Zugriff vom OPNSense Netzwerk zu den beiden VPN Gateways über deren IP´s und somit auch nicht auf dahinter liegende Clients.

Ich hab Client-seitig (also Windows Rechner und Raspi) das Routing aktiviert. Beim Windows Rechner die Firewall komplett ausgeschaltet und beim Raspi alle möglichen iptable Settings probiert, die man so finden kann...

in den Firewall Einstellungen auf der OPNSense hab ich sowohl bei LAN als auch bei OpenVPN (die Gruppenregel, da ich die Interfaces selbst nicht zugewiesen hab) "in any - any".

bei den beiden erstellten openvpn Servern hab ich separate Tunnel Netzwerke angegeben und bei beiden jeweils mein internes "ipv4 local Network" und das "ipv4 Remote Network"
TOS, inter-client communication, dynamic IP und Topology sind aktiviert.


ping geht wie erwähnt nicht durch
traceroute von der OPNSENSE hört nach Zeile 64 mit jeweils 3 Sternchen auf

zu guter Letzt noch die netstat, die doch auch gut ausschauen?!

Internet:
Destination        Gateway            Flags     Netif Expire
default            84.xxx.xxx.1        UGS      pppoe0
84.xxx.xxx.1        link#8             UH       pppoe0
127.0.0.1          link#5             UH          lo0
172.20.20.0/24     link#10            U        ovpns3
172.20.20.1        link#10            UHS         lo0
172.20.21.0/24     link#11            U        ovpns4
172.20.21.1        link#11            UHS         lo0
176.xxx.xxx.214     link#8             UHS         lo0
192.168.0.0/24     link#2             U          vmx1
192.168.0.1        link#2             UHS         lo0
192.168.2.0/24     link#3             U          vmx2
192.168.2.1        link#3             UHS         lo0
192.168.178.0/24   172.20.21.2        UGS      ovpns4
192.168.179.0/24   172.20.20.2        UGS      ovpns3


wo und wie kann ich mit der Analyse ansetzen?
ping 172.20.x.2 geht
ping 192.168.178.29 (wäre der Rechner mit installiertem openvpn) geht nicht - ich versteh es nicht und hab keinen Ansatz wo ich schauen müsste

Hallo,

habe folgendes Problem nach dem Upgrade auf 23.1

mein IPSec Tunnel zu einer Fritzbox ist zwar aufgebaut und ein Ping innerhalb der OPNSense zur Fritzbox ist über das (neu angelegte?) Interface IPSEC1 möglich, aber nicht über einen Client. Ich habe dann mal von der OPNSense einen Traceroute versucht - ebenfalls über das Interface direkt und die Pakete werden beim Tracert über die WAN Schnittstelle geschickt und kommen nicht durch?!
Daher stellt sich für mich zuerst die Frage - Warum geht der Ping durch aber nicht der Tracert?

---------------------------------------------------------------------------------------------------------------------------
# /sbin/ping -4 -S '10.0.0.1'  -c '3' '192.168.2.1'
PING 192.168.2.1 (192.168.2.1) from 10.0.0.1: 56 data bytes
64 bytes from 192.168.2.1: icmp_seq=0 ttl=64 time=33.868 ms
64 bytes from 192.168.2.1: icmp_seq=1 ttl=64 time=30.002 ms
64 bytes from 192.168.2.1: icmp_seq=2 ttl=64 time=30.673 ms

--- 192.168.2.1 ping statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 30.002/31.514/33.868/1.686 ms

---------------------------------------------------------------------------------------------------------------------------

# /usr/sbin/traceroute -w 2 -I  -n  -m '10' -s '10.0.0.1'   '192.168.2.1'
traceroute to 192.168.2.1 (192.168.2.1) from 10.0.0.1, 10 hops max, 48 byte packets
1  109.xx.xx.117  1.859 ms  1.235 ms  1.673 ms
2  * * *
3  * * *
4  * * *
5  * * *
6  * * *
7  * * *
8  * * *
9  * * *
10  * * *

---------------------------------------------------------------------------------------------------------------------------

die 109.xx.xx.117 ist die Gateway Adresse meines WAN (das WAN selbst hat die .118)

Unabhängig davon - wie migriere ich von der vorherigen legacy Verbindung auf die neue IPSec Verbindung, wenn ich keinen Zugriff auf die Fritzbox habe? Ich muss zugeben, ich hab die IPSec Verbindung nur mittels einer Anleitung zustande gebracht und hoffe, ich kann mit Hilfe der bestehenden Daten aus der Legacy Verbindung eine neue Verbindung erstellen...nur wie?

also hinter der Fritte ist ein Client aktiv, der das Routing übernehmen soll/kann.

Das Schlimme ist...das Ganze hat bereits funktioniert...dann hab ich aber die OPNSense zerschossen, neu installiert (auf Dev aktuelle Version) und seit dem bekomme ich das Ganze nicht mehr ans Laufen.

Daher frag ich mich, warum ich von dem Client Zugang erhalte und direkt von der OPNSense auf diesen Client nicht?!
Ich komme doch schon durch den Tunnel ans andere Ende (10.0.8.2) - aber die Route in der OPNSense selbst scheint ignoriert zu werden?! Oder müsste da als Gateway die 10.0.8.1 stehen statt der 10.0.8.2?! dann gibts hier wohl einen Bug.

Ich hatte in der ursprünglichen Konfiguration der virtuellen Schnittstelle opvns1 auch ein Interface zugewießen...jedoch klappt es auch damit nicht...oder meine Konfig war eine ganz andere.

Je nachdem ob ich in der Server Konfig ein eigenes und ein Remote Netz mitgebe, funktioniert auch Remote seitig nichts.

hab einen Client hinter der Fritte, da DS-Lite

Hallo,

umso mehr man sucht, umso mehr findet man ABER alles was man versucht ist zum scheitern verurteilt :(

mein vorhaben ist eigentlich ein ganz Einfaches:

LAN A - OPNSense OpenVPN - Modem - Internet - Fritzbox - Client LAN B
          192.168.0.0/24                      10.0.8.0/24        192.168.2.0/24

nun möchte ich wie viele andere auch, von allen Clients in LAN A auf alle Clients in LAN B zugreifen und umgekehrt.

Dazu habe ich alles fein säuberlich nach Anleitung(en) installiert und konfiguriert und es wurden folgende Dateien erzeugt:

die Server.conf sieht derzeit so aus

dev ovpns1
verb 3
dev-type tun
dev-node /dev/tun1
writepid /var/run/openvpn_server1.pid
script-security 3
daemon
keepalive 10 60
ping-timer-rem
persist-tun
persist-key
proto udp
cipher AES-256-CBC
auth SHA512
up /usr/local/etc/inc/plugins.inc.d/openvpn/ovpn-linkup
down /usr/local/etc/inc/plugins.inc.d/openvpn/ovpn-linkdown
local MEINE DERZEITIGE WAN IP (wird automatisch eingetragen)
client-disconnect "/usr/local/etc/inc/plugins.inc.d/openvpn/attributes.sh server1"
tls-server
server 10.0.8.0 255.255.255.0
client-config-dir /var/etc/openvpn-csc/1
username-as-common-name
auth-user-pass-verify "/usr/local/etc/inc/plugins.inc.d/openvpn/ovpn_auth_verify user 'Local Database' 'false' 'server1'" via-env
tls-verify "/usr/local/etc/inc/plugins.inc.d/openvpn/ovpn_auth_verify tls 'OpenVPN+Server+Zertifikat' 1"
lport 1194
management /var/etc/openvpn/server1.sock unix
push "route 192.168.0.0 255.255.255.0"
client-to-client
route 192.168.2.0 255.255.255.0
ca /var/etc/openvpn/server1.ca
cert /var/etc/openvpn/server1.cert
key /var/etc/openvpn/server1.key
dh /usr/local/etc/dh-parameters.4096.sample
tls-auth /var/etc/openvpn/server1.tls-auth 0
comp-lzo adaptive
passtos
topology subnet


zusätzlich noch "Client Specific Override" - Datei /var/etc/openvpn-csc/1/vpnuser

iroute 192.168.2.0 255.255.255.0


Das Ergebnis ist, dass ich zwar aus LAN B auf alles pingen kann in LAN A.
Von LAN A aus komme ich jedoch nicht ins LAN B.

Von der OPNSense selbst kann ich 10.0.8.2 pingen (also komme ich so schon mal ans Ende des Tunnels)
Ein Ping auf den entsrechenden Rechner der per OpenVPN Client die Verbindung herstellt ist jedoch nicht möglich.

Netstat -rn zeigt mir:

192.168.2.0/24   10.0.8.2  UGS   ovpns1

das schient mir auch korrekt so?!

ein Dauerping von einem Client in LAN A auf Client LAN B läuft ins Leere, aber firewall sagt:

ovpns1      Sep 22 18:52:42   192.168.0.6:61046   192.168.2.36:9630   tcp   let out anything from firewall host itself   



wo kann ich bei der Analyse weiter ansetzen?