"Recent posts
#81
Virtual private networks / Re: Wireguard Access and Globa...
Last post by meyergru - November 19, 2025, 09:28:26 AMWith VPNs, there are always two firewall rules involved:
1. The one with which you allow access for the VPN daemon port. In order to allow access for your roadwarriors from anywhere, this must not be limited by a geoip rule.
2. The ones to define what these roadwarriors can do within your network once they get an IP assigned by the VPN (which would be an RFC1918 IP). These rules can be specified at WG group, network, WG instance or even at the client IP level, but at finest granularity, they can tell you which specific WG key is bein used. They do not carry any information as to which routeable IP (or which country) the client originally came from.
So, yes, you can, but this private IP obviously bears no information on location. I use this all day. There must be a way to do this, otherwise any VPN client could do either nothing or anything. You can use different WG instances for site-2-site tunnels than for roadwarriors or even have different instances for "types" of roadwarriors (like administrators vs. developers).
1. The one with which you allow access for the VPN daemon port. In order to allow access for your roadwarriors from anywhere, this must not be limited by a geoip rule.
2. The ones to define what these roadwarriors can do within your network once they get an IP assigned by the VPN (which would be an RFC1918 IP). These rules can be specified at WG group, network, WG instance or even at the client IP level, but at finest granularity, they can tell you which specific WG key is bein used. They do not carry any information as to which routeable IP (or which country) the client originally came from.
So, yes, you can, but this private IP obviously bears no information on location. I use this all day. There must be a way to do this, otherwise any VPN client could do either nothing or anything. You can use different WG instances for site-2-site tunnels than for roadwarriors or even have different instances for "types" of roadwarriors (like administrators vs. developers).
#82
German - Deutsch / Re: HA Cluster - keine Web-Ver...
Last post by Flar69 - November 19, 2025, 09:23:18 AMIch habe mich jetzt mal an einer Zeichnung versucht.
Vielen Dank übrigens für die guten Vorlagen.
Jede Sense hat auch eine eigene WAN-IP zu Router.
Die Sense1 hat also eine x.x.101.1 für Wan1 und eine x.x.102.1 für Wan2
Die Sense2 hat dann eine x.x.101.2 für Wan1 und eine x.x.102.2 für Wan2
Ist vielleicht mein Fehler, dass ich die WAN-IPs dann zusätzlich mit einer CARP-Adresse (x.x.101.3 und x.x.102.3) versehen habe?
Wenn die CARP dann auf der Backup down ist bekomme ich keine Verbindung mehr zum Router?
Mit Dank und Gruss
Ralf
Vielen Dank übrigens für die guten Vorlagen.
Code Select
WAN WAN
: :
: CableProvider : DSL-Provider
: :
.---+---. .--+--.
WAN | Cable | Modems | DSL | WAN2
'---+---' '--+--'
| |
Ethernet | | PPPoE
| |
.----+-----------------------+----.
| | Router (MultiWan) | |
'----+-----------------------+----'
x.x.101.4/24 | | x.x.102.4/24
| |
.----+------. .-----+-----.
| Switch 1 | | Switch 2 |
'--+-----+--' '--+-----+--'
CARP x.x.101.3 | | x.x.102.1 | | CARP x.x.102.3
| | +-------------+ |
| | | |
| +--|-------------+ |
| | x.x.101.2 | |
x.x.101.1 | +--+ | | x.x.102.2
| | | |
.--+-----+--. PFSync .--+-----+--.
| OPNsense1 |----------| OPNsense2 |
'----+------' '----+------'
| CARP |
+--------+ +------+
| |
| |
.--+------+--.
| LAN-Switch |
'-----+------'
|
...-----+-----...
(Clients/Servers)
Jede Sense hat auch eine eigene WAN-IP zu Router.
Die Sense1 hat also eine x.x.101.1 für Wan1 und eine x.x.102.1 für Wan2
Die Sense2 hat dann eine x.x.101.2 für Wan1 und eine x.x.102.2 für Wan2
Ist vielleicht mein Fehler, dass ich die WAN-IPs dann zusätzlich mit einer CARP-Adresse (x.x.101.3 und x.x.102.3) versehen habe?
Wenn die CARP dann auf der Backup down ist bekomme ich keine Verbindung mehr zum Router?
Mit Dank und Gruss
Ralf
#83
Virtual private networks / Re: VIP (IP Alias) on VTI
Last post by bashfulaudi - November 19, 2025, 09:08:31 AMThe IPSec Virtual Tunnel Interface (VTI) is a route-based interface. Packets are first routed into the tunnel and then encrypted/decrypted. VIP requires NAT on the first interface that receives packets, which VTI cannot meet.
#84
25.7, 25.10 Series / Re: Feature Requst: KEA DHCPv6...
Last post by Monviech (Cedrik) - November 19, 2025, 08:22:43 AMYou can close the issue and open a new one following the template.
The more focused your request is on a simple topic, also generally with a configuration example and/or documentation, the more likely it will be a feature request.
If its mixing lots of different concepts/features and its a long wall of text it most likely doesnt get that much attention.
Put yourself in the shoes of somebody triaging 10 issues every day, the ones with a simple direction are more likely to get picked up.
The more focused your request is on a simple topic, also generally with a configuration example and/or documentation, the more likely it will be a feature request.
If its mixing lots of different concepts/features and its a long wall of text it most likely doesnt get that much attention.
Put yourself in the shoes of somebody triaging 10 issues every day, the ones with a simple direction are more likely to get picked up.
#85
German - Deutsch / Re: Opnsense DNS Warum funktio...
Last post by The_Master - November 19, 2025, 08:22:27 AMDanke für die Hilfe.
Ich bin hinter den Fehler gekommen den ich unabsichtlich gemacht habe. Ich hole aber etwas aus.
Habe ja geschrieben das ich von Tomato Firmware komme und dort auch DNSMASQ verwendet wird. Soweit so gut.
Im gleichen Atemzug habe ich mich auch in Opnsense an DNSMASQ gewagt und dort DHCP eingestellt. Auch das haben die VMs ohne Probleme übernommen.
Habe dann auch den Rat befolgt mit der Domain. Auch hier wurden die Änderungen übernommen. -> geshen in ipconfig /all.
Trotzdem waren die Geräte nicht mit dem von mir vergeben Alias Erreichbar. Egal ob mit Domain Anhang oder ohne. Mehrere Settings durchgetestet. Sogar die Opnsense komplett Reset und NEU installiert.
Nichts hat geholfen.
----------------------------------------------------------
Nun zu meinem Fehler! Und zugleich eine Bitte an die GUI Abteilung :)
Ich habe ja DHCP per DNSMASQ ausgegeben. Und auch in DNSMASQ die LEASE bekommen. Jetzt gibt es da einen Butten STATIC Lease! Damit kann man Static Lease erstellen mit Alias.
ABER DNS macht ja nicht DNSMASQ sondern UNBOUND!! Weil DNSMASQ hat den Port auf 0. Der macht ja kein DNS :)
Klar wenn DNSMASQ meine Static Lease kennt aber Unbound nicht das ich keinen Ping bekomme!
Deswegen bitte in der Wiki oder in der GUI selbst entweder riesen groß -> bitte dann UNBOUND Lease nehmen oder die Funktion/Tab sperren!
Ich weiß es war mein Fehler.
Habe es direkt zum Anlass genommen DNSMASQ links liegen zu lassen und auf KEA DHCP und Unbound DNS zu wechseln.
Sollte mein vorgehen KOMPLETT Falsch sein bitte direkt sagen. Ich will nicht einen Fehler mit einem Fehler korrigieren.
Werde die Tage nun nochmals alles auf Default oder neu installieren da ich doch einiges "getestet" habe und dann langsam alles von Tomato auf Opnsense übernehmen.
Danke nochmals für die Hilfe.
PS: ICH HASSE FRITZBOXEN. Ich will sie nicht ich habe sie nicht, kurz die Dinger sind ein graus.
Ich bin hinter den Fehler gekommen den ich unabsichtlich gemacht habe. Ich hole aber etwas aus.
Habe ja geschrieben das ich von Tomato Firmware komme und dort auch DNSMASQ verwendet wird. Soweit so gut.
Im gleichen Atemzug habe ich mich auch in Opnsense an DNSMASQ gewagt und dort DHCP eingestellt. Auch das haben die VMs ohne Probleme übernommen.
Habe dann auch den Rat befolgt mit der Domain. Auch hier wurden die Änderungen übernommen. -> geshen in ipconfig /all.
Trotzdem waren die Geräte nicht mit dem von mir vergeben Alias Erreichbar. Egal ob mit Domain Anhang oder ohne. Mehrere Settings durchgetestet. Sogar die Opnsense komplett Reset und NEU installiert.
Nichts hat geholfen.
----------------------------------------------------------
Nun zu meinem Fehler! Und zugleich eine Bitte an die GUI Abteilung :)
Ich habe ja DHCP per DNSMASQ ausgegeben. Und auch in DNSMASQ die LEASE bekommen. Jetzt gibt es da einen Butten STATIC Lease! Damit kann man Static Lease erstellen mit Alias.
ABER DNS macht ja nicht DNSMASQ sondern UNBOUND!! Weil DNSMASQ hat den Port auf 0. Der macht ja kein DNS :)
Klar wenn DNSMASQ meine Static Lease kennt aber Unbound nicht das ich keinen Ping bekomme!
Deswegen bitte in der Wiki oder in der GUI selbst entweder riesen groß -> bitte dann UNBOUND Lease nehmen oder die Funktion/Tab sperren!
Ich weiß es war mein Fehler.
Habe es direkt zum Anlass genommen DNSMASQ links liegen zu lassen und auf KEA DHCP und Unbound DNS zu wechseln.
Sollte mein vorgehen KOMPLETT Falsch sein bitte direkt sagen. Ich will nicht einen Fehler mit einem Fehler korrigieren.
Werde die Tage nun nochmals alles auf Default oder neu installieren da ich doch einiges "getestet" habe und dann langsam alles von Tomato auf Opnsense übernehmen.
Danke nochmals für die Hilfe.
PS: ICH HASSE FRITZBOXEN. Ich will sie nicht ich habe sie nicht, kurz die Dinger sind ein graus.
#86
German - Deutsch / Re: VOIP mit SWN NEumünster, F...
Last post by derMike - November 19, 2025, 07:32:59 AMMoin Maurice,
ich werde es am WE einmal austesten ob ich es damit zum laufen bekomme. Vielen Dank für den Tipp.
Gruß der Mike
ich werde es am WE einmal austesten ob ich es damit zum laufen bekomme. Vielen Dank für den Tipp.
Gruß der Mike
#87
Virtual private networks / Re: Wireguard Access and Globa...
Last post by spetrillo - November 19, 2025, 02:25:13 AMThanks!
Can I further lock this down by using the private IP of the incoming VPN connection as the source?
Can I further lock this down by using the private IP of the incoming VPN connection as the source?
#88
25.1, 25.4 Series / Re: Certain domains not resolv...
Last post by Dribbons - November 19, 2025, 12:43:02 AMHello,
i am a first time poster and registered just for this post since i have the exact same problem with e.g. stuttgart.de.
In OPNsense I forward all DNS queries to unbound. When i disable this temporarily, i am able to dig or nslookup stuttgart.de from my laptop, if i enable the dns querie forwarding again, i receive communication errors with timeouts. Adopting meyergrus settings did not help.
Any tips for digging deeper into this problem are welcome.
i am a first time poster and registered just for this post since i have the exact same problem with e.g. stuttgart.de.
In OPNsense I forward all DNS queries to unbound. When i disable this temporarily, i am able to dig or nslookup stuttgart.de from my laptop, if i enable the dns querie forwarding again, i receive communication errors with timeouts. Adopting meyergrus settings did not help.
Any tips for digging deeper into this problem are welcome.
#89
25.7, 25.10 Series / Re: Upgrade fails with signatu...
Last post by shaun90 - November 19, 2025, 12:38:34 AMQuote from: connervt on November 19, 2025, 12:18:47 AMOr perhaps today's Cloudflare issue?
It could be related, but I think it has more to do with the cellular broadband connection doing something bad. It was consistently broken after 10 attempts. I also found out after posting here that the smaller "base" tar as part of the upgrade from 25.7.0 -> 25.7.7 needed the same workaround.
#90
Virtual private networks / Re: IPSEC site-to-site P2's no...
Last post by Kadence - November 19, 2025, 12:19:21 AMI seem to have found my answer.
My Phase 2's were dropping at the Child SA Lifetime of 3600 seconds instead of rekeying.
I tried setting up this new OPNSense instance without tinkering with the IPSEC settings too much from the defaults for the sake of making it easy and trying out as much of the default stuff as possible.
I had to do a little trial and error in pfSense to find settings that would work with an OPNSense Connection set at the EA Defaults.
That seemed a little odd to me that the settings on the OPNSense end should be sort of a mystery.
In pfSense the Phase 1's had an Encryption Algorithm of AES256 with a hash of SHA512 and PFS at 14 (I also had it connect with a PFS of 16)
The Phase 2's were set the same.
These were just the settings that I settled on that happened to establish a connection and let the tunnel work.
While it appeared to be fine, it did leave me with the Phase2's dropping after an hour.
It occurred to me that I didn't fully understand what was happening with the EA set as "Default" in OPNSense. I realize that it utilizes a set of EA's that are optimal for connectivity but I'm not too great a fan of that "just trust it" sort of functionality.
I opted to disable Default and changed the algorithms to a fixed setting.
I set the Phase 1's to aes256gcm16-sha512-ecp521[DH21,NIST EC]
I set the Phase 2's to aes256gcm16-ecp512[DH21,NIST EC]
After adjusting the settings in 3 different pfSense endpoints to the same I've now had 3 tunnels rekey successfully several times without any issues.
I haven't needed to set the REQID and I have all of my LAN subnets configured in one Phase2 rather than multiple Phase 2's like on the pfSense end.
My Phase 2's were dropping at the Child SA Lifetime of 3600 seconds instead of rekeying.
I tried setting up this new OPNSense instance without tinkering with the IPSEC settings too much from the defaults for the sake of making it easy and trying out as much of the default stuff as possible.
I had to do a little trial and error in pfSense to find settings that would work with an OPNSense Connection set at the EA Defaults.
That seemed a little odd to me that the settings on the OPNSense end should be sort of a mystery.
In pfSense the Phase 1's had an Encryption Algorithm of AES256 with a hash of SHA512 and PFS at 14 (I also had it connect with a PFS of 16)
The Phase 2's were set the same.
These were just the settings that I settled on that happened to establish a connection and let the tunnel work.
While it appeared to be fine, it did leave me with the Phase2's dropping after an hour.
It occurred to me that I didn't fully understand what was happening with the EA set as "Default" in OPNSense. I realize that it utilizes a set of EA's that are optimal for connectivity but I'm not too great a fan of that "just trust it" sort of functionality.
I opted to disable Default and changed the algorithms to a fixed setting.
I set the Phase 1's to aes256gcm16-sha512-ecp521[DH21,NIST EC]
I set the Phase 2's to aes256gcm16-ecp512[DH21,NIST EC]
After adjusting the settings in 3 different pfSense endpoints to the same I've now had 3 tunnels rekey successfully several times without any issues.
I haven't needed to set the REQID and I have all of my LAN subnets configured in one Phase2 rather than multiple Phase 2's like on the pfSense end.
