Messages

Hi emwe,

thank you so so much for your detailed answer, that fully explained everything what i had in mind.
For the clients it's probably easier (for now) to route traffic via VPN to the firewall, if it's really that important to encrypt all traffic inside the LAN.
Lovely feature. I hope it will get some more support for an "official" BSD/OPNsense release via GUI.
That would be cool.

About the doc file.. i will try different OS and networks as well, maybe it's just my PC acting weird, since some pictures are there and others are not.

Pretty late answer, probably better than never :D but here is how:

>>    System: Settings: Administration

There you see "SSL Ciphers". You can tick the ones you like. I am not really sure if they are Web-GUI or SSH based or even for the whole system. After ticking and saving you should check if SSH is now working as expected with the right ciphers selected. Please make sure to check if you are still able to access the GUI after saving your changes, since all the administration is Web-GUI based. Changes in config files are rarely saved and are gone after reboot as long as they are not made via GUI.

[One question about the technical setup:]

Hi emwe,

i opened the link and downloaded the file but still, there are some pictures left not showing at all, no matter how i try to open it. :(

One question about the technical setup:
i am pretty new to dnscrypt. Am i correct to say that dnscrypt-proxy is "collecting" all DNS traffic like a proxy for the LANs asking the Firewall on port 5353 and then forwarding the queries via the standard port 53 to the servers configured in the config file? How is dnscrypt achieving encryption to the DNS servers configured in this case? Is local Traffic to the Firewall Unbound encrypted as well? Just curious but did you test that your traffic is now really encrypted or did you just "guessed" it to work?

Sorry for all the questions  :-X

Thanks for your work though and for sharing the doc! :)

[If Proto Sourc-Address Ports Dest-Address Ports NAT-IP Ports Description]

Hi incirrata,

really funny to read that post here. I had the same problem a few days ago. :D
To be honest i did not find a "clean" solution for that, since i tried the same like you, writing a DNS override, which doesn't work.

What i did as a workaround which worked fairly well is the following:
(Firewall -> NAT -> Port-Forward)

If    Proto    Sourc-Address    Ports    Dest-Address    Ports    NAT-IP    Ports    Description
VLAN_USER    TCP    192.168.X.X/XX    *    This Firewall    <Web-GUI Port>    192.168.X.X    <Web-GUI Port>    [VLAN_User] Web-GUI Administration only on one Interface

You have to create different Port-Forward rules for different source-subnets, which will likely to ask the firewall for it's web-GUI address. "This Firewall" is a Default Alias, which listens on every interface for every gateway-ip in all your different subnets, configured to use the firewall. -> You do not need to create this Alias, it's there by default. :)

[OpenVPN-Server Configuration:]

Hey guys,

i need a little help to understand how exactly OPNsense handles it's Tunnel-subnets for an OpenVPN-Server, when also combined with Client-Specific-Override settings to create Admin and User Subnets for different use-cases.

I have a fully working Roadwarrior OpenVPN-Server with Multifactor-Auth for my admin users. They can login without problems. As soon as I instead want an User to login to the same OpenVPN-Server they get a subnet, which should work (in theory), but just isn't able to find the gateway it seems.

OpenVPN-Server Configuration:
- 3 User: A-RoadWarrior [User] ; B-Roadwarrior [User] ; C-Roadwarrior [Admin]
- 1 OpenVPN-Server ontop of OPNsense with the following IPv4 Tunnel Network: 172.31.250.248/29
(3 IP's are used for Net-address, Broadcast and OpenVPN-server-gateway --> 5 useable Admin IP's)
- Redirect Gateway: [X]
- Address Pool: [X]
- Topology: [X]

OpenVPN-CSO Configuration:
- A-RoadWarrior IPv4 Tunnel Network: 172.31.250.240/29
- B-RoadWarrior IPv4 Tunnel Network: 172.31.250.240/29
- C-RoadWarrior IPv4 Tunnel Network: 172.31.250.248/29
- Redirect Gateway [X] for all three users

--> User Clients and Admin Clients are able to connect to the VPN-Server on my OPNsense and get an IP/Subnet assigned shown in my CSO-Configuration. The Admins can freely browse and administrate and the user can't even access IP-addresses via web. (The firewall rules are correct though - Outbound-NAT is working as well)
When a User Client get's assigned the 172.31.250.248/29 subnet instead they can browse and work as expected

My thoughts:
- I guess the problem here is that the server doesn't know about the 172.31.250.240/29 network,
since it's only configured tunnel-network is the 172.31.250.248/29 for the admins.

- I could probably create a second OpenVPN-Server to split both user-groups, BUT i need the Server to only listen to TCP/443 to insure that no matter what, the user or admin clients are always able to get out of the remote network. Both VPN-Servers won't probably listen to the same TCP/Port so that won't work I assume.

