"Recent posts
#81
German - Deutsch / Re: Hetzner Cloud Server Wire...
Last post by Peter68 - December 28, 2025, 11:05:10 PMWerbung ist schon weg, DNS läuft auch. IP verschleiern wäre das, was ich möchte. Sowas wie ein eigener VPN. Mit dem Cloud Server wollte ich einfach etwas Testen, kostet auch nicht so viel und andere in der Familie, könnten auch ihren Nutzen haben.
Meine OPNsense möchte ich erstmal so lassen, hängt zu viel dran. Das mit Tor, wenn du das meinst, hab ich nie richtig zum laufen bekommen.
Plan ist, dass mal alles über die cloud läuft, habe aber schon bemerkt, dass sich ein paar wenige Seiten nicht öffnen.
Meine OPNsense möchte ich erstmal so lassen, hängt zu viel dran. Das mit Tor, wenn du das meinst, hab ich nie richtig zum laufen bekommen.
Plan ist, dass mal alles über die cloud läuft, habe aber schon bemerkt, dass sich ein paar wenige Seiten nicht öffnen.
#82
German - Deutsch / Re: Hetzner Cloud Server Wire...
Last post by knebb - December 28, 2025, 10:27:30 PMMoin,
mir ist nicht ganz klar, was Du erreichen willst?
Ich denke aber, dass Du ein wenig eine fahlsche Vorstellung hast, was Dir ein solcher Cloud-Server bringen kann... Du hast doch schon im LAN eine OPNSense, damit kannst Du doch eigentlich alles machen, dann braucht es doch keinen Cloud-Server mehr zusätzlich?
/KNEBB
mir ist nicht ganz klar, was Du erreichen willst?
- Werbung weg?
- IP verschleiern?
- DNS selbst hosten?
Ich denke aber, dass Du ein wenig eine fahlsche Vorstellung hast, was Dir ein solcher Cloud-Server bringen kann... Du hast doch schon im LAN eine OPNSense, damit kannst Du doch eigentlich alles machen, dann braucht es doch keinen Cloud-Server mehr zusätzlich?
/KNEBB
#83
General Discussion / Caddy Reverse Proxy + Firewall...
Last post by kiekar - December 28, 2025, 10:23:03 PMHello,
I'm having issues trying to acces home assistant using caddy plugin.
I have a home assistant device on my IoT network 192.168.30.0/24
I created a rule on my LAN network 10.10.0.0/24 to access home assistant with
Protocol: IPv4 TCP
Source: LAN net
Destination: 192.168.30.87
Port: 8123
Which work fine however if try with ha.mydomain.com it fails with ERR_CONNECTION_TIMED_OUT.
I decide to create an Allow All Any rule for testing.
After deleting all history in the browser I was able to get access to home assistant with ha.mydomain.com
however when trying to lock down the rule by first changing the protocol from any to tcp, deleting the browser history
I was no longer able to access home assistant with browser ERROR_CONNECTION_REFUSED.
Below is the config for caddy.
Any idea why I'm having issues with the rules.
Any help would be much appreciated.
I'm having issues trying to acces home assistant using caddy plugin.
I have a home assistant device on my IoT network 192.168.30.0/24
I created a rule on my LAN network 10.10.0.0/24 to access home assistant with
Protocol: IPv4 TCP
Source: LAN net
Destination: 192.168.30.87
Port: 8123
Which work fine however if try with ha.mydomain.com it fails with ERR_CONNECTION_TIMED_OUT.
I decide to create an Allow All Any rule for testing.
After deleting all history in the browser I was able to get access to home assistant with ha.mydomain.com
however when trying to lock down the rule by first changing the protocol from any to tcp, deleting the browser history
I was no longer able to access home assistant with browser ERROR_CONNECTION_REFUSED.
Below is the config for caddy.
Any idea why I'm having issues with the rules.
Any help would be much appreciated.
Code Select
# caddy_user=root
# Global Options
{
log {
output net unixgram//var/run/caddy/log.sock {
}
format json {
time_format rfc3339
}
level DEBUG
}
servers {
protocols h1 h2
}
grace_period 10s
skip_install_trust
import /usr/local/etc/caddy/caddy.d/*.global
}
# Reverse Proxy Configuration
ha.mydomain.com {
tls /usr/local/etc/caddy/certificates/692f47de03cb7.pem /usr/local/etc/caddy/certificates/692f47de03cb7.key {
}
handle {
reverse_proxy 192.168.30.87:8123 {
}
}
}
import /usr/local/etc/caddy/caddy.d/*.conf
#84
German - Deutsch / Hetzner Cloud Server WireGuar...
Last post by Peter68 - December 28, 2025, 06:14:34 PMDa ich etwas anonymer im Netz unterwegs sein möchte, habe ich mir bei Hetzner einen kleinen Cloud Server zugelegt. Darauf habe ich Wireguard Installiert und meinen Rechner damit verbunden. Jetzt möchte ich AdGuardHome (nutze auch Unbound-DNS) welches auf meiner OPNsense läuft, auch gern nutzen. Das ganze läuft auch, bin nur nicht sicher ob es der richtige weg ist.
Beim Client (Rechner) habe ich meine Home IP als DNS eingetragen und eine Portweiterleitung eingerichtet. Hetzner IP - WAN Adresse 53 - OPNsense 53 und die Werbung wird schön rausgefiltert. IP-Adresse im Netz erscheint von Hetzner auch der standort. Ist der Ansatz soweit ok oder gibt es eine bessere Lösung.
Ich möchte irgendwann mal, wenn es stabil läuft, dass meine komplette OPNsense darüber läuft
Gruß
Beim Client (Rechner) habe ich meine Home IP als DNS eingetragen und eine Portweiterleitung eingerichtet. Hetzner IP - WAN Adresse 53 - OPNsense 53 und die Werbung wird schön rausgefiltert. IP-Adresse im Netz erscheint von Hetzner auch der standort. Ist der Ansatz soweit ok oder gibt es eine bessere Lösung.
Ich möchte irgendwann mal, wenn es stabil läuft, dass meine komplette OPNsense darüber läuft
Gruß
#85
General Discussion / acme deployment to opnsense
Last post by relvy - December 28, 2025, 05:43:08 PMHello,
I have acme client running on my Synology NAS.
I want to deploy my certificate from the NAS *to* opnsense with the ssh deploy hook
What values do I have to set to the DEPLOY_SSH_* variables for automatic deployment?
In particular I need to know the target path, target filenenames and the remote cmd.
I have acme client running on my Synology NAS.
I want to deploy my certificate from the NAS *to* opnsense with the ssh deploy hook
- .
What values do I have to set to the DEPLOY_SSH_* variables for automatic deployment?
In particular I need to know the target path, target filenenames and the remote cmd.
#86
German - Deutsch / Re: OPNsense und Hyper-V
Last post by JamesFrisch - December 28, 2025, 05:26:47 PMHi Andreas.
Eins vorweg, ich würde nicht auf Hyper-V setzten.
Wenn du aus der Windows Welt kommst, mag dies auf den ersten Blick einfacher erscheinen.
Proxmox ist aber IMHO einiges besser dafür geeignet. Gerade wenn du jetzt noch nichts am laufen hast.
Aber egal ob Hyper-V oder Proxmox, Firewall auf Hypervisor den Nachteil, dass bei jedem Hypervisor reboot dein Internet wegfällt.
Das wäre mir persönlich zu doof, aber deine Entscheidung.
Wenn wenn du dich für OPNsense auf Hypervisor entscheidest, gibt es zwei Möglichkeiten:
A: passthrough des NIC
B: virtuelle Bridges
Bei A reichst du den NIC an die OPNsense durch. Der Hypervisor hat dadurch keinen Zugriff mehr auf den NIC.
Falls dein NIC server grade ist und vNIC kann, kannst du auch nur einen der 64 virtuellen NICs durchreichen.
Vorteil von Variante A ist, dass der NIC sich bare metal verhält. Alles läuft auf dem NIC, egal welches offloading und was für Zauberdinge es sonst noch gibt.
Bei Option B ist halt der NIC in Software. Mit allen Nachteilen davon. Dafür ist es einfacher einzurichten, weil du einen NIC nicht exklusiv durchreichen musst an OPNsense.
Das nächste Problem ist deine Fritzbox. AFAIK kann die keinen sauberen bridge mode. Ist die Kabel, Kupfer oder Glas? Braucht es DECT? Ansonsten würde ich versuchen die Fritte durch einen Konverter / Bridge zu ersetzten.
Finde gerade in der Anfangszeit sollte man möglichst viele Fehler ausschliessen und das Setup möglichst einfach halten.
Darum würde ich dir dringend empfehlen OPNsense zuerst bare metal laufen zu lassen.
Du kannst die OPNsense dann immer noch später virtualisieren, mit einem simplen xml Export und Import.
Eins vorweg, ich würde nicht auf Hyper-V setzten.
Wenn du aus der Windows Welt kommst, mag dies auf den ersten Blick einfacher erscheinen.
Proxmox ist aber IMHO einiges besser dafür geeignet. Gerade wenn du jetzt noch nichts am laufen hast.
Aber egal ob Hyper-V oder Proxmox, Firewall auf Hypervisor den Nachteil, dass bei jedem Hypervisor reboot dein Internet wegfällt.
Das wäre mir persönlich zu doof, aber deine Entscheidung.
Wenn wenn du dich für OPNsense auf Hypervisor entscheidest, gibt es zwei Möglichkeiten:
A: passthrough des NIC
B: virtuelle Bridges
Bei A reichst du den NIC an die OPNsense durch. Der Hypervisor hat dadurch keinen Zugriff mehr auf den NIC.
Falls dein NIC server grade ist und vNIC kann, kannst du auch nur einen der 64 virtuellen NICs durchreichen.
Vorteil von Variante A ist, dass der NIC sich bare metal verhält. Alles läuft auf dem NIC, egal welches offloading und was für Zauberdinge es sonst noch gibt.
Bei Option B ist halt der NIC in Software. Mit allen Nachteilen davon. Dafür ist es einfacher einzurichten, weil du einen NIC nicht exklusiv durchreichen musst an OPNsense.
Das nächste Problem ist deine Fritzbox. AFAIK kann die keinen sauberen bridge mode. Ist die Kabel, Kupfer oder Glas? Braucht es DECT? Ansonsten würde ich versuchen die Fritte durch einen Konverter / Bridge zu ersetzten.
Finde gerade in der Anfangszeit sollte man möglichst viele Fehler ausschliessen und das Setup möglichst einfach halten.
Darum würde ich dir dringend empfehlen OPNsense zuerst bare metal laufen zu lassen.
Du kannst die OPNsense dann immer noch später virtualisieren, mit einem simplen xml Export und Import.
#87
25.7, 25.10 Series / Re: GeoIP with ipinfo stopped ...
Last post by IPinfo - December 28, 2025, 04:48:24 PMThank you very much. Keep me informed of any additional issues.
— Abdullah | DevRel, IPinfo
— Abdullah | DevRel, IPinfo
#88
General Discussion / Re: ECS and DNSSEC Setup
Last post by vimage22 - December 28, 2025, 02:32:48 PMHarden DNSSEC Data
If this is on, it appears to have a negative impact on performance.
Enable DNSSEC Support
If this is on, it was very difficult to see if it had an impact.
Both are off now. DoT is still on.
If this is on, it appears to have a negative impact on performance.
Enable DNSSEC Support
If this is on, it was very difficult to see if it had an impact.
Both are off now. DoT is still on.
#89
General Discussion / Re: TUI for viewing and analys...
Last post by patient0 - December 28, 2025, 02:15:25 PMIt's really a lot faster, well done! I had to record the srceen to see the pop-up with the version :)
And the view is a lot more compact, I do like >/< as indicator for incoming or outgoing traffic. It does make it a bit harder to read, I'd prefer to have the direction in it's own column or maybe a space between it and the interface (or O/I, not sure)?
Below is the output (btw, on NetBSD arm64) of a mixed IPv4 and IPv6 view. As you can see it fit's perfectly, with a little room for improvement regarding the 'Source > Destination' column :). And I can scroll to the right for infinity, maybe it would make sense to not go over the right end? Jumping to the beginning and end of a line is removed, I assume because it's hardly necessary since the view is already very compact?
The scenario when filtering for protocols with ports I think the view is not easy to read in regards to spotting the source port, with IPv4 and IPv6 address.
If filtering for one or the other it's a lot better.
Though I still think it could help to place the '>' in 'Source > Destination' at the same position for all columns.
But as said before: I really it and you are doing an tremendous job!
And the view is a lot more compact, I do like >/< as indicator for incoming or outgoing traffic. It does make it a bit harder to read, I'd prefer to have the direction in it's own column or maybe a space between it and the interface (or O/I, not sure)?
Below is the output (btw, on NetBSD arm64) of a mixed IPv4 and IPv6 view. As you can see it fit's perfectly, with a little room for improvement regarding the 'Source > Destination' column :). And I can scroll to the right for infinity, maybe it would make sense to not go over the right end? Jumping to the beginning and end of a line is removed, I assume because it's hardly necessary since the view is already very compact?
Code Select
Time Action Protocol Interface Source > Destination
Nov29-00:00:02 block carp >vtnet0 10.101.102.9 > 224.0.0.18
Nov29-00:00:02 pass ipv6-icmp <vtnet0 fdaa:b2b4:d8b2:1000::46 > fdaa:b2b4:d8b2:1000::1
Nov29-00:00:02 pass ipv6-icmp >vtnet0 fdaa:b2b4:d8b2:1000::1 > fdaa:b2b4:d8b2:1000::46
Nov29-00:00:03 block carp >vtnet0 10.101.102.9 > 224.0.0.18
Nov29-00:00:12 block carp >vtnet0 10.101.102.9 > 224.0.0.18
Nov29-00:00:12 pass ipv6-icmp >vtnet0 fe80::d475:84ff:feec:bb35 > fdaa:b2b4:d8b2:1000::46
Nov29-00:00:12 pass ipv6-icmp <vtnet0 fe80::be24:11ff:fe64:7ecf > fe80::d475:84ff:feec:bb35
Nov29-00:00:15 block carp >vtnet0 10.101.102.9 > 224.0.0.18
Nov29-00:00:16 block carp >vtnet0 10.101.102.9 > 224.0.0.18
Nov29-00:00:17 pass ipv6-icmp <vtnet0 fdaa:b2b4:d8b2:1000::46 > fe80::d475:84ff:feec:bb35
Nov29-00:00:17 pass ipv6-icmp >vtnet0 fe80::d475:84ff:feec:bb35 > fdaa:b2b4:d8b2:1000::46
...
Nov29-00:00:29 block carp >vtnet0 10.101.102.9 > 224.0.0.18
Nov29-00:00:31 block carp >vtnet0 10.101.102.9 > 224.0.0.18
position: 1/102735
q: quit | hjkl: move | ud: page | gG: jump | enter: details | /: filter
The scenario when filtering for protocols with ports I think the view is not easy to read in regards to spotting the source port, with IPv4 and IPv6 address.
If filtering for one or the other it's a lot better.
Though I still think it could help to place the '>' in 'Source > Destination' at the same position for all columns.
Code Select
Time Action Protocol Interface Source > Destination
Nov29-00:04:11 pass udp <vtnet0 10.101.102.46 57429 > 128.140.109.119 123
Nov29-00:04:17 pass udp <vtnet0 fdaa:b2b4:d8b2:1000::46 37449 > 2a01:239:25e:bd00::1 123
Nov29-00:05:31 pass udp <vtnet0 10.101.102.46 21946 > 185.207.105.38 123
Nov29-00:06:51 pass udp <vtnet0 10.101.102.46 34219 > 84.16.73.33 123
Nov29-00:07:49 pass udp <vtnet0 fdaa:b2b4:d8b2:1000::46 44293 > 2a01:4f8:120:14ed:1::100 123
Nov29-00:08:01 pass udp <vtnet0 fdaa:b2b4:d8b2:1000::46 10256 > 2603:c020:8017:3eee:123:123:123:123 123
Nov29-00:08:13 pass udp <vtnet0 fdaa:b2b4:d8b2:1000::46 11354 > 2a02:168:420b:4::7b:12 123
Nov29-00:08:21 pass udp <vtnet0 10.101.102.46 52554 > 85.195.210.125 123
Nov29-00:10:59 pass udp >vtnet2 fe80::be24:11ff:fe19:804e 546 > ff02::1:2 547
Nov29-00:10:59 pass udp <vtnet2 fe80::be24:11ff:fe6b:7a06 547 > fe80::be24:11ff:fe19:804e 546
...
Nov29-00:34:54 pass udp <vtnet0 10.101.102.46 48905 > 85.195.210.125 123
Nov29-00:39:35 pass udp <vtnet0 fdaa:b2b4:d8b2:1000::46 1345 > 2a01:239:25e:bd00::1 123
Nov29-00:39:35 pass udp <vtnet0 10.101.102.46 46626 > 128.140.109.119 123
position: 1/1492 | filter: "udp"
q: quit | hjkl: move | ud: page | gG: jump | enter: details | /: filter | esc: clear
But as said before: I really it and you are doing an tremendous job!
#90
German - Deutsch / Re: OPNsense und Hyper-V
Last post by Andi_s75 - December 28, 2025, 01:40:53 PMQuote from: Bob.Dig on December 28, 2025, 01:37:05 PMQuote from: Monviech (Cedrik) on December 28, 2025, 12:01:41 PMBei Hyper-V braucht man pro VLAN ein eigenes interface im vswitch, den Tag stellt man im interface ein.Das kann man auch anders machen, wenn man das Server-OS einsetzt.
Aber woran es hier trotz 20 Jahren scheitert, ist ja auch noch vollkommen offen.
Den Spruch hättest du dir einfach mal sparen können. Oft scheitert sowas an solchen Menschen wie dir! Ganz ehrlich! Gut, dass solche Menschen wie du alles verstehen. Ist immer wieder die selbe Art in solchen Foren. Hoffe Du hattest jetzt deinen Selbstwert steigern können.
