Messages

1: Are you sure it is in the list(s)
2: Are you sure you did not first hit the site, and enabled the dns sinklister after this request?

Klopt wat je zegt. Je wilt maar 1 apparaat dat DHCP uitdeelt (de router).
Ik ga even van uit dat je een simpele setup wilt. Gewoon 1x wireless (en geen VLANs).

Je kan je wifi aansluiten op je router direct (port 2). Maar let op. Je *moet* dan routen. Als je normale netwerk bijv 192.168.1.x/24 is dan krijgen clients op je wireless 192.168.2.x/24.
Je moet dan ook weer DHCP aanzetten, firewall rules maken, etc. En je kan dan issues krijgen met broadcast devices (bijv: media devices die je normaal "magisch" ziet).

De makkelijkere oplossing is om je AP op je switch aan te sluiten (als een PC) die hebt hangen achter je router (ga ik van uit).
Stappen in de basis zijn:
* controleer op opnsense de LAN DHCP range. Zorg dat je een IP kiest die *NIET* in de range zit. Als OPNsense 192.168.1.1 is, dan is 192.168.1.2 een goed adres. Weet niet wat de default range is. Maar meestal .50 -> .250 is prima. Alleen range goedzetten is voldoende zodat DHCP nooit 192.168.1.2 gaat "uitdelen".
* connect met je wifi. Meestal heeft zo'n ding al DHCP.
* Ga naar de web interface (goede kans dat die (ook) op 192.168.1.1 leeft)
* Zet in "AP" mode en zet het IP statisch op 192.168.1.2. Je verbinding verbreekt nu.
* Hang de AP aan je switch
* En het zou moeten werken volgens mij....maar het is laat :)

If you suspect a bug you could create a bug report ticket. But i can understand you want to validate using the forum first.

Hi, Please forgive me, I'm new to OpnSense and this forum

I'm hoping someone can help me as I'm unable to find a solution to this.
I have a network configured with multiple subnets and vlans and the admin web gui is accessible from all the default gateways.

Is there anyway to prevent this?

thanks

you need to add a firewall rule to block access to your firewall
ex. guestnet
block, interface guestnet, source any, destination this firewall/guestnet address, port 80/http

for each interface ithink you need to, except your main lan

I think it is better to used the supplied feature of OPNsense itself. And i would assume this will also works after you change the web GUI port.

That said, the best strategy is for "untrusted/guest" networks is to
  * Create a *last* rule to reject RFC1918. -> Meaning a user can go to internet but can not access anything on the lan
  * before this rule i like to create a rule to allow ICMP  to the gateway. This is mainly for (my own) debugging if issues
  * before this rule create any other LAN access exceptions (DNS/NTP, etc.)

This is probably a bug in opnsense. If you know how to reproduce the error you can create a bug ticket.

Being able to do snapshots and backup boot environments (bectl) prior to upgrades is a god-send.

If i understand correctly you can completely rollback? I really miss this feature in OPNsense (compared with TrueNAS). Someone created a guide?

Somewhat related but requested for an entire interface/network: https://github.com/opnsense/core/issues/5712#issuecomment-1404083849

This will probably never happen.

Ubiquity is proprietary and their stuff works only because they control the whole range of devices. Unless the protocol is reversed engineered is will be impossible.

The target audience is not always the same, see reaction Demusman.

Really, devices on a network segments are peers. Hack what you want but you are creating a difficult to manage network.

IOT usually means: it may not connect to LAN (or other segments). Disable connection to the internet.

If you have IOT devices who should not talk to other IOT devices (not sure why you want this) just create another SSID/VLAN (aka: IOT-CAMERA/IOT-DOORBELL) and manage things with firewall rules.

> Additionally, there are some other (non-IOT) devices which occasionally log onto that network for the purposes of debugging and admin (e.g. my desktop workstation) and I need THAT device to have access to the other devices on the IOT network.

Yeah, this is normal. You put this on "LAN". LAN can connect usually to *everything*

Can you add pictures? If i understand correctly you make a common mistake. Block at the incoming (physical) port. So at the DMZ interface you block access to LAN. You do not create this block at the LAN interface page.

It is also conventional to create a RFC1918 alias to block all local IPs. So, at the DMZ interface you block destination RFC1918. The advantage: if you create a extra network in the future it is blocked automatically.

I am happy with my TP-Link Omada. Similar (too similar) with  ubiquiti  but without the requirement running a extra machine/docker to host the software. You have the choice. Run a master machine or configure it directly using the web GUI on the device.

That said, i think ubiquiti software update support seems better.

Not sure how it will work with multiple AP's.

You checked the opnsense API? https://docs.opnsense.org/development/api.html
There also some Ansible libraries supporting opnsense.

You are right, i was not crystal clear. Blocking at Apple stuff and native youtube apps is afaik not possible.
But browser stuff is possible.

Thanks for the tip. Did not know SponsorBlock
You prefer SponsorBlock? Or do you also use uBlock Origin? Both seems open source.

It is not possible to block youtube ads. The video ads are on the same domains as the main content. In the past the IP for adds were different so it was possible to block those.

Also the connections are encrypted so opnsense has no idea what is sent. Afaik this is only possible using browser plugins (ublock origin). The session at this point is decrypted.

i do not see it
https://github.com/opnsense/core/issues?q=is%3Aissue+is%3Aopen+dhcp