Messages

[Logic behind setting Forwarding Mode to ON]

Hi!

Try setting the "Enable Forwarding Mode" to Yes (Checked) in Unbound DNS (Services: Unbound DNS: General).

If not enough, disable Harden DNSSEC data (Services: Unbound DNS: Advanced).
If still not enough, disable DNSSEC completely (Services: Unbound DNS: General).

Logic behind setting Forwarding Mode to ON: during the wizard, you get asked which DNS servers you want to use, so you set something there, maybe your provider's DNS, or Google's, or OpenDNS's etc.
By default, Unbound is set without Forwarding Mode (Disabled), and so it should directly resolve using root DNS servers. For unknown reasons, this doesn't work, so enabling Forwarding Mode would force Unbound to resolve using your previously set public DNS.

Logic behind Hardened DNSSEC settings: Depending on your chosen DNS forwarding servers, many of these DNS forwarding services don't cope well with DNSSEC, so try disabling Hardened DNSSEC at first, and then, if needed, DNSSEC completely.

Hope it helps.
Cheers!

So are my rules correct but simply applied on the wrong interface? Do I simply need to recreate them on the LAN interface?

It's wiser to apply the block at the first and most close to the conditional element point: why would the FW evaluate rules twice for the same datagram, for this case once for LAN which allows it ("Default allow LAN to any rule" rule, which is evaluated when your datagram reaches LAN) , and again for WAN which blocks it if you so created a rule?  ;)

[must]

:))))))

Don't block from PC's IP to FW's IP, you'll simply lock your access from that PC to OPNsense:

Is Facebook's IP (or Google, or opnsense.org or any other destination in entire internet for that matter) = WAN IP?
NO
Then, traffic is allowed.

This matter (confusion) is not a matter of documentation, I'd say... Rather a matter of interpretation: the fact that the traffic must pass through the firewall to reach internet DOESN'T mean that if you block the intermediate destination the traffic will be blocked and wouldn't reach the final destination. :)

Hi!

Your approach might be wrong: I guess what you're looking for is Outbound NAT == "No Nat" (Route).

In OPNsense, add an interface and configure it with the first (or last) of your public IPs in the range, so that you have a GW interface for those servers behind OPNsense. Name it "Perimeter", "DMZ" or something meaningful to you...

Then, in Firewall: NAT: Outbound menu, set Mode to Hybrid (or Manual, but I prefer Hybrid, it's easier to administer afterwards if you still play with adding/ deleting/ modifying LAN interfaces) and add an Outbound NAT rule for your public IP range with "Do not NAT" checked. Disable the corresponding auto-generated rules for NAT (they were auto-generated at the moment you created and set the interface, so you will find them bellow the just created manual "Do not NAT" rule).

The end result is that, for those public IPs in that rule, and for traffic on that particular interface, there will only be route, and no NAT, so your datagrams (data packets) will always have the public IP of the server behind the FW as source, not the public IP of OPNsense. (Take care of the fact that you have to have routing also for the return path, so your ISP have to handle the routing for IN traffic, the traffic destined to your public IPs, set toward your WAN.)

Get back and confirm if this is what you intend and if it works.
Cheers!

[not]

Hi!

Since you're new to FW, allow me to further explain:

As @bigops said, the ideea is that the Hollander PC is not reachable from the internet to LAN, but quite contrary, most likely there is an app or a service on Hollander PC that calls home to Hollander servers, hence OPNsense permits the traffic based on default rule "Default allow LAN to any rule" (the same rule that permits internet traffic for everything in your LAN), then establish e connection/ session for that communication from the app/ service on Hollander PC to Hollander Head Quarter Servers, and everything that comes back as a reply from Hollander HQ servers to Hollander PC is bound to that already established session, so the communication is successful both ways. It is important to acknowledge the fact that software disabling action is not initiated by the vendor, it is only the response (reply) action your vendor set for the software to be taken at the moment when the client app/ service will initiate contact to their servers successfully!!! (!) This is important!!! :)

This happens because OPNsense is a stateful firewall, so a reply on an already established session (on the firewall, the session's state is established & ON) is always permited without the need to have mirroring rules on WAN for every rule you have on LAN.

It might be helpful for you too (it is for me) to imagine a router like a road junction:

- roads getting into and leaving from the junction are the NICs (Network Interface Cards) and cables/ antennas
- the junction itself is the router box
- the traffic signs and rules are the ACLs and firewall rules
- the authority establishing traffic signs and rules for that junction and the policeman occasionally present in the middle of the junction, directing traffic, is you, yourself! ;)
- the most important part, however, is to find the proper way of placing rules and signs: this particular sign (FW rule), because it enforce this particular effect, must be placed before the junction (for in traffic) or after the traffic (for out traffic) and on this particular road.

Al the best in the routing world, as well as in the real world! :)

LE: Ah... One more thing: in Unbound DNS try to set "Enable Forwarding Mode" to ON. Start with that one!!! (!)

Hi!

Try to disable 1. Harden DNSSEC data, and if it's not enough, try to disable 2. DNSSEC Support, both in Unbound DNS.