- The CSO passes the IP, configured in the tunnel-network no matter what, which is odd. So in my case both User A and B will get the IP 172.31.250.240/29, which is the Net-address. They will also steal each others IP's. The fun part is that I am able to give my Admin Client C the IP 172.31.250.248/29, which again is the Net-address but this time it will work, even though the User should not know how to reach the gateway-address with such an IP.

Any idea how to utilize subnets correctly in this scenario? I am probably overlooking something obvious here. :( Thanks for any help! Much appreciated!

@Maurice

There won't be any forwarding because it's not required. If dnsmasq and unbound are disabled, the DHCP server assigns the DNS servers configured on the General page to the clients. So the clients query the Google DNS servers directly. In this scenario OPNsense is not involved in DNS at all.

Okay that's a legit point but here is my second question:
How is the OPNsense itself going to lookup hostnames?  ???
As far as i know, searching for updates, aka. "check updates" will probably not work anymore or will OPNsense just use the DNS configured in the general page aswell, even without any forwarding feature enabled? Never had this setup before so i am really curious. :)

@comet i really didn't wanted to respond again but here we go...

Now to me, that came across as "I'm not going to answer the question you asked, but instead the one I think you should have asked, and I'll say 'sorry' but I'm really not."

It was a joke... this "sorry, not sorry" is just a meme. The "Glad you asked." part aswell. It's just that Unbound is insanly powerful with it's resolving feature in addition with DNSSEC that i did not understand why on earth someone would want to use Google DNS with both unbound and DNSmasq disabled.
Using Unbound instead of any weird google DNS was such a "no-brainer" to me that i tried to be funny.
... I failed hard obviously.
I explained every checkbox and every step in my inital post.
Instead of going full rampage on me you could have answered:
"cool, i didn't know that there is this kind of feature but i am still unsure about the consequences and advantages as opposed to just using the Google DNS, could you please go more into detail?"
I would have happily responded with more hints and details but not this way....
I am not getting paid to help you and this forum is free for everyone.
If you don't like "us" then leave, it's that simple and easy.

Best regards,
Oxy

[net.inet.tcp.rfc1323=0]

will this value be overwrite  after the updates ?

probably, sadly. :(

If you find some time, can you check if it is enough to add net.inet.tcp.rfc1323=0
to the tunables in [System: Settings: Tunables] ?
This may work aswell and even survive any upcoming updates. Besides that i would recommend to write down all these tunables somewhere, in case an update wrecks all additional made settings. :)

[[X] Enable Forwarding Mode]

Uncheck this. This will disable unbound completely and Google's DNS servers will be assigned to your clients.
When it's disabled, all other unbound settings don't matter.

If DNSmasq AND Unbound are disabled, who is going to do the forwarding to the Google DNS? ;)

You will need to keep Unbound enabled but with this option checked:
[X] Enable Forwarding Mode
This will tell Unbound to not use the resolver "feature" but instead use the Google DNS Server configured in
[System: Settings: General] aka forwarding all requests to Google. That's why it is called "Forwarding mode".
The rest was correct @Maurice :)

@comet i don't feel like you really want to learn something new so i will not explain or go further into detail about the steps, since it won't matter for you anyway. Besides that you should really learn the difference between "Resolving" and "Forwarding" when talking about DNS.

@douglasg14b Thanks alot. :) These steps will lead to a functioning and trusted DNS configuration using the root-DNS-Servers: https://www.iana.org/domains/root/servers
Unbound is really powerful this way. :)

[--> nrpe2 plugin is already existing... but not with predefined checks indeed. You have to "craft" them yourself.]

Long time ago i once had to configure a setup with Nagios+OPNsense, where nrpe2 was used + encryption to do NAGIOS checks on the OPNsense Firewall. If you want i can search in my Forum history and i may find something useful. :) I even made a post back then, because it was so hard to configure it so there is proof somewhere.
--> nrpe2 plugin is already existing... but not with predefined checks indeed. You have to "craft" them yourself.

[--> Services: Unbound DNS: General]

The problem with any ISP DNS is the interception/redirection/hijacking of your DNS queries.
Google DNS is "ok" but not the best solution if you really want performance and high availability for your DNS-Client queries.

I will rephrase your question so that it works the best for you ;) Sorry, not sorry. ;)

How do i configure DNS Unbound to use the local Unbound cache and ask root-DNS-Servers only, while at the same time make sure the queries send out to these servers, are all legit and can be trusted using DNSSEC?

Glad you asked. :P

