Messages

Hi,
I ve configured VPN on OPNsense and I do get successful VPN connections with the clients "openvpn" on Debian 10 and "OpenVPN GUI 2.x" on Win 11. As Win 10 refuses to install OpenVPN GUI 2.x I tried to use the newer client version "OpenVPN Connect v3" on my Win10 pc. But I get the error "EPKI_ERROR External Certificate Signing Failed". Here is the connecting log:

Code Select Expand


[Dec 6, 2022, 12:39:33] OpenVPN core 3.git::d3f8b18b win x86_64 64-bit built on Mar 17 2022 11:42:02
[Dec 6, 2022, 12:39:33] Frame=512/2048/512 mssfix-ctrl=1250
[Dec 6, 2022, 12:39:33] UNUSED OPTIONS
1 [persist-tun]
2 [persist-key]
6 [resolv-retry] [infinite]
8 [lport] [0]
13 [pkcs12] [my_p12_file.p12]
[Dec 6, 2022, 12:39:33] EVENT: RESOLVE
[Dec 6, 2022, 12:39:33] Contacting my_server_ip:1194 via UDP
[Dec 6, 2022, 12:39:33] EVENT: WAIT
[Dec 6, 2022, 12:39:33] WinCommandAgent: transmitting bypass route to my_server_ip
{
"host" : "my_server_ip",
"ipv6" : false
}

[Dec 6, 2022, 12:39:33] Connecting to [my_server_ip]:1194 (my_server_ip) via UDPv4
[Dec 6, 2022, 12:39:33] EVENT: CONNECTING
[Dec 6, 2022, 12:39:33] Tunnel Options:V4,dev-type tun,link-mtu 1602,tun-mtu 1500,proto UDPv4,comp-lzo,keydir 1,cipher AES-256-CBC,auth SHA512,keysize 256,tls-auth,key-method 2,tls-client
[Dec 6, 2022, 12:39:33] Creds: UsernameEmpty/PasswordEmpty
[Dec 6, 2022, 12:39:33] Peer Info:
IV_VER=3.git::d3f8b18b
IV_PLAT=win
IV_NCP=2
IV_TCPNL=1
IV_PROTO=30
IV_CIPHERS=AES-256-GCM:AES-128-GCM:CHACHA20-POLY1305:AES-256-CBC
IV_LZO_STUB=1
IV_COMP_STUB=1
IV_COMP_STUBv2=1
IV_AUTO_SESS=1
IV_GUI_VER=OCWindows_3.3.6-2752
IV_SSO=webauth,openurl,crtext

[Dec 6, 2022, 12:39:33] EVENT: EPKI_ERROR External Certificate Signing Failed
[Dec 6, 2022, 12:39:33] Client exception in transport_recv_excode: OpenSSLContext::SSL::read_cleartext: BIO_read failed, cap=2576 status=-1: error:0406B07A:rsa routines:RSA_padding_add_none:data too small for key size / error:141F0006:SSL routines:tls_construct_cert_verify:EVP lib
[Dec 6, 2022, 12:39:33] EVENT: DISCONNECTED


One year ago a user asked the same question in the openvpn forum, but yet no solution => https://forums.openvpn.net/viewtopic.php?t=32717.

Is there any chance to get the Connect-Client work with VPN on OPNsense? If not, isn't it about time that both teams OPNsense and OpenVPN communicate with each other to fix this problem?

Hallo,
danke, dass du Dir die Zeit genommen hast, auf meine Fragen einzugehen. Ich meine, dass das "Chaos" eigentlich überschaubar ist. Es kommt jetzt vielleicht nur so rüber, weil ich bei meinem Problem auch noch meine Test-Umgebung ins Spiel bringe. Ich habe die echten Firewalls nach folgenden Dokus mit meinen verfügbaren IPs eingerichtet:

https://www.thomas-krenn.com/de/wiki/OPNsense_HA_Cluster_einrichten
und
https://www.thomas-krenn.com/de/wiki/OPNsense_OpenVPN_f%C3%BCr_Road_Warrior_einrichten

Und für VIP habe ich die CARP-Regel drin.

