Recent posts

#1

26.1 Series / Re: 10%-30% packet loss on upl...

Last post by pfry - Today at 11:17:29 PM

[...]I want to try this myself but the ping command you gave doesn't work in OPNsense.[...]

But it does work in Windows:

Code Select Expand

Microsoft Windows [Version 10.0.19045.4529]
(c) Microsoft Corporation. All rights reserved.

C:\Users\User>ping google.com -f -l 1472

Pinging google.com [142.251.116.102] with 1472 bytes of data:
Reply from 142.251.116.102: bytes=1472 time=19ms TTL=104
Reply from 142.251.116.102: bytes=1472 time=14ms TTL=104
Reply from 142.251.116.102: bytes=1472 time=19ms TTL=104
Reply from 142.251.116.102: bytes=1472 time=19ms TTL=104

Ping statistics for 142.251.116.102:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 14ms, Maximum = 19ms, Average = 17ms

C:\Users\User>


[,,,]I also recently replaced my ISP's cable modem /w a Netgear CM2000 which meets and exceeds the specs of the ISP's modem.[...]

What cable service? More asymmetric ones are going away, but many are still around. Just a data point.

#2

26.1 Series / Re: Clarification on source-ba...

Last post by OPNenthu - Today at 11:05:26 PM

I can't find anything official on how it should handle "blank" subnets, but the method right now is it will parse any lists that are blank in addition to any other policy it did match on.  I agree if nothing else, it should be a feature request.

Ok, so it doesn't really cascade.  If I understood you, it matches the policy with the most specific source and then, having failed to match a blocklist item there, it falls immediately to the 'default' policy.

As far as forcing the route though the GUA to get there, you would have needed to add a firewall rule to allow that behavior, otherwise it wouldn't route. DNS is also not a security feature. They can also just type the IP in directly, add it their local hosts file,  or many other various methods

Right, let me clarify my question.

If I do configure ULAs they would be in addition to GUAs because I don't want to have to use NAT with IPv6.  What I recall is that clients choose GUAs before ULAs and in most cases the ULA address won't ever be used.

If Unbound is listening on a ULA, then does the client automatically choose its ULA as well to reach Unbound?  Or does it still try the GUA route?

I don't think I'd be able to control it from the client side (?), so I would have to assume that any client could try to reach Unbound from any of its configured IPs.  In that case I again have the problem that dynamic prefix GUAs would need to be handled by a default (catch-all) policy in Unbound which would break the 'localhost' policies.

I guess I could use firewall blocks to enforce it, but not sure I like that.  It seems like it would cause delays.

#3

26.1 Series / Re: What to do with "Rules" no...

Last post by OPNenthu - Today at 10:20:02 PM

BUT, in my Interfaces below the old rules, I still see "Floating rules" and those are clearly MY floating rules, not automatically created!

They seem to be the same as from the new rules, at least I can see one new rule that I added in the new rules section after the upgrade.
But they have no Delete button.

I can't tell from your screenshot what those Floating rules are but I think they would all be yours.  System-generated and automatic rules go into their own categories.

If you created Floating rules in either of the new or old UIs, then I think those would reflect in the Floating folder in your screenshot.

It's true that in the new system rules with multiple interfaces get promoted to Floating, but it was always the case that multi-interface rules had to be Floating.  You can't have an interface level rule with multiple interfaces.

I think the reason the Delete button is missing is because if the rules are native to the new UI then you can only delete them from there.  You can't manage 'new' style rules from the 'old' style interface, even if they're visible.  They're read-only.

This seems to be a fundamental change to before, where changing such things would never change the priority (rule-number)!

And, I cannot have "late" rules anymore for more than one Interface! Now, such a rule get's moved to the front.

Not sure I understand this, but I'm interested.  Can you elaborate on what you mean by "late" rule?

There's a kind of open challenge from the devs to come up with cases that no longer work in the new Floating system:

https://github.com/opnsense/core/issues/9652

I think so far the devs are winning with the caveat that you have to use a dummy or loopback interface to avoid splitting related Floating rules across interfaces :P

