Messages

Could developers of OS please use less fancy but more user-friendly UI for Edit Alias/Content field? We don't really need the fancy 'Tag'-like field there which does not allow the existing contents to be copied to clipboard w/o resorting to browser inspect function.

It seems like this functionality already exists in some places (e.g. DNSCrypt-Proxy plugin).  It uses the 'Tag'-like fields as you call them, but there is also a 'Text' mode that makes it easy to copy/edit:

You cannot view this attachment.

You cannot view this attachment.

This would be a huge value-add for Aliases, IMO.

FYI: https://github.com/opnsense/plugins/pull/4374

Edit: Was curious, what encryption protocol does this use between OPNsense and the ODoH relay? 

I understand that it's using ODoH between the relay and the server, but is it normal DNSCrypt from OPNsense to relay?  If so, what is gained (privacy wise) over regular DNSCrypt with Anonymous relay?

[W]

I just noticed he said "BG320-500" and not "BGW320-500".  I can't find a spec sheet on the former, so not sure if that's a typo or if there's a similar model without WiFi.

Anyhow, that "Netgear Armor" service seems to include a privacy VPN.  It's possible that a killswitch got triggered when the VPN connection dropped, in which case he might have had to go into settings and manually disable it to get normal routing back.  Anyway moot point now, as you said.

I'm sorry that the Bitdefender product you purchased isn't what you expected, @timlab55.  OPNsense won't run that.

The AT&T gateway you mention does have built-in WiFi, according to: https://usermanual.wiki/Humax/BGW320-4522445.pdf

Was there a reason why this WiFi didn't work for you, that led you to look into the Netgear router in the first place?

You mention needing something that can handle 50 connections.  Can you talk more about that- why do you feel that the original gateway was insufficient?

I was happy as a lark until last week.  I walked into my office and nothing worked.

The Netgear was working for a while and then suddenly stopped.  Not clear to us why, without more details. 

However since your AT&T gateway and the Netgear both have WiFi, you will want to make sure to disable the AT&T WiFi so that those radios don't interfere with the Netgear.  Perhaps that's what AT&T support meant when they told you the Netgear was "too close" to the AT&T gateway?

Respectfully, no, I think you miss the point.  The zones guide is narrowly focused on the idea of zones and inter-zones traffic, but this is a more advanced topic and the guide requires that the reader already understands the basics of interfaces and interface rules.  It's the reader's exercise to configure their interface groups, as it says in the text I quoted.

Looking over your screenshots I think you're expecting that the top-level zone rules are providing internet to each other, which is not the case.  Allowing the internal networks to the reach the "external" network (where I presume you have your WAN interface) is not the same as allowing internet.  There's a common misconception that "WAN net" means "internet" but it's not.

There's an explanation of this and some more discussion about the allow rule with the RFC1918 exclusion here: https://forum.opnsense.org/index.php?topic=36865.0

Yes, you're right.  Looking over the Zones guide, I see that it only walks you through setting up a few top-level rules for inter zone traffic.  I think it assumes that you will set up more specific rules for things like DNS and internet access:

Our unified ruleset will create a baseline that will always match on top-level. Afterwards, we can create more selective allow rules in the individual interface groups.

So I think you have a few options.  You could add a default allow rule (like LAN typically has) to the 'trust' group, or you can add more granular rules to specifically allow DNS(53), HTTP(80), and HTTPS(443). 

Quick is fine.  In that case, put any default 'Allow any' rule(s) at the bottom of the list.

(@Monviech, if you're reading, did I interpret the Zones guide correctly here?  Will be good to get the author's view on this.)

Quick update (pun intended):

Looking at the OpenBSD 'pf' manual, it seems non-quick is the default and 'quick' is a modifier which breaks the rule processing immediately on match.  https://www.openbsd.org/faq/pf/filter.html#quick

So the rules are processed in the same order as they are defined in one pass (which would make sense for things like packet tagging) but we can still think of the non-Quick rules as a separate pass logically, if we are only talking about the rule actions such as pass/block/reject.

How are the floating allow rules supposed to work if the they are processed after the auto-generated ones (and specifically the ones that blocks everything)?

It has to do with non-Quick vs. Quick rule types, indicated by the lightning bolt.  Keep in mind the "Default deny" rule is non-Quick.

The Quick rules are evaluated first, top to bottom, and in order of precedence by their priority levels (System/auto rules -> Floating -> Group -> Interface).