Firewall: Rules: WAN
Protocol IPv4 CARP
Source WAN net
Port *
Destination WAN net
Port *
Gateway *

Firewall: Rules: LAN
Protocol IPv4 CARP
Source LAN net
Port *
Destination LAN net
Port *
Gateway *

Deshalb ist es mir unbegreiflich, warum die OpenVPN-Verbindung auf der WAN IP funktioniert und nicht auf der WAN VIP (Backup zu Master geworden am neuen Standort). Ich werde noch einmal alles durchgehen.

Hier die von mir eingefügte ICMP - Regel. Unter floating sind jede Menge automatisch generierte Regeln auch für ICMP, jeweils für IPv4 u. 6. Dann müsste es doch eigentlich damit schon funktionieren.

Firewall: Rules: WAN

Protocol IPv4 ICMP
Source *
Port *
Destination *
Port *
Gateway *


Wie macht ihr das hier mit dem Kopieren von Regeln für das Forum? Ich kann doch jetzt nicht alle Regeln abschreiben, Screenshot klappt nicht unter Debian in einer VM.

Hallo,
ich hätte noch eine andere Frage. Ist es normal, dass man die FW nicht mehr anpingen kann, wenn sie sich im Backup-Status befindet, auch wenn sie eine eigene WAN Adresse hat? Ich teste hier immer erst alles in einer virtuellen Umgebung unter Windows 10 / Virtualbox mit VM für opnsense1/2 und Debian).

opnsense1 WAN 192.168.178.34
opnsense VIP WAN 192.168.178.35
opnsense2 WAN 192.168.178.36

Wenn ich bei opnsense1 den Button "Enter persistent CARP maintenance mode" drücke, kann ich die 192.168.178.34 von Debian aus, das sich im LAN der FW befindet, nicht anpingen. Ist das normal?

Von Windows aus der Kommandozeile heraus kann ich die drei IPs allerdings gar nicht anpingen, dabei habe ich ICMP in den Rules freigegeben.

Hallo,

ich habe derzeit eine Backup-Firewall eines HA-Setups für einen schrittweisen Umzug an einem anderen Standort untergebracht und die neuen IP-Adressen eingetragen. Eine VPN-Verbindung über die WAN-IP funktioniert, aber nicht über die WAN-VIP. Die WAN-VIP kann aber angepingt werden und wird als Carp-Master im Dashboard angezeigt. Was war noch einmal die Voraussetzung, damit eine VPN-Verbindung auch über die virtuelle IP funktioniert? Muss da irgendwo noch eine Regel eingetragen werden? Eine VPN-Verbindung über die VIP der Master-Firewall am alten Standort funktioniert hingegen. Deshalb bin ich da nun etwas verwirrt. Danke für eine evtl. Hilfestellung!

Das scheint jetzt zu funktionieren. Ich habe den anderen Thread überflogen und daraufhin für jede FW eine erreichbare WAN IP angegeben und bei NAT Outbound als NAT Address "WAN address" statt "VIP WAN" ausgewählt. Ich wollte halt mit WAN IPs nicht "verschwenderisch" sein (eingetragen war 172.18.0.101 und 172.18.0.102). Bei Produktivsystem habe ich tatsächlich auch nur eine externe IP zur Verfügung, aber bald nach einem Umzug wären ausreichend vorhanden, so dass ich das dann auch entsprechend ändern könnte.

Hi,
ich möchte gerne ein Update von opnsense im HA Cluster in meiner virtuellen Umgebung durchspielen. Dazu habe ich folgende Anweisung vorliegen:

1. Aktualisieren Sie die Backup-Firewall (Firewall 2) und warten Sie, bis diese wieder online ist.
2. Wählen auf der primären Firewall unter Firewall ‣ Virtual IPs ‣ Status den Punkt Enter Persistent CARP Maintenance Mode.
3. Sobald Firewall 2 zum MASTER wurde, überprüfen Sie ob alle Dienste wie DHCP, VPN, NAT nach dem Update weiterhin korrekt funktionieren. Für den unwahrscheinlichen Fall, dass das Firewall-Update zu Problemen bei bestimmten Diensten führte, können Sie wieder auf die ursprüngliche Firewall schalten bevor Sie dort das Update eingespielt haben.
4. Wenn alle Dienste wie gewünscht nach dem Update funktionieren, aktualisieren Sie Firewall 1 und wählen Sie danach Leave Persistent CARP Maintenance Mode.