Get back and confirm it helped or didn't. :)
Tschuss!

[Beware and think twice about choosing high performance & high TDP wattage CPU options on allowing POnDesk HW (Products On Desk (Winston Marriot - London UK based) - pondesk.com) if it might happen to stumble upon it!!!]

(Excuses for this very-very long reply)

Even if I clearly saw what happened when @ricsip stated a warning against a specific product based on it's feelings/ emotions, I can't refrain myself from saying Beware and think twice about choosing high performance & high TDP wattage CPU options on allowing POnDesk HW (Products On Desk (Winston Marriot - London UK based) - pondesk.com) if it might happen to stumble upon it!!!

Only beware! Only mind! Don't avoid at all costs if you really want to try specific high end config! But be prepared for intricacies and stalling and email ping-pongs with sells/ support reps quite a bit. In the end, they did their best to repair the situation, and they did. But with unnecessary statements in emails and trying to dodge the real problem at first.

I can prove anything I state here with emails and pictures, if requested, but I only want to mention the facts for now. So, without further ado, what happened is like following:

I bought a Pondesk NSHO-001 model (https://www.pondesk.com/product/8-LAN-10Gig-Fiber-SFP-4G-NGFW-Firewall-1U-Rackmount-Server_NSHO-001) with the highest performance CPU available, the I7 - 4790K (4 Cores/ 8 Threads (SMT/ Hyper-Threading), 8 MB cache, 4,4 GHz - 88 W TDP). Actually, I have chosen an I7 - 4790 CPU, but they offered to send the next option as a courtesy of first time customer, and we (me and my corp customer) accept it. (Of course I checked any online reviews I could find about them, but even if I found tens of such reviews, all positive, none were about the 1U rack-mount models, since nobody seemed to have been bought such models from them, but desktop models.)

The reason they offered the I7 K in place of I7 non-K for the same money, I have been finding out later, was that they had one and only one 1U device available, and it was based on that I7 K CPU: the case was dirty (sticky/ oily dirty) and had multiple irregular scratches some of which were quite deep, the rubber pads were already glued on their places excepting one pad that was out of its place, but glue residues was also present on the correct spot nearby... And so on and so forth, suffice to say the product (well over 1000 $) wasn't brand new in its aspect.

OK, it was purchased as a testing unit, so the physical aspect was not an issue, as long as possible following orders will be as they should - but I took pictures of the unit and have sent them back to their sales stating that this physical state for following orders would be a "no go" for us.

First, let's connect a monitor to the device, let's power it up, and enter the BIOS to see whats there: everything OK, reported RAM and storage were as requested/ ordered, the CPU was the K version... Except the reported CPU temperature was a little bit (more) worrying: 55 deg C and rising... Stopped at about 63.

Booted from an utilities USB stick, run some CPU stress testing tools, monitored the temp, and concluded heavy CPU throttling since in just 2-3 seconds since stress test started the reported temp was 100. Repeated tests several times, asked POnDesk if it's OK to check the thermal compound on the CPU cooling unit, they stated "not necessary, the unit was thoroughly tested, but go ahead, no warranty issues!, opened the unit only to find huge amounts of thermal paste between the CPU and the heatsink, and even more bewildering, none of it was forced out by the pressure, all of it was two thick layers on both the CPU and heatsink, and no metal glimpse could be seen on either of the CPU or heatsink: they didn't mind the mounting position of the heatsink regarding the row of several capacitors near the CPU and one bracket of the heatsink was lying on 2 of those capacitors, one of them having a clear scratch on top, caused by the mounting bracket of the heatsink!!! (!)

Replaced the thermal paste, repositioned the heatsink so that no bracket would lay on any capacitor, only to have marginal improvements, it reached "only" 58 this time during BIOS monitoring, but no difference during stress tests, seconds to reach 100 (only if I would have a car like that ;) ).

Out of pure curiosity, I did install OPNsense on the unit: ~55 on idle, ~85 - 100, mostly 100, on light traffic (only one client, a laptop, with default config, no traffic shaper, no IPS, no NAT... No nothing excepting the default LAN rules). Took some screenshots, sent them on an email, and requested the unit to be repaired/ replaced.

Trying to cut an already long story short, I would say that they accepted the unit to be sent back, but hilariously their comment was that (and mind this) since the OPNsense interface shows 8 cores it is clearly NOT reliable, AND the temp measured is not accurate, because this model of the CPU has only 4 cores!!! Wouldn't you love these salesman people who have not quite all the ideas about what they're selling?!?!? :)))) (Of course, sent them a short response about SMT and Hyper Threading things, directing them to their technical dep, but OH, MY!...)

