Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - Vilhonator

#1
Sounds like your Unbound can't verify certificate (yes, you need a certificate)

Make sure you have typed correct certificate name (in DNS over TLS settings, edit cloudflare dns record and you should see "verify CN" field), you can find correct record using dig command on linux or nslookup on windows (just type dig/nslookup IP_ADDRESS and you should see the certificate name as a result. Correct one for 1.1.1.1 is "one.one.one.one" without quatation marks, but not sure about other IPs)

This is easy to miss since on WebUI, verify CN isn't visible anywhere else, other than creation or edit window.
#2
Tutorials and FAQs / Re: Unbound DNS Guidance
May 05, 2025, 01:28:55 PM
You can access override rules of Unbound in Services ---> Unbound ---> Overrides

In the overrides window, select + icon under "hosts" which is at the top above aliases

#3
You shouldn't have to open any ports for Zenarmor to work.

Whole idea of Zenarmor is NOT to open any ports you don't need to, just so you could access internet easier.

If Zenarmor doesn't work on your firewall, it means you can't access internet at all, or you have blocked all traffic through https and http ports to servers, Zenarmor downloads its updates from and uploads database files for remote management thingy (Yes, Zenarmor only needs unrestricted access to it's update servers and server, which contains it's Database for remote management). Other than updates and database related things, Zenarmor doesn't need internet access at all to function (that is if you are using default options, but most features which require internet access, are available for you, only if you have paid version)

If you are able to access certain websites, which should be blocked by Zenarmor, all is as it should be (or not. thing is, Zenarmor or any plugin really, won't be able to block everything 100% certainty without manual input. Especially if you use free version).

You won't be able to block access to websites with 100% certainty just based on domain names or IPs alone. You need to use custom blacklists (especially if you use free version of Zenarmor).

Paid version is bit more effective with this, because it unlocks features which give you more effective tools to block things. You still need to put manual input to things though (which is why many think free version is just as good, which is true, for those who are familiar with manually setting everything).
#4
No you don't usually have to restart unbound when you add stuff to whiltelists. If your machine is unable to access domains you whitelist, you need to flush dns records on that machine (on windows, you do that by opening command prompt and type command "ipconfig /flushdns" without quatation marks).

Cron tasks (like almost everything) are logged and you can view them from logs (there is no status page for it, you have to either check the logs under general logs or unbound logs, or read the correct log file on console. You can use filters and search using keywords.)

If by overriding blacklists as in allowing you to access websites containing adult material while blocking your kids gaining access to those websites, I would recommed using Zenarmor. I don't know if Unbound can do that, but BIND can, BIND is just bit more complicated to setup than unbound is and I wouldn't use it on Opnsense, if I didn't have to host local DNS zone.
#5
25.1, 25.4 Production Series / Re: VLAN Problems
April 16, 2025, 08:45:09 PM
First If you have some custom built PC running Opnsense, make sure the network interface supports IEEE 802.1Q (yes, for vlan to work, network interface your opnsense has must support it. Most mainstream consumer market interfaces like cheap realtek NICs don't have that, it is one of few things you have to pay bit more extra. Intel l350 series 1 gigabit NICs aren't that expensive and for 10Gb ethernet, x550 series is solid choice)


Secondly reboot your opnsense if you havent done so, after you finished setting things up and tried if it works. Rebooting is sometimes required for changes to take affect (this should be first thing you should try. I have had my share of similar vlans not working situations, and rebooting fixed the issue on vast minority of cases, but still something worth trying)

If that doesn't work, next make sure the switch port which is connected to opnsense is set to tagged mode for VLAN 10, secondly assign the port your computer is connected to as member or ACCESS mode to vlan 10 (opnsense uses 802.1Q tagged vlan, you have to set port(s) you connect to opnsense and other possible switches to trunk or tagged mode for VLAN 10 and ports you plan to connect your client devices to access mode or member mode for vlan 10 (I am familiar with Cisco terminology, tagged and untagged is something they don't use on hardware I have).

Your LAN belongs to different IP range, which is why you can't ping from LAN to VLAN10 and it is possible, it's a routing issue. to test this, run a traceroute on machine connected to vlan10, on linux system open terminal, and type "traceroute 10.28.74.1" and "traceroute google.com". If both fail, it's obvious routing issue,  easiest way to fix it, is to set LAN and VLAN10 to same private range, in your case, 10.28.74.1/22 for LAN and 10.28.75.1/22 for VLAN10

