OpenVPN Routen funktionieren nicht

[titzi266]

Hallo,

ich benutze seit kurzem OPNsense. (Als virtuelle Maschine in KVM)

Die VM läuft auf einem CentOS in KVM und hat folgende Netzwerkkarten:

 - Eine Netzwerkkarte (INTERN) ist eine Bridge zum physikalischen Interface des Servers.
 - Die zweite Netzwerkkarte (DMZ) ist in einem virtuellen KVM Netzwerk (die DMZ).

Im Netzwerk DMZ befindet sich z.B. eine Apache-VM die von OPNsense per DHCP eine IP bekommt und OPNsense als default Gateway nutzt.


Mein Netz sieht wie folgt aus:

Internet > FritzBox > OPNsense Interface INTERN  | OPNsense Interface DMZ < VMs im virtuellen DMZ Netz.

FritzBox:
 - IP: 10.0.0.1
 - Route: 10.2.0.0/24 via 10.0.0.254 (Route zur DMZ via OPNsense)
 - Port-Forwarding für z.B. TCP/443 zu 10.0.0.254 (OPNsense)

physikalischer Server auf dem OPNsense als VM in KVM läuft:
 - IP eth0: 10.0.0.100
 - Default GW: 10.0.0.1 (FritzBox)

OPNsense:
 - IP (INTERN): 10.0.0.254
 - IP (DMZ): 10.2.0.254
 - OpenVPN Server mit Tunnel Netz: 10.8.0.0/24

VMs im virtuellen DMZ Netz:
 - IP: 10.2.0.X (per DHCP von OPNsense)
 - Default GW: 10.2.0.254 (OPNsense)

Das Problem:
Nun habe ich auf der FritzBox unter anderem ein Port Forwarding für 1194/UDP nach 10.0.0.254 (OPNsense Interface im Netz der FritzBox).
In OPNsense habe ich eine NAT Rule die mich für 1194/UDP zu 10.2.0.254 (DMZ Adresse von OPNsense) bringt.
Der OpenVPN Server lauscht auf dem Interface 10.2.0.254 von OPNsense.
In OpenVPN habe ich folgendes bei IPv4 Local Networks eingetragen: 10.0.0.0/24,10.2.0.0/24

Nun wäre meine Erwartung, dass ich Routen zu diesen Netzen per VPN bekomme und diese erreichen kann per VPN.

Als Client Specific Override habe ich folgendes (um eine Feste IP auf dem VPN Client zu bekommen):
ifconfig-push 10.8.0.22 255.255.255.0;
Funktioniert auch.

Ich habe hier auch schon auf folgendem Wege die Routen versucht zu pushen:
push "route 10.0.0.0 255.255.255.0 10.8.0.1"

Ich kann nur das VPN-Gateway 10.8.0.1 und andere Clients im VPN Netz erreichen aber nicht die Netze 10.0.0.0/24 und 10.2.0.0/24.

Im Firewall Log sehe ich nichts was blockt aber auch die Verbindungen gar nicht ankommen. Vermute also daher, dass das Problem noch weiter vorne liegt.1

Der Client ist übrigens ein Android Gerät mit dem offiziellen OpenVPN Client aus dem Google PlayStore.
Hier sieht es gut aus. Bekomme folgende Ausgaben am Client:
[route] 10.0.0.0 255.255.255.0
[route] 10.8.0.0 255.255.255.0
[route] 10.0.0.0 255.255.255.0 10.8.0.1
[topology] subnet

Kleine Info noch: Ich habe noch eine separate OpenVPN VM in der DMZ (10.2.0.X mit OPNsense als default Gateway).
Wenn ich die NAT Rule in OPNsense auf diese VM biege (statt das DMZ Interface von OPNsense) bekomme ich über diese VM VPN und dann auch an alle gewünschten Netze ran.
Nur den OpenVPN Server innerhalb von OPNsense bekomme ich nicht ans Laufen.