If, and only if, no Quick rule was matched in any of the sections, then the non-Quick ones are evaluated (again top to bottom).  The difference is that non-Quick rules are also last-match meaning later rules overrule earlier ones.  If you have a non-Quick rule in your Interface section that matches, it will take effect even if the system level "Default deny" rule was also matched.  Last one wins.

(This is the logical behavior at least; the rules might be processed differently in code.  You could imagine that they are all processed in a single pass and exits immediately on any Quick rule match, otherwise the last matched non-Quick rule action gets applied.)

The end result is that the system level "Default deny" rule action is only ever applied if there are no other rules (Quick or non-Quick) that are matched, anywhere in the hierarchy.

If you're hitting the Default deny then it's likely you have a misconfiguration in your rules.  Can you post them here?

EDIT: Do I also need to add rules for DNS and DHCP for each zone?

If you're using ISC, it registers automatic DHCP rules.  Kea and Dnsmasq do it by default unless you disable the option in the service settings.  I think there might be a nuance with Dnsmasq where it only auto-registers the DHCP rules if you select specific listen interfaces, but won't do it if you leave it on 'All' interfaces.

DNS rules may or may not be needed, depending on how you set up your access rules and where your DNS server is.  If you have a typical "Allow any" rule and your DNS isn't on a blocked network, then probably not needed.

This is of course secondary to the core functionality, but I was wondering if at some point DNSmasq and/or Kea might gain the Status, State and Lease Type columns that are present in ISC?  I rather like those, especially the green/red Status indicator.

Higher priority (for me, at least) is being able to set DHCP Option 43 for my UniFi console.  I appreciate that there's focus on it already in this thread :)

Purely a pedantic cleanup, for those inclined.  I added one more alias for the IPv4 link-local range and renamed the IPv6 alias to "IPv6_local_ranges" rather than "IPv6_private_ranges" to be more accurate.

IPv4:
- IPv4_no_NAT:
  -- IPv4_private_ranges  (RFC1918)
  -- IPv4_local_ranges (RFC3927)

IPv6:
- IPv6_local_ranges (RFC4291, RFC4193)

Thanks for giving it a go. I don't see why the WAN rule can't be in floating.  My preference is to keep interface-specific rules on the interface and shared/common rules in Floating, but I'm open to new ideas about that.

Good call with 169.254.0.0/16.  I'd probably put it in the "IPv4_no_NAT" alias rather than the "IPv4_private_ranges" one.  I think it's kind of like the fe80::/10 range in that routers aren't supposed to forward packets from those, but who knows what a misbehaved one might do (?)

I'm a little nervous to post this as it's not reviewed.  It's appreciated for the greybeards and others to point out the holes.

[Disclaimer]

I didn't see a similar topic in this section but only did a cursory title search with some keywords.  Apologies if this is covered elsewhere.

By default OPNsense filters private IP ranges on incoming connections.  My goal was to also filter outgoing connections as an added layer so that all private IPv4 and local IPv6 destinations would be rejected on WAN out, thus avoiding leaks.  This might also be prudent on shared ISP lines with neighbors.

In addition I wanted an alias for management clients, such as my PC/laptop, to have an exclusion so that those could continue to reach my leased cable modem UI.  In my case the modem is at 10.0.0.1 and I cannot change this, but I don't have any 10.x networks in OPNsense nor any static route to it.  I rely on Outbound NAT to reach the modem UI.  I suspect this is a common scenario for a lot of home internet users with basic setups.

Normally you'd have to put OPNsense into Manual NAT mode and add some translation rules because you cannot simply add a WAN rule with a "source" address to include your management PC/alias.  That field gets overwritten by NAT.  I wish to avoid this and leave it in the default Automatic NAT mode.  That way I don't have to worry about managing the NAT rules as interfaces and networks change over time.  Fortunately, pf/OPNsense support IP exclusions in alias tables and we can leverage this.  (Read more at OPNsense docs,  feature PR,  'pf' handbook).

Disclaimer: You might have some more complicated routing setup that breaks with these instructions, so be sure to do your homework if this applies.  I tested with my Wireguard site-to-site setup and saw no issues there.


The procedure:

1) Create an Alias to specify your management PCs. I called it "management_clients".

This will be used in step 5.

(This one is optional as you may already be using a dedicated management network or can even use a trusted network (e.g. LAN) for this purpose.)

2) Create an Alias to specify your modem configuration IP.  I called it "modem_ui_address".

This will be used in step 5.