If that's the case, placing both networks to same private range should fix the issue (since opnsense creates route for LAN automatically by default).

Your switch supports IEEE 802.1Q so there shouldn't be issues there.

To summirize.

Make sure your opnsenses NIC supports IEE 802.1Q (802.1Q for short)

Make sure you have rebooted the system.

Make sure your switch have correct port(s) set as Tagged for VLAN 10 and correct port(s) assigned as member ports of VLAN 10 (I would assume untagged, but might be wrong).

Make sure routing is correct (you are able to traceroute to your VLAN gateway)
#6
Zenarmor isn't able to block or control anything that uses encryption (which nowadays most servers, apps and even smart devices use).

Zenarmor is able to block you gaining access to adult content, as long as your computer isn't using VPN combined with encrypted dns, and domain in question is included in Zenarmors database or custom blocklists.

If you want bit more (free) effective, and effortless way to block adult content, check https://nextdns.io/ or https://adguard-dns.io/en/welcome.html
#7
Oh also disable ClamAV, it doesn't work.

Having antivirus installed on firewall is useless, it can only scan traffic, which is unencrypted (without reverse proxies where data is decrypted before they enter your firewall, all data goes through it unfiltered)

Same with Zenarmor, you aren't able to prevent hackers being able to install backdoors or malware on your machines with it, since all they have to do, is use encrypted connection (discord, https, ssh and list goes on.)

Almost every traffic on the internet is encrypted these days, which reminds me: in command prompt, type "nslookup 192.168.1.1" and try going to the domain instead of using IP (by default I think domain opnsense uses is opnsense.local), if that doesn't work and you use google chrome or firefox, try manually typing https://192.168.1.1:443 on microsoft edge (especially if you hardly ever use it). I have sometimes issues connecting to webgui using IP instead of domain names of certain plugins I use but using domain or clearing all browser data fixes things if time doesn't.
#8
Easiest way to do this is to reset default values.

You can try ssh, if that doesn't work, you need gain physical access to device running opnsense (If your opnsense box doesn't have video output, you need to use console cable, in which case you have to check the serial documentation. All official hardware come with console cable, so all you need is putty, know which serial line to use and what serial speed to use which can be found on documentation).

