"Recent posts
#1
General Discussion / Re: Block Local Network Connec...
Last post by meyergru - Today at 09:23:35 AMIn a strict sense, you would need a separate VLAN for any specific device. Most people only separate an "IoT" VLAN.
There are smart switches and networking equipment, where you can even keep devices on layer 2 separate. Unifi can do that on their WiFi networks ("Client Device Isolation", but it inhibits Airplay, Chromecast and others).
If you do not want network access for a single network device, you can block that specifically on OpnSense, even without having VLANs. Note, however, that this would strip a smart TV from most of its prominent features, like streaming.
As long as your device has internet access, it can spy on you even when it cannot reach its neighbors one way or another. As the video shows, the webcams and microphones are accessible from outside.
There are smart switches and networking equipment, where you can even keep devices on layer 2 separate. Unifi can do that on their WiFi networks ("Client Device Isolation", but it inhibits Airplay, Chromecast and others).
If you do not want network access for a single network device, you can block that specifically on OpnSense, even without having VLANs. Note, however, that this would strip a smart TV from most of its prominent features, like streaming.
As long as your device has internet access, it can spy on you even when it cannot reach its neighbors one way or another. As the video shows, the webcams and microphones are accessible from outside.
#2
26.7 Series / Re: Wireguard vs. DNS resoluti...
Last post by meyergru - Today at 09:04:33 AMPlease see reply #7 and provide the information requested there. Otherwise, there is little point in further speculation.
#3
German - Deutsch / Re: DNS Setup mit Unbound, DNS...
Last post by emmitt - Today at 08:31:32 AMQuote from: JeGr on September 04, 2026, 01:01:33 PMWenn die Entscheidungen durch sind, ist es nur noch ein Zusammmenstecken der Komponenten. Je nach Konfiguration kannst du dann AGH auf internem Interface auf 53 lauschen lassen, Unbound auf 5353 umziehen und dem AGH als Forward dann localhost:5353 verpassen damit er das an den internen Unbound weitergibt. Der macht dann die Endauflösung via Roots und Resolving. Wenns DNSmasq ist, gleiches Spiel. Das was die Clients bekommen/erreichen sollen, sollte auf Por 53 laufen, den Rest packt man auf andere Ports und forwarded da hin.
Kea ist da eigentlich DHCP-technisch völlig simpel und annähernd gleich mit ISC zu konfigurieren. Außer du hast große Sonderlocken mit irgendwelchen DHCP Optionen und Co., das könnte dann problematischer werden, aber für Standard run-of-the-mill normalen DHCP gibts da gar nicht viel zu failen.
Ganz herzichen Dank für Deine Mühe und die ausführliche Antwort JeGr!
Das hat mir sehr geholfen und ich habe es jetzt so umgesetzt: AGH -> Unbound -> KEA
Läuft prima!
Greetz Emmitt
#4
General Discussion / Re: Block Local Network Connec...
Last post by tangofan - Today at 08:31:29 AMQuote from: pfry on Today at 07:50:12 AMThanks, Steve.
Sure, just run all connections through the firewall. I do this. In general you just need enough compute power in your firewall (varies by application) and appropriate connectivity (e.g. lots of ports on the firewall and/or virtual ports via one or more managed Ethernet switches).
Just to clarify: That would mean running every device directly into a port on the firewall, would it not? Because if you connect them via a switch, that traffic would never hit the firewall, since the switch would just pass it directly via the applicable port to the target device.
Of course now that I think of it, if you had a managed(!) switch, then you could put each device into a separate VLAN that you also created in OPNsense. Then there would be no intra-VLAN traffic and the switch would forward all traffic to OPNsense. Pretty extreme, but workable. Perhaps someone has a better idea?
#5
General Discussion / Re: Block Local Network Connec...
Last post by pfry - Today at 07:50:12 AMThanks, Steve.
Sure, just run all connections through the firewall. I do this. In general you just need enough compute power in your firewall (varies by application) and appropriate connectivity (e.g. lots of ports on the firewall and/or virtual ports via one or more managed Ethernet switches).
I jail my TV (connect it to a port on the firewall that does not allow outbound communication), as I do not use any "smart" features. I connect it (to Ethernet) to try to dissuade it from connecting to open wi-fi... which may or may not be effective (I believe it is, as my TV is fairly old). I'd remove the wi-fi module, but that effectively disables the remote (which I use occasionally).
Sure, just run all connections through the firewall. I do this. In general you just need enough compute power in your firewall (varies by application) and appropriate connectivity (e.g. lots of ports on the firewall and/or virtual ports via one or more managed Ethernet switches).
I jail my TV (connect it to a port on the firewall that does not allow outbound communication), as I do not use any "smart" features. I connect it (to Ethernet) to try to dissuade it from connecting to open wi-fi... which may or may not be effective (I believe it is, as my TV is fairly old). I'd remove the wi-fi module, but that effectively disables the remote (which I use occasionally).
#6
26.7 Series / Re: block events without Label...
Last post by pfry - Today at 07:31:52 AMI'd expect a log like that to be due to "Firewall: Settings: Normalization" -> "Disable interface scrub", also visible under "Firewall: Diagnostics: Statistics" -> "rules", "rules" -> "filter rules", usually the top entry. I believe you can allow options via rules: check "allow options" under "Advanced features".
#7
General Discussion / Block Local Network Connection...
Last post by borealis67 - Today at 07:30:55 AMPlease excuse me if this isn't being posted in the correct place or has been addressed.
Is there a way to setup my OPNsense router to block or hide all LAN devices from seeing or interacting with each other?
This is something I've been wondering about for a while but after I saw this video I made me want to do this even more.
Is this possible? Is there a way to request such a feature to be added to OPNsense? Or is it there and I am just ignorant of its existence?
Any help is appreciated.
Is there a way to setup my OPNsense router to block or hide all LAN devices from seeing or interacting with each other?
This is something I've been wondering about for a while but after I saw this video I made me want to do this even more.
I would really very much like to keep my devices from doing anything more than using my network to access the WAN. I do not have wifi anymore; I have gone 100% ethernet. I just use the network to get devices on the internet. I don't need the LAN for transferring files or anything like that. I just want all devices to be invisible and inaccessible to each other.
Is this possible? Is there a way to request such a feature to be added to OPNsense? Or is it there and I am just ignorant of its existence?
Any help is appreciated.
#8
26.7 Series / Re: block events without Label...
Last post by lmoore - Today at 07:30:54 AMThe OPNsense installation I've set up have had the Logging options in Firewall-Advanced enabled by default, with exception to Outbound NAT.
The reason line gives you a clue.
Extract from pf.conf(5)
The reason line gives you a clue.
Extract from pf.conf(5)
Quoteallow-opts
By default, packets with IPv4 options or IPv6 hop-by-hop or destina-
tion options header are blocked. When allow-opts is specified for a
pass rule, packets that pass the filter based on that rule (last
matching) do so even if they contain options. For packets that match
state, the rule that initially created the state is used. The im-
plicit pass rule, that is used when a packet does not match any
rules, does not allow IP options or option headers. Note that IPv6
packets with type 0 routing headers are always dropped.
#9
26.7 Series / Re: Transparent Filtering Brid...
Last post by lmoore - Today at 06:51:06 AMIdeally, you would use a system with at least three internal interfaces.
The management interface should be on an isolated network which is in a different Broadcast Domain to your LAN, and it should never be included in the bridge.
OPNsense has a document how to set up a transparent firewall for IPS - https://docs.opnsense.org/manual/how-tos/transparent_bridge.html
I have a test system where I've installed OPNsense using the serial image, and it has a number of snapshots containing various configurations.
When I set up a new configuration, I'll create a new snapshot and use it. In the new snapshot a factory reset is performed so as to have a fresh configuration.
Include are the steps I use - it may help you. They should also work when performing a factory reset using a VGA console.
N.B: You may be able to apply the same settings when performing a new installation.
At this point you will need to configure your system according to how you will use your Transparent Firewall.
HTH. :)
The management interface should be on an isolated network which is in a different Broadcast Domain to your LAN, and it should never be included in the bridge.
OPNsense has a document how to set up a transparent firewall for IPS - https://docs.opnsense.org/manual/how-tos/transparent_bridge.html
I have a test system where I've installed OPNsense using the serial image, and it has a number of snapshots containing various configurations.
When I set up a new configuration, I'll create a new snapshot and use it. In the new snapshot a factory reset is performed so as to have a fresh configuration.
Include are the steps I use - it may help you. They should also work when performing a factory reset using a VGA console.
N.B: You may be able to apply the same settings when performing a new installation.
Code Select
Configuration Information.
Interface assignments:
em0 -> [MGMT]
igb0 -> [WAN]
igb1 -> [LAN]
Management IP address: 10.200.128.2/24
Management Gateway address: 10.200.128.1
Internal DNS server: 10.199.201.254
Configuration steps to prepare a system as a Transparent Firewall using the Serial console.
Perform a Factory Reset of OPNsense.
- Connect a computer to the serial port on the OPNsense device using a baud rate of 115200
- Power on OPNsense device
Ignore configuration importer
When message appears regarding interface assignment options, press a key when prompted.
- Do you want to configure LAGGs now? [y/N]: <Enter>
- Do you want to configure VLANs now? [y/N]: <Enter>
The list of available interfaces.
Valid interfaces are:
igb0 b4:96:91:8c:a0:f8 Intel(R) I350 (Copper)
igb1 b4:96:91:8c:a0:f9 Intel(R) I350 (Copper)
igb2 b4:96:91:8c:a0:fa Intel(R) I350 (Copper)
igb3 b4:96:91:8c:a0:fb Intel(R) I350 (Copper)
em0 48:4d:7e:ee:1b:4e Intel(R) I219-LM SPT(5)
- Enter the WAN interface name or 'a' for auto-detection: <Enter>
- Enter the LAN interface name or 'a' for auto-detection
NOTE: this enables full Firewalling/NAT mode.
(or nothing if finished): <Enter>
- Enter the Optional interface 1 name or 'a' for auto-detection
(or nothing if finished): em0
- Enter the Optional interface 2 name or 'a' for auto-detection
(or nothing if finished): igb0
- Enter the Optional interface 3 name or 'a' for auto-detection
(or nothing if finished): igb1
- Enter the Optional interface 4 name or 'a' for auto-detection
(or nothing if finished): <Enter>
The interfaces will be assigned as follows:
OPT1 -> em0
OPT2 -> igb0
OPT3 -> igb1
- Do you want to proceed? [y/N]: y
The OPNsense banner after completing the boot process.
*** OPNsense.localdomain: OPNsense 26.7.3_11 (amd64) ***
OPT1 (em0) ->
OPT2 (igb0) ->
OPT3 (igb1) ->
HTTPS: SHA256 6E C9 0B 92 1B AB C9 15 20 B1 D2 76 08 EF 80 98
C4 6F E0 91 4C 04 EE 05 FB FB 34 AA 49 F8 7F F2
FreeBSD/amd64 (OPNsense.localdomain) (ttyu0)
login:
Log in as root.
- Select option 2 - Set interface IP address
- Select 1 - OPT1 (em0)
- Configure IPv4 address OPT1 interface via DHCP? [y/N] N
- Enter the new OPT1 IPv4 address. Press <ENTER> for none:
> 10.200.128.2
- Enter the new OPT1 IPv4 subnet bit count (1 to 32):
> 24
- For a WAN, enter the new OPT1 IPv4 upstream gateway address.
- For a LAN, press <ENTER> for none:
> 10.200.128.1
- Do you want to use the gateway as the IPv4 name server, too? [Y/n] n
- Enter the IPv4 name server or press <ENTER> for none:
> 10.199.201.254
- Configure IPv6 address OPT1 interface via DHCP6? [y/N] <Enter>
- Enter the new OPT1 IPv6 address. Press <ENTER> for none:
> <Enter>
- Do you want to enable the DHCP server on OPT1? [y/N] <Enter>
- Do you want to change the web GUI protocol from HTTPS to HTTP? [y/N] <Enter>
- Do you want to generate a new self-signed web GUI certificate? [y/N] <Enter>
- Restore web GUI access defaults? [y/N] Y
The OPNsense banner after IP assignment.
*** OPNsense.localdomain: OPNsense 26.7.3_11 (amd64) ***
OPT1 (em0) -> v4: 10.200.128.2/24
OPT2 (igb0) ->
OPT3 (igb1) ->
HTTPS: SHA256 6E C9 0B 92 1B AB C9 15 20 B1 D2 76 08 EF 80 98
C4 6F E0 91 4C 04 EE 05 FB FB 34 AA 49 F8 7F F2
0) Logout 7) Ping host
1) Assign interfaces 8) Shell
2) Set interface IP address 9) pfTop
3) Reset the root password 10) Firewall log
4) Reset to factory defaults 11) Reload all services
5) Power off system 12) Update from console
6) Reboot system 13) Restore a backup
Enter an option:
- Select option 0 - Logout
Log in to the WebGUI.
- Interfaces -> Neighbors -> Automatic Discovery
- Enabled: untick
- Click 'Apply'
Update descriptions for OPT1, OPT2 & OPT3.
- Interfaces -> [OPT1]
- Description: MGMT
- Click 'Save'
- Interfaces -> [OPT2]
- Description: WAN
- Click 'Save'
- Interfaces -> [OPT3]
- Description: LAN
- Click 'Save'
- Click 'Apply changes'
Add and assign the Bridge interface.
- Interfaces -> Devices -> Bridge
- Add
- Member interfaces: WAN, LAN
- Click 'Save'
- Click 'Apply'
- Interfaces -> Assignments
- Add
- Description: BRIDGE
- Select device from drop-down list: bridge0 ()
- Click 'Save'
- Click 'Apply'
- Interfaces -> [BRIDGE}
- Enable: tick option
- IPv4 Configuration Type: None
- IPV6 Configuration Type: None
- Click 'Save'
- Click 'Apply changes'
Disable firewall Source NAT.
- Firewall -> NAT -> Source NAT
- Mode: Disable Source NAT rule generation
- Click 'Apply'
Configure Unbound to forward queries to the internal DNS server.
- Services -> Unbound -> Query Forwarding
- Use System Nameservers: tick
- Click 'Apply'At this point you will need to configure your system according to how you will use your Transparent Firewall.
HTH. :)
#10
Virtual private networks / Re: SOLVED - VERIFY ERROR: cou...
Last post by mcdeltat - Today at 01:58:37 AMThis can be marked as solved. I was of course following the docs for the new Instance Based "Road Warrior" setup, which can be found here: https://docs.opnsense.org/manual/how-tos/sslvpn_instance_roadwarrior.html
In there, the tiniest comment "Leaf Certificate - Type Server: Set the Common Name to the FQDN of this machine." bears all the weight here. You must set a CN value, no matter what it is, for things to work. I don't use a FQDN on my router yet, so I had omitted it. I put one that is a subdomain of my actual domain, but is not an actual DNS entry anywhere on my network. The other "Self-Signed Certificate Chains" doc also points to this, saying to put "leaf-certificate.example.com". See: https://docs.opnsense.org/manual/how-tos/self-signed-chain.html
Once I had reissued the certificate the OpenVPN instance was using, I restarted the instance from the Dashboard. I exported the ovpn client file again and imported.
RANT: Can we please get better warnings in OpnSense??!! I've been using it for 7+ years now and every single problem I have pulled my hair on can be chalked down to "UI does not clearly tell you what is a required field or warn you of obvious issues."
If modern OpenVPN/openssl implementations demand a CN, then it should either:
1) Be a required field when creating a new leaf certificate.
2) Flagged as a health status issue up top that says "Your OpenVPN instance certificate chain is missing a Common Name."
I'm tired boss. This took 5+ hours out of a good weekend. A tiny sentence, not in bold, not italicized, with no warnings from the router itself. That took 5 hours.
In there, the tiniest comment "Leaf Certificate - Type Server: Set the Common Name to the FQDN of this machine." bears all the weight here. You must set a CN value, no matter what it is, for things to work. I don't use a FQDN on my router yet, so I had omitted it. I put one that is a subdomain of my actual domain, but is not an actual DNS entry anywhere on my network. The other "Self-Signed Certificate Chains" doc also points to this, saying to put "leaf-certificate.example.com". See: https://docs.opnsense.org/manual/how-tos/self-signed-chain.html
Once I had reissued the certificate the OpenVPN instance was using, I restarted the instance from the Dashboard. I exported the ovpn client file again and imported.
RANT: Can we please get better warnings in OpnSense??!! I've been using it for 7+ years now and every single problem I have pulled my hair on can be chalked down to "UI does not clearly tell you what is a required field or warn you of obvious issues."
If modern OpenVPN/openssl implementations demand a CN, then it should either:
1) Be a required field when creating a new leaf certificate.
2) Flagged as a health status issue up top that says "Your OpenVPN instance certificate chain is missing a Common Name."
I'm tired boss. This took 5+ hours out of a good weekend. A tiny sentence, not in bold, not italicized, with no warnings from the router itself. That took 5 hours.
