New user, unable to set up a static ip interface. What am I doing wrong?

Started by viper3two, August 06, 2025, 02:55:53 PM

Previous topic - Next topic
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 PM
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.
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.