3) Create an Alias of type "Network group" to define RFC1918 private IPv4 ranges, excluding the modem management IP.

In order to use IP exclusions you have to use a nested alias, so it's really a combination of two aliases here into a final third one.

The first one is for the private IPv4 ranges.  You may already have one like this as it's commonly used in interface rules:

Code Select Expand

Name: IPv4_private_ranges
Type: Network(s)
Content: 192.168.0.0/16, 172.16.0.0/12, 10.0.0.0/8
Description: RFC1918 private ranges

The second one is the exclusion (negated IP) of the modem or upstream device that you connect to over WAN.  This one also needs to be a "Network(s)" alias in order to combine with the previous one, so just give it a /32 notation if it's a single IP:

Code Select Expand

Name: modem_ui_exclusion
Type: Network(s)
Content: !10.0.0.1/32
Description: Inversion of modem MGMT IP

The "!" prefix is important here. Substitute whatever IP you need.

The final one is the combined alias:

Code Select Expand

Name: IPv4_dont_NAT
Type: Network group
Content: IPv4_private_ranges, modem_ui_exclusion
Description: Private IPv4 ranges to filter outbound

You can inspect the final alias in Firewall->Diagnostics->Aliases to confirm the exclusion IP is there sorted among the RFC1918 ranges.

You cannot view this attachment.

3) Create an Alias of type "Network(s)" to define at least IPv6 ULA (fc00::/7) and link-local (fe80::/10) prefixes.  The latter shouldn't be routable but I like having it.

You cannot view this attachment.

4) Add two respective WAN rules with direction "out" (post-NAT) to reject these destinations.

   *Important to use "reject" and not "block" here, so that LAN clients get notification and don't hang. RFC4193 for IPv6 ULA also recommends this.

You cannot view this attachment.

I made mine non-Quick rules to act as defaults on WAN, but you can keep them as Quick also.

5) Add a Floating interface rule to block all except the management hosts/network to reach the modem management IP.

Code Select Expand

Action: Block
Quick: checked
Interface: <none selected>
Direction: In
TCP/IP Version: IPv4
Protocol: TCP
Source invert: checked
Source: management_clients  (or network)
Destination: modem_ui_address
Destination port: HTTP
Description: Block all except MGMT hosts to modem UI

Clone and add an HTTPS rule if your modem uses it.

You cannot view this attachment.

6) Test with some pings.  You should get timeouts on all private IP addresses which are not defined in OPNsense, except for the modem IP.

Code Select Expand

C:\>ping 10.1.2.3

Pinging 10.1.2.3 with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for 10.1.2.3:
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

The firewall live view should reflect that these pings are dropped.  The "Source" address should be your WAN public IP, confirming that the rule was applied post-NAT.

For IPv6 you can ping a random ULA address:

Code Select Expand

C:\>ping -6 [fd50:2e32:f043::]

Pinging fd50:2e32:f043:: with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for fd50:2e32:f043:::
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

In this case the "Source" IP in the FW logs will be your public IPv6 address (GUA) or a ULA if you have one configured on your local interface, as these aren't NAT-ed.  (Note: the intention is not to confirm filtering of ICMPv6 here, as that's generally frowned upon in IPv6.  This is just testing the rule.)

If you open a browser and try to navigate to these IPs you should not get stuck waiting.  You should get a "Connection Refused" error after a few seconds, confirming the Reject action on the WAN rules.

Finally test the modem admin UI is working.

7) Profit!

From now on you only need to update the management client and modem IPs in the respective aliases, if those change.  In summary those are:

Code Select Expand

Name: management_clients
Name: modem_ui_address
Name: modem_ui_exclusion


The way I interpret this, OP wants to give the impression to the child that the internet and/or game server becomes unusable at night without making it too obvious that parental control has taken place. :)

Oh that's sneaky }:->

I think the capability is already present.  You can create a Pipe in Firewall->Shaper with a packet delay (under Advanced settings).  Example of that in this thread.

Then you can create a schedule in Firewall->Settings->Schedules.

Finally you can add an interface rule and apply the schedule within it.  There's a new/experimental feature in OPNsense which lets you apply the shaping in the pf rule itself (by selecting the pipe). 

Haven't tried this but I think it should work.  The only thing I'm not clear on is how to prevent the pipe from reducing the total available bandwidth for other clients because this is essentially bandwidth reservation.  You might have to narrowly define the pipe bandwidth for the specific client you want to throttle and just accept the loss of that bandwidth, but I might be mistaken about this.