Hat jemand eine Idee wo es hängen könnte?

Danke für eure Hilfe.
Titzi266

[pingus]

Hi

Ich kann dir zwar nicht weiterhelfen, habe aber evtl. das gleiche oder ein ähnliches Problem.

Habe mit der 17.1.3er Version eine OpenVPN Verbindung (Seite A) zu einem anderen Gerät (Seite B) hergestellt und konnte von der Seite B richt Seite A pingen jedoch nicht umgekehrt.

Routen sind auf beiden Seiten vorhanden. Im Log sehe ich nichts geblocktes.

Einfach zur Info

[titzi266]

Hi,

ich habe leider keine Idee was bei dir für ein Problem vorliegen könnte. Klingt für mich eventuell nach asynchronem routing.

Ich habe mein Problem lösen können. Habe OPNsense einfach nochmal komplett neu installiert und das OpenVPN neu konfiguriert. Nun geht alles. Keine Ahnung was davor los wahr. Vielleicht irgendeine andere bestehende Regel von meinen Tests, die nicht im Log aufgetaucht ist.

Grüße
Titzi266

[pingus]

Hi

Habe gestern wieder mal mit OpenVPN gespielt. Es funktioniert einfach nicht.

Routingeinträge habe ich auf der OPNsense Seite wie auch auf der Mikrotik Seite. Firewallregeln sind any/any auf beiden Seiten. Von der Mikrotik Seite her kann ich ins OPNsense LAN pingen, umgekehr geht gar nicht. Im OPNsense Rules Log sehe ich keine geblockten Einträge. Traceroute endet bei OPNsense, auf der Mikrotik Seite geht nichts.
Zwischendurch konnte ich das LAN auf der Mikrotik Seite pingen, ohne etwas zu ändern hat es dann aber plötzlich nicht mehr funktioniert. Warum? Kein Ahnung.

Lustigerweise funktioniert ein OpenVPN Tunnel mit Debian einwandfrei. Tunnel zwischen Mikrotik und Mikrotik funktioniert auch. Irgendwas klemmt. Ich probiere heute mal noch pfsense aus, obwohl, eigentlich will ich OPNsense 

[pingus]

Endlich hat es funktioniert. Ich musste für jeden Client "Client Specific Overrides" anlegen. Dort habe ich dann nur das Remote Netzwerk nochmals eingetragen (und den Common Name).
Beim Server sind die Remote Netzwerke ja schon in einer Komma getrennten Liste eingetragen.

Ist das so üblich? Für S2S müsste doch der Servereintrag genügen?:

These are the IPv4 networks that will be routed through the tunnel, so that a site-to-site VPN can be established without manually changing the routing tables. Expressed as a comma-separated list of one or more CIDR ranges. If this is a site-to-site VPN, enter the remote LAN/s here. You may leave this blank if you don't want a site-to-site VPN.

[Unwissender]

Ich habe als IPv4 Upstream Gateway das "normale" Gateway im WAN angegeben.Zudem habe ich unter System->Gateway jeweils die beiden weitergehenden Gateways angelegt. Soweit bin ich aber ja noch gar nicht.

Client----Switch-----LAN-OPNsense-WAN-----Switch-------WANGateway
                                                                               -------Clinet im WAN

Ich kann vom Client nur das OPNsenseWAN-Interface erreichen, nicht aber das Gateway oder den Client im WAN.
Routingeinträge sollten hierfür ja auch nicht erforderlich sein, da die beiden Netze der FW ja bekannt sein sollten.

Die Firewall habe ich nicht aktiviert, da ich die Funktionalität nicht benötige.
Muss man das Routing noch irgendwo aktivieren? Ich nutze derzeit noch eine Smoothwall. Hier kann man ohne weitere Konfiguration "durchpingen".

[mimugmail]

Zudem habe ich unter System->Gateway jeweils die beiden weitergehenden Gateways angelegt.

Lass die mal weg, ist ne Fehlerquelle weniger.