--> Services: Unbound DNS: General
1. make sure it's enabled (obviously...)
2. [X] Enable DNSSEC Support
3. [ ] Enable Forwarding Mode <-- Do NOT activate this box or Unbound will start forwarding all DNS Traffic to the upstream DNS-Servers configured in [System: Settings: General] and you do not want this to happen.
4. [X] Register DHCP leases in the DNS Resolver <--- makes sure that you can lookup your local hosts
5. [X] Register DHCP static mappings in the DNS Resolver <--- makes sure that you can lookup your local hosts
6. You can change the advanced settings if you want to harden DNSSEC, but sometimes it breaks the lookup, so trial and error these settings if you feel like it and leave ALL other options on default settings.

--> System: Settings: General
1. DNS servers <-- these Servers you put in here are not used, aslong as Unbound is not working in Forwarding Mode, so just leave it as default, since we are using the "Resolver" Option for Unbound. Just for the record, if you are not doing any Multi-WAN fancy stuff, just for your own sanity leave "use gateway" on "none". :) In our Unbound Resolving configuration they are not used anyway.
2. [ ] Allow DNS server list to be overridden by DHCP/PPP on WAN <-- no tick, because you don't want your ISP to override any configuration you do on your OPNsense.
3. [ ] Do not use the DNS Forwarder/Resolver as a DNS server for the firewall <-- this should not be ticked, so that OPNsense is able to use it's local cache for lookups.

Thats it. I may overlooked something, but thats it for unbound on OPNsense.
Additionally the only Firewall Rule you need is the one that allows LAN Clients to reach OPNsense on Port 53 in there specific subnet. That should be it for DNS. :)

Have fun. :)

Best regards,
Oxy

How Unbound works: https://calomel.org/unbound_dns.html

[EDIT]

@[Services: Unbound DNS: Access Lists] All the internal configured ACL's are automatically configured for all the Subnets/Interfaces, unbound is configured to listen to under
[Services: Unbound DNS: General] ---> "Network Interfaces".

Quick note here: If you are not planning on using DNSmasq[Forwarder] and Unbound[Resolver] at the SAME time, you probably should leave this setting on "All". Otherwise you may end up with Interfaces/subnets not being able to send DNS lookup queries to your Firewall. :)

I obviously did not work on it day-in and day-out but a fair amount of time. :D
1-2 hours every week, until everything got finished. :)

Basically i wanted to separate my VLAN_Subnets into two groups.
1 group that is allowed to use the outgoing VPN-tunnel traffic without leaks and
one guest VLAN Subnet group, which should leak intentionally for guest users or working from home users.

In the end all the tiny settings and ticks i had to set or not set so that there were no leakage left and everything would be working as planed were a serious problem for me. Well that took some time and nerves but finally worked in the end.

[>> System: Settings: Administration]

Hey unixpgmr,

it's super important that you get your firewall-rules right and documented so that this mistake won't happen again. :)
Additionally there is one new sexy feature, which got added recently. You can actually configure the listen Interface for the Web-GUI access or SSH, see here:

>>   System: Settings: Administration

Underneath "Web GUI" go to "Listen Interfaces" and select the interfaces, which you want to access the Web-GUI from. As the "information" already tells you "only use with care".
Same for SSH underneath "Secure Shell".

Have fun! :)
Oxy

[To take away some fear, i can promise you that you will get it working pretty fast, that's for sure.]

The official OPNsense documentation is really good for an initial basic setup.
To take away some fear, i can promise you that you will get it working pretty fast, that's for sure. :)

But here is the second thought about VPN in general:
Sadly as always and every time things get harder and more difficult to configure the more features and settings you want to enable.
For VPN it's always easier to troubleshoot and configure Site-To-Site or Roadwarrior End-To-Site VPN if you are able to configure both sites, server and client. You are then able to look up error-logs or push settings and so on.
One heavy rabbit hole are the advanced settings for OpenVPN. You can heavily improve your security and performance or completely destroy your already working settings with these additional settings. :D

To get things into perspective:
my OpenVPN configuration, which differs extremely from yours, was done in 2 hours of work with just basic knowledge about OpenVPN and no knowledge at all about the OPNsense configurations i had to do. After 2 hours i had my OpenVPN configuration running and working. From there i started to analyze, improve the performance and hardened the security settings, which took me another 1-2 months (!) until i was happy. In this time the VPN was always stable and working, but "just not perfect". :)

I hope that helped a little. :)
"Just do it" ;)

Oxy

I had some last problems with the update back to 18.1.5. but I was able to update via SSH CLI and it worked perfectly.

Sorry guys for all the mess. 18.1.5 is a gift for the community and I should really stop using the Unbound DNS in forwarding mode. :D

Unbound DNS forwarding was active.... what the f* :D
Don't want to promise to much to myself but it seems like i found the issue.

See you all in 5 minutes with (hopefully) good feedback :D