Das Problem ist aber nun, dass meine Backup-Firewall überhaupt keine Verbindung zum Internet hat, wenn sie sich im Backup-Status befindet! Erst, wenn sie Master geworden ist, bekomme ich darüber ne Verbindung zum Netz. Punkt 1 kann ich so gar nicht durchführen.

Ist es normal, dass die Backup-FW im Backup-Status keine Verbindung zum Netz hat? Wenn ja, wie ist eine Aktualisierung ohne Ausfall möglich? 

Bei mir ist zum Testen Windows der Host, dann Virtualbox mit einer VM für FW1, einer VM2 für FW2 und einer VM für Linux, die über die FWs verbunden ist.

Man könnte natürlich einen Port-Forward einrichten vom OpenVPN Netz komment und dann auf den externen SSH Server weiterleiten.

Alternativ (was ich schöner finde) wäre es sinnvoller dem Client einfach die Route mitzuteilen. Also z.B. 1.1.1.1/32 soll durch den OpenVPN Tunnel durch. Dann das OpenVPN Netz in die Outbound NAT Regel vom WAN integrieren und fertig.

Super, danke, ich werde das morgen ausprobieren. Die erste Lösung hatte ich heute Morgen einmal ausprobiert, es kam aber keine Antwort. Da war dann wohl doch ein Fehler dabei. Aber ich werde die zweite Lösung auch testen. Aber schon einmal gut zu wissen, dass es mehrere Lösungen gibt.

Hallo,

ich habe OpnSense und OpenVPN so konfiguriert, dass sich Clients per VPN über das Internet ins Firmennetz verbinden können. Nun würde ich das gerne so erweitern, dass ein VPN-Client bei bestehender VPN-Verbindung eine SSH-Verbindung zu einem anderen externen Server herstellen kann, wenn dieser einen bestimmten Port der Firewall adressiert, weil nur die WAN-IP der Firewall bei dem externen Server freigeschaltet sein darf. 

Für die VPN-Verbindung muss ja unter Firewalls/Rules/OpenVPN eine Regel für den Zugriff vom VPN Netz auf das lokale Netzwerk der Firewall erstellt werden (VPN-Netz direction in). Meine Frage ist nun, ob ich an dieser Stelle eine weitere Regel für den Zugriff nach außen erstellen muss, also VPN-Netz direction out? Oder muss diese Regel unter Firewall/NAT/Outbound untergebracht werden (VPN-Netz an WAN-Address)?

Bei meinem Test-System hat die Einstellung für das Port-Forwarding funktioniert, alledings ohne VPN. Bei dem Real-System mit VPN funktionerte es nicht, deshalb kann es nur an der fehlenden Regel für das VPN-Netz liegen.

Gruß
Thomas

Hach, dann muss wirklich das rote Kabel eine Macke haben. Ich habe DNS und Upstream-GW wie auf der 1. FW eingestellt. Muss ich wirklich hinfahren...

[...]
Updating OPNsense repository catalogue...
pkg-static: https://pkg.opnsense.org/FreeBSD:11:amd64/20.1/latest/meta.txz: No address record
repository OPNsense has no meta file, using default settings
pkg-static: https://pkg.opnsense.org/FreeBSD:11:amd64/20.1/latest/packagesite.txz: No address record
Unable to update repository OPNsense
Error updating repositories!

Hallo,
ich habe zwei Firewalls, als HA-Setup aber noch unvollständig. Auf der 1. FW funktioniert der ausgehende Traffic. OUTBOUND ist an die virtuelle Public-IP wie folgt gebunden.

Code Select Expand


Firewall: NAT: Outbound 1. Firewall

Interface Source Source Port Destination Destination Port NAT Address NAT Port Static Port Description
WAN 192.168.2.0/24  * * * <VIP WAN/Pulic-IP> * NO


