"Recent posts
#91
Virtual private networks / Re: Wireguard client under Wi...
Last post by louis_nichols - July 03, 2025, 08:07:32 PMI am adding more screenshots of my config.
You cannot view this attachment.
You cannot view this attachment.
You cannot view this attachment.
You cannot view this attachment.
You cannot view this attachment.
You cannot view this attachment.
You cannot view this attachment.
You cannot view this attachment.
#92
Virtual private networks / Wireguard client under Window...
Last post by louis_nichols - July 03, 2025, 08:06:06 PMHi,
I configured Wireguard in my OPNSense following these instructions:
https://docs.opnsense.org/manual/how-tos/wireguard-client.html
using IPv4 only. For Normalization, I set 1372.
I defined two peers using the Peer Generator. I use one with my Android phone, and the second is for Windows. In Windows, I copy-pasted the config from the peer generator, so there is no reason to suspect keys or anything.
And now, the Android client works, but the Windows client keeps showing
2025-07-03 19:27:42.550: [TUN] [My_Wireguard] Handshake for peer 1 (<edited>:57394) did not complete after 5 seconds, retrying (try 2).
Under the transfer counters, the Rx stays always at 0.
I've read some posts online that suggested modifying the MTU in the Windows peer. I tried several values, but none of them had any effect.
I am adding screenshots with part of my config to this post. I am not able to add more because of attachment limits. I will try to add the rest to a reply to this post.
Any ideas?
You cannot view this attachment.
You cannot view this attachment.
You cannot view this attachment.
You cannot view this attachment.
I configured Wireguard in my OPNSense following these instructions:
https://docs.opnsense.org/manual/how-tos/wireguard-client.html
using IPv4 only. For Normalization, I set 1372.
I defined two peers using the Peer Generator. I use one with my Android phone, and the second is for Windows. In Windows, I copy-pasted the config from the peer generator, so there is no reason to suspect keys or anything.
And now, the Android client works, but the Windows client keeps showing
2025-07-03 19:27:42.550: [TUN] [My_Wireguard] Handshake for peer 1 (<edited>:57394) did not complete after 5 seconds, retrying (try 2).
Under the transfer counters, the Rx stays always at 0.
I've read some posts online that suggested modifying the MTU in the Windows peer. I tried several values, but none of them had any effect.
I am adding screenshots with part of my config to this post. I am not able to add more because of attachment limits. I will try to add the rest to a reply to this post.
Any ideas?
You cannot view this attachment.
You cannot view this attachment.
You cannot view this attachment.
You cannot view this attachment.
#93
German - Deutsch / Re: MultiWAN Routing
Last post by achmo - July 03, 2025, 06:09:52 PMGanz herzlichen Dank für die hilfreichen Tipps.
Ich habe (aus Verzweiflung ;-) ) den letzten Tipp einmal befolgt und eine LAN Regel an erster Stelle erstellt. Diese fixte das Routing, so das die Pakete für das Zwischennetz 192.168.30.0/30 auch durch das richtige GW die OPNSense verliessen. Das konnte ich mit PCAP, Traceoute und der Filter Liveansicht nachvollziehen. Verstehen tue ich dies weiterhin nicht; eine Route/Regel sollte wegen der direkten Schnittstelle 192.168.30.2 eigentlich nicht erforderlich sein. Aber gut.
Sehr wichtig ist in diesem Zusammenhang auch der "HINWEIS: Die Auswahl "Erlauben" funktioniert bei Multi-WAN nicht ordnungsgemäß. Sie funktioniert nur auf einer Schnittstelle, die das Standard-Gateway enthält. " bei den NAT Filterregeln des MultiWAN. Diese standen für die entsprechenden Ports zwar auf die richtige Gruppenschnittstelle aber die Filterregel war noch auf "Erlauben" aus den Single WAN Zeiten. Hier muss unbedingt "Eine entsprechende Filterregel anlegen" ausgewählt sein.
Andernfalls funktioniert die eingehende Verbindung durch die Schnittstelle mit der höheren Prio einwandfrei aber durch die andere nicht. Hier erreichen die Pakete zwar auch Ihr Ziel, aber die Antwortpakete gehen ohne Hinweis oder Protokolleintrag auf der OPNSense verloren oder werden ebenso durch die falsche Schnittstelle geroutet.
Ich habe (aus Verzweiflung ;-) ) den letzten Tipp einmal befolgt und eine LAN Regel an erster Stelle erstellt. Diese fixte das Routing, so das die Pakete für das Zwischennetz 192.168.30.0/30 auch durch das richtige GW die OPNSense verliessen. Das konnte ich mit PCAP, Traceoute und der Filter Liveansicht nachvollziehen. Verstehen tue ich dies weiterhin nicht; eine Route/Regel sollte wegen der direkten Schnittstelle 192.168.30.2 eigentlich nicht erforderlich sein. Aber gut.
Sehr wichtig ist in diesem Zusammenhang auch der "HINWEIS: Die Auswahl "Erlauben" funktioniert bei Multi-WAN nicht ordnungsgemäß. Sie funktioniert nur auf einer Schnittstelle, die das Standard-Gateway enthält. " bei den NAT Filterregeln des MultiWAN. Diese standen für die entsprechenden Ports zwar auf die richtige Gruppenschnittstelle aber die Filterregel war noch auf "Erlauben" aus den Single WAN Zeiten. Hier muss unbedingt "Eine entsprechende Filterregel anlegen" ausgewählt sein.
Andernfalls funktioniert die eingehende Verbindung durch die Schnittstelle mit der höheren Prio einwandfrei aber durch die andere nicht. Hier erreichen die Pakete zwar auch Ihr Ziel, aber die Antwortpakete gehen ohne Hinweis oder Protokolleintrag auf der OPNSense verloren oder werden ebenso durch die falsche Schnittstelle geroutet.
#94
25.1, 25.4 Production Series / Re: [acme] Custom deploy hooks...
Last post by keeka - July 03, 2025, 05:22:24 PMThere is the option in the dropdown to run a remote command via SSH.
You should therefore be able to use that option to run a local command via SSH on localhost. However I'm not sure how you discover the current cert/key/ca paths, should you need it in your script.
You should therefore be able to use that option to run a local command via SSH on localhost. However I'm not sure how you discover the current cert/key/ca paths, should you need it in your script.
#95
25.1, 25.4 Production Series / [acme] Custom deploy hooks?
Last post by skywalker007 - July 03, 2025, 03:43:05 PMCan I run my own automation script in the acme plugin? It seems to only have a list of commands to choose from.
thanks! Till
thanks! Till
#96
German - Deutsch / Re: Über VLAN ins Internet - L...
Last post by viragomann - July 03, 2025, 03:41:23 PMWAN_net ist eben nur das am WAN definierte Subnetz, WAN_address ist die WAN IP.
Du must die Destination alles erlauben, außer auf deine Subnetze.
Das kannst du machen, indem du eine Blockregel dafür oberhalb der allow-any setzt oder die Funktion der Destination umkehrst, damit nur andere erlaubt sind, was ich eleganter finde.
Um hierbei auf nach späteren eventuellen Änderungen im lokalen Netzwerk auf der sicheren Seite zu sein, empfiehlt es sich, einen Alias für sämtliche private Netzwerkbereiche anzulegen (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16). Ich nenne diesen naheliegend RFC1918.
Dann kannst du diesen in der Pass-Regel als Destination mit "Destination / Invert" angehakt verwenden, um nur andere Ziele als private Subnetze zu erlauben.
Alternativ kannst du ihn in einer Block-Regel verwenden.
Für den Fass, dass du den DNS Server auf der OPNsense nutzt, bedenke, dass dies dann eine zusätzliche Regel benötigt.
Du must die Destination alles erlauben, außer auf deine Subnetze.
Das kannst du machen, indem du eine Blockregel dafür oberhalb der allow-any setzt oder die Funktion der Destination umkehrst, damit nur andere erlaubt sind, was ich eleganter finde.
Um hierbei auf nach späteren eventuellen Änderungen im lokalen Netzwerk auf der sicheren Seite zu sein, empfiehlt es sich, einen Alias für sämtliche private Netzwerkbereiche anzulegen (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16). Ich nenne diesen naheliegend RFC1918.
Dann kannst du diesen in der Pass-Regel als Destination mit "Destination / Invert" angehakt verwenden, um nur andere Ziele als private Subnetze zu erlauben.
Alternativ kannst du ihn in einer Block-Regel verwenden.
Für den Fass, dass du den DNS Server auf der OPNsense nutzt, bedenke, dass dies dann eine zusätzliche Regel benötigt.
#97
25.1, 25.4 Production Series / Re: API path /api/trust/cert/...
Last post by skywalker007 - July 03, 2025, 03:41:15 PMI actually got this working by using trust/cert/get
#98
German - Deutsch / Re: Über VLAN ins Internet - L...
Last post by Patrick M. Hausen - July 03, 2025, 03:36:27 PMDu legst dir einen Alias an, der die anderen Netze enthält und ersetzt "any" in der Destination durch "!mein_alias".
#99
German - Deutsch / Re: Über VLAN ins Internet - L...
Last post by BeTZe313 - July 03, 2025, 03:24:26 PMHabe ich jetzt gemacht. Folgende Regel habe ich bei VLAN5 erstellt:
Interface: VLAN5
Direction: in
TCP: IPv4
Protocol: any
Source: VLAN5_net
Destination: any
Damit klappt es. Allerdings komme ich so auch in alle anderen Netze. Was muss ich denn tun, damit ich es auf den Zugang ins Internet beschränke?
Wenn ich bei Destination WAN_net oder WAN_Address nehme, funktioniert es nicht mehr
Interface: VLAN5
Direction: in
TCP: IPv4
Protocol: any
Source: VLAN5_net
Destination: any
Damit klappt es. Allerdings komme ich so auch in alle anderen Netze. Was muss ich denn tun, damit ich es auf den Zugang ins Internet beschränke?
Wenn ich bei Destination WAN_net oder WAN_Address nehme, funktioniert es nicht mehr
#100
High availability / Help !!! Packet lost and drop ...
Last post by stchesmeli - July 03, 2025, 02:52:29 PMHi all,
we use opnsense in our cloud IaaS provider (a based Xen solution Vates).
So we set up two instances with their own IPs in each VLAN, adding VIPs in carp mode with different group IDs.
We synchronize states and xmlrpc config via a SYNC VLAN.
Everything seemed to work fine during our tests, but as soon as we opened up the system to customers with a heavier load, we noticed a lot of timeouts and lost connections.
This only happens when both firewalls are on. As soon as we switch off the 2nd firewall everything works perfectly. I think there's a problem with the states.
Configuration level:
- each interface where there is a VIP CARP has a firewall rule to authorize CARP from any source/destination
- SYNC interface authorizes any IPV4 source and destination on the SYNC network
- SYNC's interface also authorizes CARP from any source/destination
- We sycnhronize "Aliases, DHCPD, Firewall Rules, NAT, static routes, Unbound DNS, VIP, Wireguard".
- some NAT/FW rules have the option of not synchronizing their conf via xmlrpc because they are "local" to the firewall
we use opnsense in our cloud IaaS provider (a based Xen solution Vates).
So we set up two instances with their own IPs in each VLAN, adding VIPs in carp mode with different group IDs.
We synchronize states and xmlrpc config via a SYNC VLAN.
Everything seemed to work fine during our tests, but as soon as we opened up the system to customers with a heavier load, we noticed a lot of timeouts and lost connections.
This only happens when both firewalls are on. As soon as we switch off the 2nd firewall everything works perfectly. I think there's a problem with the states.
Configuration level:
- each interface where there is a VIP CARP has a firewall rule to authorize CARP from any source/destination
- SYNC interface authorizes any IPV4 source and destination on the SYNC network
- SYNC's interface also authorizes CARP from any source/destination
- We sycnhronize "Aliases, DHCPD, Firewall Rules, NAT, static routes, Unbound DNS, VIP, Wireguard".
- some NAT/FW rules have the option of not synchronizing their conf via xmlrpc because they are "local" to the firewall