It is best not to use captive portal unless you have AP that has built in encryption (captive portal doesn't encrypt anything other than passwords, even when you don't have access to internet, wifi traffic is moving locally and it is plain insecure and unencrypted wifi connection, anyone connected to same network is able to sniff traffic on it. And Radius uses MD5 hash, which is no where near hard to crack using websites like https://10015.io/tools/md5-encrypt-decrypt)

If you are familiar with whole webgui stuff, then all you need to do, is access console, choose shell option in console, type pfctl -d (which disables the firewall and you have to manually re enable it with pfctl -e) and hope, it's just firewall blocking your access to webgui. If that doesn't work, you have to pretty much start from scratch.
#9
Also instead of manually having to type IPs (and creating loads of rules), you can simply use aliases, just add your host IPs to aliases.

Alias to apply any host belonging to network 192.168.1.0/24, you create alias, set Type to host and type 192.168.1.0/24 on content.

Alias to apply any host within same private network range as 192.168.1.0/24 is, content is 192.16.0.0/16

for individual local IPs, you don't have to type /24 at the end (as long as they use 24 bit subnet which is 255.255.255.0), just local IP suffices.

for public IPs, subnet bit is required (you can google whois IP and search WHOIS records for any public IP there is, it will display the information you need)
#10
If that is too much work or instructions are too complicated to follow, Optionally you can just add new interface, name it management, add "Block all rule to "Management net" and "block all rule to this firewall" for LAN net, "allow all to this firewall" rule for management interface and "allow DNS for LAN" rule and you are done. Then, everytime you need to access opnsense, you have to connect your PC to LAN interface which is lot safer. To prevent hackers etc. gaining access to your firewall, you should block connections from ANY NETWORKS which has ANY devices connected (including your daily use computer. As long as your computer has access to internet AND your router or firewall, hackers are able to exploit that)

Shortly, you should have 2 networks, 1 that has no internet access and can access all local networks or just your firewall, and 1 that has access only to internet and can't access firewall or router.
#11
If your OpnSense has 3 ports instead of 2 and you don't use IPv6, then easier and bit more secure way to setup what you are intending to do, is to enable all 3 ports and create individual block and allow rules for each interface.

First make sure your opnsense is in a state, where everything works as should (most crucial things are firewall rules blocking all traffic to specific IP and allowing internet access for any device).

If that is the case, backup your current configuration. To do so, go to System ---> Configuration ---> Backups tick "encrypt configuration file" and type your password password (OTHER THAN YOUR USER PASSWORD! this is completely optional, but without encryption, the configuration file is plain text xml file which shows everything from your user names and passwords in plain text!) then select "Download configuration" and select destination where you want to store it.

Next go to firewall ---> NAT ---> Port forwarding and delete any forwarding rules you have created.

After that, go to Firewall ---> Rules ---> WAN and make sure you don't see any rules there.

After that, go to Firewall ---> Rules ---> LAN and make sure you can only see the 2 default allow all rules for IPv4 and IPv6.

Then go to interfaces ---> Assignments and at the bottom, if your opnsense has unused physical ports left you should see "Assign a new interface", on "Description" type "WIFI" or whatever you like and then, Click "Add" option, and save changes after that (if it appears at top of the window).

Now go to interfaces ---> WIFI (or whatever description you gave to new interface) and tick "Enable Interface" for "IPv4 Configuration Type" click box and choose "Static IPv4", and at bottom, Assign IP 192.168.100.1 to it (This must be different from your "LAN" interface, assigning IP belonging to same private range makes things A LOT easier, but if you know which are IP ranges preserved for private networks, you can use any of them)

After that, create another separate backup (next step is tricky and can break things BADLY).

Once you have 2 backups (1 which enables you to undo ALL new changes and another which brings you back to state where you have interfaces configured), go to System ---> Gateways and click add.

Gateway name is LAN, Interface is "LAN", uncheck "Disable gateway monitoring", IP address and monitoring ip both are the IP address of your opnsense LAN interface. Leave others to default values.

If you placed new interface to different ip range, then you need to add another gateway, this way your new interface, changes you make are same as with LAN. If you gave your new interface IP of 192.168.100.1/24 (or anything like 192.168.2.1/24), then you can ignore this part and move to next.

After that, click save and after that, apply changes.

Next go to system ---> Routing ---> Configuration and add new static route.

Network Address is 192.16.0.0/16 and gateway is LAN. If your new interface has different IP range, then you need to create another rule for it and assign correct ranges to it. (I wouldn't recommend, when done wrong, routing can break things BADLY and I can only remember private range which most commonly used 192.168.0.0/24 private network uses)

Routing part can be ignored or at least left inactive untill you have switch and setup vlans (I had some issues with vlans not properly working till I added routing rules, hence I added instructions for that).

After that, click save and apply changes.

Then it is time to make sure that your LAN (at least) didn't loose internet and you can access everything, so connect your PC to LAN port, open command prompt (or terminal) and type "ping 192.168.1.1", if it responds, then ping google.com and also open webrowser and make sure you have access to internet and your opnsense gui. If this fails, well that is what backups are for.

If you didn't get any issues so far, it is time to move on.

Go to Firewall ---> Rules ---> Wifi (or whatever is the name of your new interface) add new rule and follow these instructions TO THE LETTER.

"Action" is "Pass"

"Apply the action immediately on match" is ticked

"Direction" is "In"

"TCP/IP Version" is set to "IPv4"

"Protocol" is set to "TCP/UDP"

"Source" is set to "WIFI net"(or your "interface name" net)

"Destination" is set to "WIFI Address" (or your "interface name" Address, you might have to manually type the IP address, which is under "other" and brings new text box, make sure box next to it is set to /24)

"Destination port range" is set to "DNS"

check the "Log" box and under "Description" type "ALLOW DNS", click save and after that, apply changes (if you can see "Default allow all" rules, move new rule to the top of rule list before applying changes")

After that, click the "clone" option on the left corner of the rules, change "Action" to "block", "Protocol" from "TCP/UDP" to "any", "Destination" from "WIFI Address" to "This Firewall", "Destination port range" from "DNS" to "any" and change description to "block firewall access"

Save and apply changes, make sure the new block rule is below DNS rule.

Clone the new block rule, and change destination from this firewall to LAN net and give it good description. save and apply changes.

After this, if your new interface is missing the apply all rules, create new rule, action is "pass", direction is "in", "TCP/IP Version" is IPv4, source is "Wifi net", T and leave rest to default values (Optionally, you can clone the "allow all" rule from LAN, then you have to just change Interface from LAN and source from LAN net to correspond new interface). Click save, and then apply changes, make sure new apply all rule is at the bottom of the rule list

Then you can proceed to setup DHCP server for new interface.

After you have setup DHCP for new interface, attach the LAN port of your AP to new interface port of Opnsense, connect to wifi on another device and see, if you can get to internet. You shouldn't be able to ping opnsense, nor access webgui or SSH using LAN or WIFI interface IPs or opnsenses public IP address, only DNS should be accessible (under Firewall ---> Log Files ---> Live view you should be able to see any blocked connections to firewall and any allowed connections to DNS).

If all your networks have internet and only LAN interface can access opnsense, then all is as it should be, and you can start testing connectivity in general, if not, then revert back to last working backup.

You can disable logging for any block rules generated at this point
#12
Quote from: Vlad on February 18, 2025, 03:12:18 PMHello. I set up the network in this way: Internet, router, opnsense firewall. There was a problem with the IP, I set LAN 192.168.50.4 and WAN 192.168.50.92 and nothing works. I can't log in to the web interface. Please tell me how to solve the problem, it is very necessary.



I am assuming you are trying to setup opnsense for home use, from your post, it doesn't seem you are trying to do anything else.

Simply remove router from your setup. You won't be able to place opnsense behind a router with static private IP address assigned to WAN (basic network 101: Each interface of each router must belong to disjoint subnet to be able to control traffic) and without setting up transparent filtering, opnsense is just plain router with firewall, IDS/IPS and plugin functions.

So your setup should be either any of the following listed from easiest and least amount of configuration requiring way to setup to hardest and most configuration requiring way to setup:
 
  • Internet ---> OpnSense ---> Client
  • Internet ---> Opnsense ---> Switch ---> Clients
  • Internet ---> Opnsense ---> Switch ---> AP ---> Clients
  • Internet ---> OpnSense ---> AP ---> Clients
  • Internet ---> Opnsense ---> Router which has DHCP, NAT and Firewall disabled ---> Clients

WAN IP should be a public IP address, asigned by your ISP using DHCP. and you don't access to opnsense using WAN address, LAN is for that.
#13
24.7, 24.10 Legacy Series / Re: Problems accessing WebUI
September 03, 2024, 10:50:31 PM
Glad that your problem was that minor. I would just want to give small tips, incase you ever loose access to web GUI ever again.

As long as issue is just not being able to connect to WebGUI, in most cases all you have to do, is access the console via SSH or physical method and either select restore backup. By default, opnsense automatically creates an backup everytime, you make changes to system. Now it does start overwriting oldest backup after x amount of changes made (can't remember what default value is, since I changed mine, but it is quite high and propability it working is high, as long as last 20 or so changes caused the issue).

As long as you have access to console, you are able to either revert to quite a few last automatic backups named on date and time they were created (unless you have disabled it) or less safe option which is disabling firewall from shell.

Best practice would be creating backups before and after you have made changes to the system, or configure automatic backups (https://docs.opnsense.org/manual/how-tos/cloud_backup.html) in which case you are always able to just reset everything to factory defaults ;)
#14
24.1, 24.4 Legacy Series / Re: Try to NAT port 53
July 19, 2024, 12:52:04 AM
On consumer internet contracts you won't be able to host your own DNS server which is open to internet, you need to either host that DNS on VPS like azure or AWS or setup VPN or proxy.

ISPs of most countries block incoming DNS traffic on UDP 53 to prevent people being able to mess up global DNS servers and DNS spoofing, outgoing smtp traffic on TCP 25 to prevent spamming and few other ports only hosting companies like google, amazon AWS, Microsoft and Eila Kaisla need, in fact some countries (for example Finland for one) even have laws which obligate ISPs to do that.
#15
Quote from: yutzin_sea on June 13, 2024, 04:50:01 PM
Thanks so much for the reply.

My switch is an HP ProCurve J9298A and I believe, if I'm looking at the documentation right, the ports support IEEE 802.3/802.3u/803.2ab.  It seems like it's a few versions ahead of 802.1Q, but perhaps they are different standards?  This is my first major foray into networking so I apologize for not knowing.

Given the above, would you still suggest enabling IEEE 802.1Q/VLAN tagging on the Windows network adapter?  I'm happy to try anything at this point.

You can try enabling it. Assigning VLAN ID on the network adapter should solve the issue, only downside is, that you have to do so, with each windows client on your network.