After a few days they reported the unit just arrived at their address, and that the tech dep will give further details, but for now only resetting the BIOS to defaults lead to peak temp to 55! (Say whaaaat???!!! (!)) I didn't reply on spot. After a few days, I reminded them that no final resolution, nor the further details from tech dep has been sent, and they replied with "We still have temp issues, tests are not finished, and as we don't want to further delay your shipment, we would like to send you our brand new product and design, the NSHO-004 model" (https://www.pondesk.com/product/Intel-Atom-C3758-8-Core-6-LAN-10Gig-SFP-1U-Rackmount-Server_NSHO-004). So not another device of the same config, but an another design by itself - proving insufficient design testing, let alone product testing! (!) My customer agreed, as a second and final chance for this company to prove something, so it arrived after a few more days (this time really being and looking brand new).

All good, temp is as low as possible in between 35 - 45, CPU passive cooling, 2 case fans on the back of the unit, maxing out my customers 1 GB internet fiber link, but no idea about real stressing loads with IPS and/ or VPN since my customer reverted back to virtual appliance and no replacement up to now, only short tests, temp concerned at most, from behind the VM (the actual site-to-site VPN and IPS probable bottleneck).

Both units look like they're presented in the pictures found on website.

Hope it would help someone making the right choice: I would say this NSHO-004 model is quite a good choice for being a Network Appliance powered by OPNsense, at list for what short and superficial tests I ran up to now (I will come back with further details) and since Qotom has no rack-mount units on its offer, I would turn toward NSHO-004 any time if rack-mounting is mandatory.

Also, maybe Deciso would mind the Intel® Atom™ C3758 (8 core, 16M Cache, up to 2.20 GHz) for its products, as those AMD CPUs, even if still notable, are a bit old from now on.

Thanks for the great input! I just realized I may have misunderstood the "Weight" value. I thought this was a priority of the traffic (i.e. higher weighted traffic has higher priority than lower weighted queues). Is it actually a percentage of the allocated bandwidth within a pipe?

Yes, only not a percentage, but a proportion: say you have (like upon) a weight of 100, one of 66, and one of 33, this case every concurrent traffic made by 3 clients corresponding one to each weight you will have a shape of 3 datagrams (packets) routed for client in weight 100, followed by 2 datagrams routed for client in weight 66 and followed by 1 datagram routed for client in weight 33. Further, say that client in weight 100 finished its traffic activity, weight 66 will still get 2 datagrams routed for every 1 packet routed for client in 33. Or else, if 66 finished its transfer, 100 will get 3 datagrams passed for every 1 datagram of 33.

Theoretically, lets say you have 100 clients, and each has a corresponding individual weight: first 100 datagrams will be passed and routed for client in 100, followed by 99 datagrams passed and routed for client in 99, and so on and so forth... making client in weight 1 having only 1 datagram passed and routed for it only after 4999 datagrams have been passed and routed for everybody else... But this is a case quite not likely to be encountered in real setups.

Speaking about such theoretical setups, this is the point of all net neutrality debate: no ISP should be allowed to implement such a setup, neither towards services, neither between own clients.

I like "Weighted Fair Queuing" + "FQ CoDel" for anything as such: since I'm not able to differentiate traffic at Layer 7, at least I force the traffic to be weighted and fairly shared among internal clients, as well as different services for the same client.

The most you can do is to give a higher priority in shaper to clients you use for streaming (even if for cloud bkp too), than to those clients that don't stream. Meaning, that weight 50 bulk 80/ 443 you mentioned should be further split to weight 66 based on streaming clients' IP addresses, and weight 33 for non-streaming. Maybe you will still have cloud bkp & streaming "fights", but only on those devices that do both streaming and cloud backups, and only when they do it in the same time. This cases, the weighted fair queuing should really help.

Actually, thinking through about that, and after a few more days, I can say that the info is there, "in your face" enough!
First, RTFM, and second and more than RTFM, RTFS!!! :) (screen)

I don't know. Sorry, I really don't know! :)

I think that opense does not translate Nat DNS query to IP Switch

It shouldn't: it is supposed to ROUTE it, not NAT it. Meaning, OPNsense should set DNS reply packet to 10.10.20.3 as destination (and via 10.10.10.1 as GW - route), and not to 10.10.10.1 as destination (NAT).

It's weird, I admit. If I get to figure out something else, I'l come back.

This is why you can ping from any client in VLAN 10, but not from the device from VLAN 20.

LE Also, this is why you can ping any client from any client in between VLANs, but not OPNsense from different VLANs than 10.10.10.0
PS Sorry for double posting.

[routing]

Again, I stick to my opinion, which might be wrong, I accept:

Your SWITCH does the routing between VLANs. This means that the source and destination IP addresses are NOT changed. Hence, the source address of ping will be 10.10.20.X, outside of the LAN network of OPNsense, so OPNsense will drop the ping packet.

Sorry if I'm wrong, but if I'm wrong I assure you I'm sincerely wrong!

Code Select Expand

Welcome!  Both `root' and `installer' users are available for system
setup or invoking the installer, respectively.  The predefined root
password works for both accounts.

What about?:

Code Select Expand

Welcome!

THIS SESSION IS IN LIVE CD MODE! Mind the fact that your changes are NOT persistent after a reboot! (!)

One way to change this is to login with 'installer' user in order to trigger the install to local storage.
The predefined 'root' password works for 'installer' user too.