Da auf der 2. FW die virtuelle IP nicht aktiv ist / sein kann, habe ich für OUTBOUND nur WAN-Adresse ausgewählt. Dies scheint der Grund zu sein, warum ich auf der 2. FW nicht raus komme und kein Update durch führen kann. Testweise habe ich dies auf der 1. FW auch so eingestellt, dann funktionierte der ausgehende Traffic auch nicht mehr. Wenn OUTBOUND aber an VIP WAN gebunden sein muss, wie muss ich das denn dann auf dem Backup-Server einstellen, damit ich mal ein Update durchführen kann?

Dann nutzt du vermutlich die flasche Subnet Mask. /32 ist für einen Singlehost.

Danke, jetzt funktioniert es. Nun kann ich beides über die Web-GUI abgleichen. Das Feld  "Subnet Mask" ist zunächst deaktiviert bei Auswahl von SingleHost or Network, auch wenn man die IP-Adresse einträgt. Man muss dann trotzdem auf das deaktivierte Feld klicken, damit es aktiviert wird. Ich werde morgen trotzdem wohl zu den Servern fahren müssen, das rote Kabel der 2. FW muss ne Macke haben. Ich komme auf der 2. FW überhaupt nicht raus und kann kein Update durchführen.

Ich habe an einigen Standorten auch ein HA Setup. Die zweite Firewall ist meiner Meinung nach nicht erreichbar, da sie die Quell IP, von der Du kommst, an ihren eigenem OpenVPN Gateway antworten will (Route).

Ich habe mir so beholfen, dass ich einfach eine NAT Outbound Rule auf der FW1 eingerichtet habe, so in etwa:

Interface LAN
Source: Das Netz von dem du kommst
Destination: die IP von FW2
Port *
NAT Address: "Interface address", oder eine beliebige aus dem Netz, in dem beide FW's sind
NAT Port *
Static Port NO

Ich kam erst jetzt wieder dazu, mich damit auseinander zu setzen. Ich kann als Destination hier nicht die IP der 2. FW eintragen. Die Web-GUI der 1. FW ändert mir während des Speicherns automatisch die Adresse aus dem Feld "Single Host or Network" in die LAN-Netzwerkadresse um (192.168.2.0 anstelle von 192.168.2.102). Daher habe ich diese Regel nicht endgültig übernehmen können.

Eine Frage hätte ich dazu noch nachträglich: Kann ich diese Regel nicht auch über die Konsole "irgendwo" in einer config eintragen, oder bin ich hier immer auf die Web-GUI angewiesen? Irgendwie müsste das möglich sein, weil ja über PFSYNC auch Änderungen in Form von "Snippets" an den Backup-Server übertragen werden, oder?

Was sagt denn das FW Log deiner 2. Sense? Lässt sie Anfragen aus dem VPN schonmal rein?

Code Select Expand


tbarth@Debian10:~$ ssh -p 222 root@192.168.2.102

root@opnsense2:~ # tcpdump -i igb0 -n host 192.168.3.6
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on igb0, link-type EN10MB (Ethernet), capture size 262144 bytes

10:46:20.088964 IP 192.168.3.6.39592 > 192.168.2.102.222: Flags [S], seq 3875960924, win 64240, options [mss 1357,sackOK,TS val 1701548012 ecr 0,nop,wscale 7], length 0


Hat Deine 2. Sense eine Route für das VPN zum LAN damit sie nicht default an das WAN routet?

Nein, hat sie noch nicht. Offensichtlich muss ich dann auf dem OpenVPN Interface bereits die selbe Regel erstellen, wie ich sie auf der 1. Firewall eingerichtet habe?

Code Select Expand


Protocol Source Port Destination Port Gateway Schedule Description
IPv4 * 192.168.3.0/24 * * * * * Allow OpenVPN traffic


ERST, wenn ich mich auf opnsense1 einlogge, kann ich mich auf opnsense2 einloggen

Meinst Du über das GUI einloggen?  :o

Sorry, da meinte ich den SSH-Login