Messages

Yes, I know it may be confusing that I mentioned the 10/8 range in this topic for the CGNAT discussion, sorry for that.

But what I can clearly see in the firewall log is the following and similar entries:

100.73.8.126:33827   84.xx.yy.zz:9000   udp   Block private networks from WAN

100.73.8.126 is not private network. At least not in the similar way as 10/8 or 192.168/16 is.

@2fun0: thanks, but the official Unbound man page has no idea how Opnsense has been built to provide name resolution to the opnsense box itself, and to LAN clients. As opnsense can be configured to use unbound in many different ways:
1) recursive mode
2) forwarder mode
3) use dnsmasq (in parallel with unbound?)
4) use bind (but in what relation with unbound?)

So in short, the Unbound man page has not much to do with how a different product called Opnsense works.

Hello all,

If I check the Interface \ WAN settings, I have the following choices: to selectively block Private networks AND/OR Bogus networks from connecting to my router.

Block Private network has the following help text:

Block private networks    
When set, this option blocks traffic from IP addresses that are reserved for private networks as per RFC 1918 (10/8, 172.16/12, 192.168/16) as well as loopback addresses (127/8). This option should only be set for WAN type interfaces that use public IP address space.

Actually, 10/8 in its entirety is not considered to be private anymore, as according to RFC6598 CGN has been officially allocated to 100.64.0.0/10 (reference: https://tools.ietf.org/html/rfc6598)

So while it is still advisable to block non-routable private address space on a public-IP WAN connection, CGN peers should be allowed to come through. Disabling the block of Private networks opens a possible security hole for spoofed IP attacks, while Blocking private networks blocks many hosts that are located behind the same ISP as my router.

I think it would make sense to either exclude the CGNAT range from 10/8, or create a new third category: "Block CGNAT networks". What do you think?

"I am aware how DNS works and specifically how OPNsense DNS service works with unbound and dnsmasq"

Would you mind sharing the details with the conmunity about your knowledge? Is it your own experimenting, or you found the explanation on some public website?

sub

Do you have any chance to access PPPOE-based WAN / PPPOE-based WAN simulator? As I also have issues to reach 1 Gbit even on multi-stream, if PPPOE is used for the WAN Aconnection. I already gave up hope for 1Gbit single-flow performance, but even multi-flow performance is quite low. Where connecting a PC to the same PPPOE WAN directly (no OPNSENSE router/firewall in front of the PC), I can achieve much higher speeds.

I think such small difference cam easily be the random variation between test runs. I could see similar variations myself running on the same OS.

Anyway, thanks for your support, at least I know its not just me. Practically all Pcengines APU2 owners should consider something different for 1Gbit WAN. If opnsense will be installed on the board of course. :-)

I think the confusion comes from the fact, that there are actually 2 very similar solutions in opnsense for the DNS name resolution: Unbound AND dnsmasq. So its not a surprise, that without guidance or detailed explanation, one can get easily lost whether these 2 both are needed (they both solve only half of the task), or they are mutually exclusive and only 1 should be used at any time?

Its also not trivial, considering that:
1) you can provide a global DNS server list in the System tab. Its not really explained, that the definition of an entry here basically sets forwarding to an upstream DNS server, and practically disables recursion type of working
2) your ISP can send you their own preferred list of DNS servers, when you establish an internet connection via your opnsense box. You either accept this list or you reject it ans specify your own preference, as seen in 1)
3) recursion mode enabled in Unbound settings, that does completely ignores 1) and 2)

Your explanation (even if copied from an external source) could use some more wording, like:

1) Your client asks the DNS service "Who is opnsense.org?"

rather say this:
1) A PC on your local LAN wants to resolve a DNS name.
This PC has been set up with the preferred nameserver pointing towards the LAN IP address of the Opnsense box. So this PC sends a DNS query to the Opnsense router, to resolve the DNS name, and send back the reply to your PC.

2) Your DNS service will check its cache and reply if the answer is already known.

rather say this:
2) The DNS service called Unbound, running on your Opnsense router will check its internal cache and reply, if the answer is already known.

3) Since 2 is not true in our example, the DNS service delegates the request to the (local) recursive DNS resolver.

rather this:
3) Since 2) is not true in our example, the Unbound DNS service running on your Opnsense router delegates the request to the (local) recursive DNS resolver. Which is a fancy way of saying, that the local Unbound service needs to figure out how to get the job done via asking other DNS servers.

4) Your recursive server will send a query to the DNS root servers: "Who is handling .org?"

rather this:
4) The Unbound service running on your Opnsense box will send a query to the DNS root servers: "Who is handling .org?" How did Unbound know where these DNS root servers are? It has a static file stored locally, called root.hints that lists the IPs of all these publically known DNS root servers. Without the root.hints file, this approach breaks!


"It is obvious that the methods are very different and the own recursion is more involved than "just" asking some upstream server. This has benefits and drawbacks:"

