I purchased a HUNSN firewall with 5 interfaces. I installed OPNSense, and it sees the interfaces, it set up the lan 192.168.1.1 and wan ports as default and I am able to access the web gui at that address. I want to add a 3rd port for management on our 10.x.x.x network. I am able to see the interface, assigned it to ign2 hardware, and set up the ipv4 address on it. I set ipv6 to none. I have a cable running from that port to a switch on our 10.x.x.x network. I am unable to get to the web gui on the 10.x.x.x address I assigned it, and unable to ping that address. I even went as far as creating a gateway that matches our asa and marked it upstream gateway. That didn't help, still unable to ping or see. I set up an allow all rule for that interface as well, that didn't help. What am I doing wrong or missing? I just want to set up a static 10.0.0.0 IP on that port and be able to access the firewall opnsense. Thank you in advance.
The basics: Check for address typos. Check the interface state (e.g. in "Interfaces: Overview"), and ARP ("Interfaces: Diagnostics: ARP Table"). If ARP entries are present for the interface, make sure they are correct. Check them also on your client(s) ("arp -a" on most OSs). If the interface and ARP are good, try pinging from the firewall ("Interfaces: Diagnostics: Ping") (assuming the device you are pinging does not have its own firewall filters, e.g. Windows). You can check rule behavior using "Firewall: Log Files: Live View" (e.g. when pinging from a client).
Remember to clean up any test config (such as the gateway, assuming it is not required).
Quote from: pfry on August 06, 2025, 03:23:05 PMThe basics: Check for address typos. Check the interface state (e.g. in "Interfaces: Overview"), and ARP ("Interfaces: Diagnostics: ARP Table"). If ARP entries are present for the interface, make sure they are correct. Check them also on your client(s) ("arp -a" on most OSs). If the interface and ARP are good, try pinging from the firewall ("Interfaces: Diagnostics: Ping") (assuming the device you are pinging does not have its own firewall filters, e.g. Windows). You can check rule behavior using "Firewall: Log Files: Live View" (e.g. when pinging from a client).
Remember to clean up any test config (such as the gateway, assuming it is not required).
Thank you for this information. I am going through everything you suggested and will report back.
First, let me apologize in advance for my answer. I recently did something similar on a Chinese commodity 4 port PC, but it's a lab PC at this moment and put away. I am doing this from memory so it will help you, but also be a little incomplete.
Also, keep this in mind. during my experience above, I noticed that OPNsense sometimes hides necessary entry fields and will not show them unless you either check or uncheck a box that's vaguely marked. It was very annoying. This was not noticeable until I tried to add another interface. The default original load for WAN and LAN only had no issues.
You set up rules, so that's good. They are very easy in this case and fairly intuitive.
In my case, I copied the two LAN default rules over to the new interface and changed accordingly. Then on top I added a rule to keep the new interface out of LAN since the new subnet needed to be isolated from LAN. (I don't know how much if any of this would be default behavior, anyway.)
This MAY solve your problem .... the new interface has no DNS server. You need to add an override DNS server such as 8.8.8.8, 9.9.9.9, or 1.1.1.1. Depending on your DHCP server, the override fields are obvious or hidden. I don't use DNSMASQ so look around if you are using that one. ISC has the override field in plain sight. KEA has a vaguely marked box you need to UNCHECK to find the hidden override DNS server field.
Populating the hidden field on KEA with 9.9.9.9 brought my new subnet to life immediately (On Windows, don't forget to run ipconfig /release and ipconfig /renew as Windows sometimes does not like to cooperate when subnets change suddenly.)
Good luck.
If that doesn't work, look again at the firewall rules. Also, make a good backup. I did a lot of experimentation to solve my problem and knocked out the whole router. I needed to go to the console, do a factory reset, and reload from a good backup.
Quote from: coffeecup25 on August 06, 2025, 06:07:45 PMYou need to add an override DNS server such as 8.8.8.8, 9.9.9.9, or 1.1.1.1.
IMHO you should use your OPNsense as the local DNS resolver for all your clients instead of pointing your clients at a public resolver.
Quote from: Patrick M. Hausen on August 06, 2025, 07:04:15 PMQuote from: coffeecup25 on August 06, 2025, 06:07:45 PMYou need to add an override DNS server such as 8.8.8.8, 9.9.9.9, or 1.1.1.1.
IMHO you should use your OPNsense as the local DNS resolver for all your clients instead of pointing your clients at a public resolver.
Well, I agree unless doing that doesn't work. Then you use the override dns servers.
The router main setup page uses the public servers the user entered unless you are using the isp dns server by default.
This is also very commonly done if you are using pihole or Adguard Home on local home servers.
Quote from: coffeecup25 on August 06, 2025, 07:16:12 PMWell, I agree unless doing that doesn't work. Then you point to the override dns servers.
I prefer to make things work that should by finding the root cause of the failure. And I do not use public resolvers at all.
Quote from: Patrick M. Hausen on August 06, 2025, 07:18:34 PMQuote from: coffeecup25 on August 06, 2025, 07:16:12 PMWell, I agree unless doing that doesn't work. Then you point to the override dns servers.
I prefer to make things work that should by finding the root cause of the failure. And I do not use public resolvers at all.
Surprise. Then you're using your ISP's resolver, which may be google or anyone else. There is no 'official' DNS resolver. They follow a hierarchy I won't pretend to understand because it's not relevant. But, the ones we all use are public DNS servers at one level or another.
Also, it's just possible that an ISP DNS resolver is used to aggregate information to sell for a little extra cash. Therefore, public resolvers with the right retention policies are actually much more private.
Quote from: coffeecup25 on August 06, 2025, 07:59:06 PMSurprise. Then you're using your ISP's resolver, which may be google or anyone else.
No I am not. Unbound is a perfectly capable recursive DNS server that does not need any upstream.
I am an ISP. I have been doing this for three decades. Don't try to teach me DNS fundamentals.
And I perfectly understand the DNS hierarchy and how it is supposed to work - surprise.
Quote from: Patrick M. Hausen on August 06, 2025, 08:10:06 PMQuote from: coffeecup25 on August 06, 2025, 07:59:06 PMSurprise. Then you're using your ISP's resolver, which may be google or anyone else.
No I am not. Unbound is a perfectly capable recursive DNS server that does not need any upstream.
I am an ISP. I have been doing this for three decades. Don't try to teach me DNS fundamentals.
And I perfectly understand the DNS hierarchy and how it is supposed to work - surprise.
Well butter my rear and call me a biscuit. I didn't know that. Until now, I thought unbound was only software and a dns program. I didn't know it was a complete enterprise.
Same question ... What makes unbound pure and the other not so pure? It's all information that comes from out of your control. Unless you personally are unbound and speaking for yourself.
How does unbound make its money? Offering free 100% reliable DNS to the world must be very expensive. I'm sure it doesn't come from the air like electricity comes from the wall.
Unbound isn't a service but a local recursive DNS server. It's maintained by volunteers like so many open source projects. You just run it locally, e.g. on OPNsense.
Any fully recursive DNS server - Unbound, BIND, djbdns (*gasp* the author is ... difficult to say the least) does not need a fixed upstream "service" to resolve names on the Internet. DNS is a *distributed* database. That is the point.
I explained it all in detail here:
https://forum.opnsense.org/index.php?topic=22760.msg108462#msg108462
HTH,
Patrick
Quote from: Patrick M. Hausen on August 06, 2025, 08:25:51 PMUnbound isn't a service but a local recursive DNS server. It's maintained by volunteers like so many open source projects. You just run it locally, e.g. on OPNsense.
Any fully recursive DNS server - Unbound, BIND, djbdns (*gasp* the author is ... difficult to say the least) does not need a fixed upstream "service" to resolve names on the Internet. DNS is a *distributed* database. That is the point.
I explained it all in detail here:
https://forum.opnsense.org/index.php?topic=22760.msg108462#msg108462
HTH,
Patrick
It's still information out of yours, and mine, and everyone else's control. Public DNS servers offer other capabilities than DNS, like filtering and no record retention, or so they say.
And, to return to the original point, sometimes you need to use a public server to solve a problem. Especially since there's absolutely nothing wrong with using one.
Edit: I think I figured out why there needs to be a public DNS server entered.
I looked up unbound and how it works. Omitting the DNS hierarchy because it's a black box essentially, unbound is a program that queries a database for an ip address. It may ask a few times, before it gets the right answer, but it gets it or it doesn't. It's basically a series of function calls from a programmer's point of view. Then it caches the reply for later use if needed. Public dns servers do the same thing but make money at it one way or another.
OPNsense appears to tie unbound to the primary LAN. If a new subnet is locked out of the primary LAN, as most would be, then subnet #2 might not find unbound depending on the firewall rules. I could not bypass my port 53 / 5353 situation because OPNsense protected those fields on the rules page. Therefore, a public DNS server is needed.
Also, as I wrote above, accessing pihole or Adguard Home on a home server would also necessitate an override DNS.
Quote from: coffeecup25 on August 06, 2025, 08:33:54 PMthen subnet #2 might not find unbound depending on the firewall rules.
That's why you need to add rules for local services like DNS or NTP.
Works perfectly well.
Quote from: Patrick M. Hausen on August 06, 2025, 09:15:39 PMQuote from: coffeecup25 on August 06, 2025, 08:33:54 PMthen subnet #2 might not find unbound depending on the firewall rules.
That's why you need to add rules for local services like DNS or NTP.
Works perfectly well.
I tried for an hour off and on and the port override fields were locked. No entry permitted. There's heroics and maximum effort, and there's getting the job done in a perfectly acceptable way that is easy for another person to figure out and maintain later if needed. As I said, Unbound as a dns server is a convenience, but there's nothing pure and true about it. I'm using it as a program that only coordinates. The function calls to the database of dns addresses are not needed. Especially since it does not work properly in my situation without heroics being involved.
I also added a couple of NTP servers in the hidden fields, just because. I didn't want a rude surprise later in case one was coming.
All, I am totally new at this. Maybe if I explain a bit further it would help. I am going to set this up on our local network at work, between our asa and the lan. I found an article on how to create a transparent bridge and got the hunsn firewall since it had several interfaces. I was able to flash opnsense (it came with pfsense), and was able to connect a laptop to the lan port and see the web interface at 192.168.1.1. I was wanting to set up an interface so that I could connect it to our local lan to see the web interface, and that is what I am attempting to do. Our local lan is on 10.x.x.x and it is /21. Our local lan has NO dhcp servers or services running, so everything on our network is static IP. I have a free ip to use for the interface, and I set it up using that IP. I also set up a pass firewall rule to pass everything in/out on that interface. We do have a dns server on our local lan which is our domain controller. I don't know where to enter that information so the interface sees it. I can go to the statistics and it shows entries coming in but not going out of that interface, and I am unable to ping it either. I do see other devices on our local lan on the stats so I know it is seeing the network, but still unable to access the web interface using that IP or ping it. Is this possible? My basic high level idea was create a transparent bridge for filtering traffic. Thank you, and again I am totally new at setting this up. I am studying all I can on this to figure it out.
Quote from: viper3two on August 06, 2025, 09:53:19 PMAll, I am totally new at this. Maybe if I explain a bit further it would help. I am going to set this up on our local network at work, between our asa and the lan. I found an article on how to create a transparent bridge and got the hunsn firewall since it had several interfaces. I was able to flash opnsense (it came with pfsense), and was able to connect a laptop to the lan port and see the web interface at 192.168.1.1. I was wanting to set up an interface so that I could connect it to our local lan to see the web interface, and that is what I am attempting to do. Our local lan is on 10.x.x.x and it is /21. Our local lan has NO dhcp servers or services running, so everything on our network is static IP. I have a free ip to use for the interface, and I set it up using that IP. I also set up a pass firewall rule to pass everything in/out on that interface. We do have a dns server on our local lan which is our domain controller. I don't know where to enter that information so the interface sees it. I can go to the statistics and it shows entries coming in but not going out of that interface, and I am unable to ping it either. I do see other devices on our local lan on the stats so I know it is seeing the network, but still unable to access the web interface using that IP or ping it. Is this possible? My basic high level idea was create a transparent bridge for filtering traffic. Thank you, and again I am totally new at setting this up. I am studying all I can on this to figure it out.
I'm going to be blunt. I didn't even try to read through all your confusion. We were all beginners once. I have a rather complicated home system and I don't do anything as complicated as what I think you were trying to describe.
Unless there's a reason not to, just build a basic lan. Get is working. Then add the missing parts you need, not the ones you think you might need because you think you heard someone say something.
Adding a 2nd subnet is easy. It sounded like you already did that. Do the rules thing I mentioned above. Then add a dns server to the dhcp. You will connect to the internet. Use unbound as the selected dns server but forget unbound as this magical complex thing.
If you need more, then it's a new problem.
Quote from: coffeecup25 on August 06, 2025, 08:33:54 PMQuote from: Patrick M. Hausen on August 06, 2025, 08:25:51 PMUnbound isn't a service but a local recursive DNS server. It's maintained by volunteers like so many open source projects. You just run it locally, e.g. on OPNsense.
Any fully recursive DNS server - Unbound, BIND, djbdns (*gasp* the author is ... difficult to say the least) does not need a fixed upstream "service" to resolve names on the Internet. DNS is a *distributed* database. That is the point.
I explained it all in detail here:
https://forum.opnsense.org/index.php?topic=22760.msg108462#msg108462
HTH,
Patrick
It's still information out of yours, and mine, and everyone else's control. Public DNS servers offer other capabilities than DNS, like filtering and no record retention, or so they say.
And, to return to the original point, sometimes you need to use a public server to solve a problem. Especially since there's absolutely nothing wrong with using one.
Edit: I think I figured out why there needs to be a public DNS server entered.
I looked up unbound and how it works. Omitting the DNS hierarchy because it's a black box essentially, unbound is a program that queries a database for an ip address. It may ask a few times, before it gets the right answer, but it gets it or it doesn't. It's basically a series of function calls from a programmer's point of view. Then it caches the reply for later use if needed. Public dns servers do the same thing but make money at it one way or another.
OPNsense appears to tie unbound to the primary LAN. If a new subnet is locked out of the primary LAN, as most would be, then subnet #2 might not find unbound depending on the firewall rules. I could not bypass my port 53 / 5353 situation because OPNsense protected those fields on the rules page. Therefore, a public DNS server is needed.
Also, as I wrote above, accessing pihole or Adguard Home on a home server would also necessitate an override DNS.
You seem to be misunderstanding the way a dns recursor works. Unbound in this case. It does not query a database as a programmers' function at all. It queries the root servers from the top down and yes public dns servers but that is a different argument between which is better and from which perspective public root servers vrs a commercial one. What you also want to remember is that in any case, these commercial ones don't have a copy of the records (putting caches aside). They must go to the the same root servers to get the answers ie. that's where their records come from.
That means you either get the answers from the roots or you ask google 8.8.8.8 to get them for you.
As to Unbound tien to the primary lan. The recommended way is "all interfaces" and rules will take care of only allowing those wanted. LAN rules include the permission. Other new networks need to have the relevant rule(s) added.
For filtering the results you can always use your own. Unbound has its own but personally I prefer AdGuardHome. Then similarly I filter it or someone else for me? I rather get the results as intended and filter myself if needed. But that is the part where a is IMHO a more personal preference, not a technical one.
cookiemonster,
Thank you for your reply.
Regarding my understanding of DNS Servers, you are correct from one point of view that I did not describe them well.
However I stand by my point that the DNS source data is a 'black box' from the far downstream user's perspective. It is in no way essential to understand for the public DNS System to parse out an ip address from a name. It only has to work. The user only has to enter a name in a url or click on a link.
The programmer has to understand how to properly query a database of ip addresses in order to get the required information.
The problem with DNS Hierarchy explanations is that they are all horrible, generally speaking. Nobody can ask a simple question without getting an overflow of non-essential and over-complicated explanations about how the parsing is done. From a programmer's point of view, Upstream DNS servers are a database that needs to be queried properly. That's it. There's nothing magical about them although they are probably one of the most amazing inventions in the world.
Unbound is only a program that queries the DNS Database (I'm calling it a database to remove the mystique). It also coordinates ports in use for where to listen for DNS information between the downstream application and the router. I'm sure it does a lot more.
Until a couple of days ago, Unbound was only a name for something people seemed to talk about with reverence and otherwise seemed too out there to comprehend. I don't claim to be any kind of expert, but nobody needs to be to use it.
Unbound appears to be something nobody needs to think about unless you do something out of the ordinary with your router. I added a 2nd subnet for IoT and wrote rules to keep it completely apart from the main LAN subnet. These rules apparently locked unbound out of the new subnet also. Therefore, the need to use overide DNS servers in the DHCP Server Page to access the internet. This technique is common, and may be also essential, to send DNS queries to pihole or Adguard Home if they are on separate home servers on the home lan. My experience is this is the standard way to get to them.
Adding 'relevant rules' to bypass the one that kept the subnets apart was impossible for me as the port fields were protected from entry. Plus, I was not looking forward to the trial and error that would have been required as nobody is born with the knowledge to do this. So I used 'plan B' and I did it the common ordinary and real easy way by using the dns server override fields on the DHCP page for the IoT subnet. Worked like a charm. (Why put those entry fields there if they are not supposed to be used? Even though OPNsense hides them on KEA. I'm starting to wonder if that is politics rather than a simple programming error. If it is politics then that is a mistake. That would mean very fussy users are the driving force behind the design of a product intended for general use. Not good. Routers like OPNsense can be complicated simply to make them do what the users need. Adding religion into it makes it much harder to even understand.)
There are dozens of large public DNS servers that are in common use and perfectly safe. Adguard offers one that can be accessed using several techniques. It's safe and provides excellent ad blocking. I use their free public one on my phone by their dns number. Unbound is an amazing program that does far more than I imagined a couple of days ago, but there's nothing pure or holy about it. I need it to coordinate DNS ports between Adguard Home on OPNsense and the main router. I also have several outside DNS servers noted on various places in OPNsense. All are quite safe. None are the back-alleys that some people like to scare others about.
OPNSense has many options and with them comes complexity. Then with that it behaves less like a consumer router. Maybe that is why you encountered problems.
Maybe I misunderstand what you are saying but when you create a new network, you have to set it up including the relevant rules to access what it needs. Default is block (LAN is the exception).
I don't understand either what entry fields you refer to that aren't to be used. I am very sure that all elements of the UI have a purpose.
Back to topic...
Quote from: viper3two on August 06, 2025, 09:53:19 PM[...]
I do see other devices on our local lan on the stats so I know it is seeing the network, but still unable to access the web interface using that IP or ping it.
[...]
How's it going? Were you able to see ARP on your OPNsense machine and your client(s)? On OPNsense, you should see entries for your 192.168.1.0 network; the entries for the 10.x.x.x net should look similar (both local and remote MACs).
If you have good ARP, have you tried watching the firewall live log when pinging the OPNsense machine? (You want to have the log view up when you start the ping.)
Quote from: pfry on August 08, 2025, 05:35:51 AMBack to topic...
Quote from: viper3two on August 06, 2025, 09:53:19 PM[...]
I do see other devices on our local lan on the stats so I know it is seeing the network, but still unable to access the web interface using that IP or ping it.
[...]
How's it going? Were you able to see ARP on your OPNsense machine and your client(s)? On OPNsense, you should see entries for your 192.168.1.0 network; the entries for the 10.x.x.x net should look similar (both local and remote MACs).
If you have good ARP, have you tried watching the firewall live log when pinging the OPNsense machine? (You want to have the log view up when you start the ping.)
Yes sir, I was able to resolve it. I did see arp on the opnsense machine and clients, all good there. I viewed the firewall log and found it was an issue with our internal gateway. In our facility there are 2 separate asa's. I found that when I switched to the older gateway, it worked. I could ping the opnsense and I was actually able to proceed on and build a bridge, and I am now working with configuring to work with intrusion prevention module to stop the brute force that we are getting. I am glad I was able to get this far with it, just have to learn more on the intrusion prevention module. Thank you for all the help.