#4

High availability / Re: Dnsmasq - doesn't work for...

Last post by GreenMatter - Today at 09:52:44 PM

As far as I can see, even KEA sends dhcp offers from interface address and not VIP. Is it correct?

#5

General Discussion / Re: ISP bandwidth is cut in 1/...

Last post by Greg_E - Today at 09:49:48 PM

Suricata should be multithreaded, it definitely was when I was running it on pfsense, and I'm guessing it is on OPNsense. Snort was single threaded for a long time, I think they may have fixed this by now (but not sure).

#6

General Discussion / Re: software cost of opnsense ...

Last post by Greg_E - Today at 09:47:48 PM

Is it really paying OPNsense or is it paying Microsoft? I could see a 50/50 split, but OPNsense better get something.

#7

Hardware and Performance / Re: RISC-V port could be an id...

Last post by Greg_E - Today at 09:45:42 PM

How long did it take Linux to really get rolling on x86? RISC-V is fairly new still.

#8

26.1 Series / Re: Clarification on source-ba...

Last post by falken - Today at 09:28:24 PM

The documentation indicates "the algorithm selects the most specific subnet when domains overlap across subnet sizes."  This is true, if you have 10.0.0.0/24 and 10.0.0.5 for example, it will only match on 10.0.0.5 and not 10.0.0.0.  The main issue there is no default that says "if nothing applies, use this list".  Leaving it blank applies to all policies.  So 10.0.0.5 and the blank one would both apply, but not 10.0.0.0/24.
I can't find anything official on how it should handle "blank" subnets, but the method right now is it will parse any lists that are blank in addition to any other policy it did match on.  I agree if nothing else, it should be a feature request.

As far as forcing the route though the GUA to get there, you would have needed to add a firewall rule to allow that behavior, otherwise it wouldn't route. DNS is also not a security feature. They can also just type the IP in directly, add it their local hosts file,  or many other various methods

#9

26.1 Series / Re: What to do with "Rules" no...

Last post by senseOPN - Today at 09:27:56 PM

Unsolicited advice: once you've migrated, don't look back at the legacy UI for any reason.  Just forget it exists and try to acclimate to the new one (which is a lot like a spreadsheet).  The exception is for Outbound NAT as that isn't migrated yet.

That was very informative.
Those multiple groups of automatically created rules were confusing.

BUT, in my Interfaces below the old rules, I still see "Floating rules" and those are clearly MY floating rules, not automatically created!

They seem to be the same as from the new rules, at least I can see one new rule that I added in the new rules section after the upgrade.
But they have no Delete button.

Really, this is confusing!
But I hear you and will try to ignore :-)
Thanks!

BTW, in the old version, you could create a floating rule for any and all selection of Interfaces - now, adding a second Interface, will change the rule to a Floating rules and vice versa!

That means, adding a second Interface moves a rule automatically up to the Floating rules, which are handled before other rules.
And removing all but one Interface, removes the rules from the Floating rules, dropping it in priority!

This seems to be a fundamental change to before, where changing such things would never change the priority (rule-number)!

And, I cannot have "late" rules anymore for more than one Interface! Now, such a rule get's moved to the front.
Before, "Floating" was simply separate, not decided by the number of Interfaces.

#10

Zenarmor (Sensei) / Google Voice keeps getting blo...

Last post by lorem - Today at 09:23:34 PM

Google Voice is occasionally blocked. When I look at Live sessions I see two blocks:

The first Blocked Domain is stun.l.google.com. Block message is Conferencing category
If I allow all of Conferencing category, stun.l.google.com is still blocked

The second Blocked Domain 74.125.39.xxx (xxx = it changes). App protocol is STUN Protocol. Block message is Network Management category
There is no STUN Protocol in Network Management category. In App Controls -> VOIP -> VoIP STUN was already enabled.

I can individually enable these in Live Sessions -> Blocks. But Google occasionally changes a port or address setting and then I silently lose incoming calls until I discover I can't make a call. Besides allowing everything which would defeat the purpose of Zenarmor, I don't see any way to fix this.