I would extend this section with the following:
Malware protection: some hosts on the internet  serve malicious content, therefore it is advised to block your DNS clients being able to contact these hosts. So as a simple defense method, you want to "break" the normal DNS name resolution for malicious hostnames, and reply with a bogus IP address for such hosts. Either you maintain an active lists of such hosts. In that case your Unbound running on the Opnsense box can authoritatively reply for such entries with a bogus IP address.
Or you subscribe to the public OpenDNS service. In that case, you cannot use recursion on your Unbound, but rather use it in forwarding mode, and trust OpenDNS to make a filtering on the requests of your DNS clients.

Sounds reasonable/doable. My 1st github experience.

You misunderstand me, I wanted to add this myself, as soon as I get to know how exactly this works.

99% of that is irrelevant to most users, they do not care about layer 2, layer 3 or the layers of a cake, they  just want it to work with simple straight forward instructions, that's a how-to... not a why's and wherefore and a discussion on networking principles.


However there is nothing preventing you from writing in depth explanations if you feel the need and presenting them for inclusion in the wiki; frankly I don't have time to spare at the moment.

As I have already typed the text here, would not be impossible to make it part of the wiki :-)

Looking at these test results, the mainline v4.8.0.5 seems more promising, even without the ECC capability, then the legacy v4.0.20, but YMMW.

https://docs.google.com/spreadsheets/d/1_uRhVo9eYeZONnelymonYp444zYHT_Q_qmJEJ8_XqJc/edit#gid=0

https://docs.google.com/spreadsheets/d/1_uRhVo9eYeZONnelymonYp444zYHT_Q_qmJEJ8_XqJc/edit#gid=1817105926

Have you checked the list of known issues between the latest 4.8.x and 4.0.x release? Also, some known issues are revealed on that page only after it has been fixed, not when it is being discovered. So you would assume everything is fine and dandy when you see the current release has only 1-2 issues listed. When in reality, there are many discovered issues, just that they dont get revealed, until they get fixed. Which means, you naively think "oh it will be fine to use this as I am not affected by this 1-2 already revealed bugs". But behind the scenes, most probably you will be affected by the already-discovered but non-disclosed and not-yet-fixed ones.

This for example is only a partial list of what is going on behind the scenes:
https://github.com/pcengines/coreboot/issues

Just to get an idea, this ECC topic is the perfect example. Nowhere it is mentioned, that "hey customers, ECC is broken since our product hit the market". And all of a sudden, 4.8.0.5 finally admits: "well guys, we knew it was broken for 2+ yrs, but now we BELIEVE its working".
Have you seen ECC reported as broken in any of the previous releases "known issues" section? You see, thats the problem with this approach: perfectly supports the product vendor dishonesty, and allows them to reveal (or not!) their product defects on their convenience.

Or here is another topic: nobody in the world knows for sure, what is the real clockrate of the AMD CPU built into the APU2 boards!
https://forum.netgate.com/topic/133656/did-i-just-overclocked-my-apu2c4-amd-gx-412tc-soc

Everybody just guessing, not a single person can confidently say, this CPU is clocked to XYZ Ghz, and can/cannot do Turbo clock, where its Turbo clockrate is XYZ+ABC Ghz, and the reason why in the APU2 we dont see this clockrate ever is: ? (a big questionmark, nobody external or internal knows it)

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=232451

Do you think its a flow-control related bug?

Hmm, not the most customer-centric approach  :o

Let me explain:

- the 2 tunables are not described at all, what do these change in practicality? What happens in this network topology, if neither of them is changed from their defaults?
- what exact scenario this howto is supposed to solve, is quite unclear. Same as the transparent filtering bridge howto, that tries to accomplish a different type of network architecture, but also not described very precisely (at least a drawing showing the Layer2 / Layer3 would help understanding how that topology should work). It assumes the person reading the howto has the networking knowledge comparable to a CCNP. At least the following introduction should be added in this example:

----------------------------
By default, Opnsense interfaces are configured as Layer-3 interface. That means each physical interface segments the network into different broadcast domains, all using its unique L3 IP addressing scheme. However, if there is a specific need, it is possible to configure some physical interfaces into a Layer-2 mode, similar to L2 switchports, thanks to the virtual software-based interface type "bridge". Members of such bridge interface group behave like ports of a standard L2 switch in the same broadcast domain. This topology is recommended only in the following cases:
- if there is no standalone L2 switch in the network, while Opnsense box has plenty of available physical interfaces, and the number of connecting endpoints is minimal, or
- if the corresponding L2/L3 switch lacks any available ports.

Performance note: in contrast with a true L2 switch -where packet forwarding is done at hardware ASIC level without stressing the switch main CPU- a virtual software-based bridge sends all traffic of bridge member interfaces through the Opnsense CPU. This is true, regardless if the traffic is between two endpoints where the Opnsense box is normally not involved. As a result, even traffic that should normally not be processed or seen by Opnsense itself, still puts significant processing load on its CPU, and reduces the available resources to handle normal workloads.
---------------------

How does this sound?

Hmm, looks like the lan_bridge.rst file is not hooked up to a parent page so it's not showing up on https://docs.opnsense.org/


Cheers,
Franco

Indeed! This topic cant be located on the docs page.