Recent posts

#21

General Discussion / Re: Where should I put the mai...

Last post by Patrick M. Hausen - Today at 10:28:09 AM

Specifically given that you need explicit rules for the most basic network communications between the clients on one side of the bridge and the router on the other one. ARP, NDP, DHCP, SLAAC, ...

Unless of course you just "allow any any" - but then, what's the point?

#22

General Discussion / Monit when WAN link is dropped

Last post by Albertk - Today at 10:27:02 AM

Hi,

Is there an example where when the wan link is down to execute a script.

Thank you.

#23

25.7, 25.10 Series / Re: 25.7.8 Unbound blocklist s...

Last post by meyergru - Today at 10:26:16 AM

...or else they'll fix that problem! ;-)

#24

General Discussion / Re: Where should I put the mai...

Last post by meyergru - Today at 10:25:01 AM

Is that possible with a transparent bridge setup? I frankly do not know...

And BTW: Does Home Network Guy not specifically cover that basic question, which should come up all the time with such setups, I imagine?
Oh, yes, he does. By creating a MGMT interface and bridging that to WAN. How elegant and intuitive.

I still do not get how people think that a transparent bridge would be easier than a routed setup.

#25

General Discussion / Re: Access HTTPs and SSH from ...

Last post by Albertk - Today at 10:24:14 AM

Is the host "on the Internet" from which you are testing actually connected to the same network as the WAN interface of OPNsense? I.e. is there an Ethernet instead of a point to point connection between OPNsense and the uplink router? And you are testing from that network?

In that case: Firewall > Settings > Advanced >  Disable reply-to.

That fix it.  Thanks.

#26

Development and Code Review / Re: Delete one firewall rule o...

Last post by patient0 - Today at 10:23:12 AM

Do you already have "Destination NAT" instead of "Port Forward" under NAT?

No, it is still called 'Port Forward', of which I have two + an Outbound NAT for IPv6.

Addition: Deleting one of the port forward rules make them all (two) disappear). In that use case there is again a <rule>...</rule> added. <rule> after </outbound> and </rule> before </nat>. Removing them resolves it.

#27

25.7, 25.10 Series / Re: 25.7.8 Unbound blocklist s...

Last post by Monviech (Cedrik) - Today at 10:13:37 AM

Better do not call them and do not wake sleeping dogs. :)

#28

25.7, 25.10 Series / Re: 25.7.8 Unbound blocklist s...

Last post by OPNenthu - Today at 10:12:28 AM

Well that's... a solution.  I'd like to evolve from monkey someday soon, though :)

I might need to get on the phone with my ISP and inquire about this.  I noticed my prefix hasn't changed in quite some time, so I wonder if they've changed a policy and now make the prefixes sticky.

#29

Development and Code Review / Re: Delete one firewall rule o...

Last post by Monviech (Cedrik) - Today at 10:11:30 AM

Do you already have "Destination NAT" instead of "Port Forward" under NAT?

Thats a thing that changed recently, maybe there's something unexpected going on?

https://github.com/opnsense/core/commit/da976d77fb46117b3837693b43b4b34472fd19f8

#30

Hardware and Performance / Re: Suggestion for Bufferbloat...

Last post by Seimus - Today at 10:08:10 AM

I will call this used guide guide "Dirty but effective"

The creator of this article looks like doesn't know what their are doing.
There are several miss statements about Pipes and Queues.
There are several miss-configurations in the Pipe > BW, Queues, Quantum
There are several miss-configurations in the Queue > MASK, ECN, Enabled Codel

And so on.

Some of the configured features don't do anything and some of them have impact. Like MASK, Quantum & BW and overlapping FQ_C in scheduler and CoDel in the Queue, causes overall that there is twice running the CoDel algorithm, fighting each other.

In layman terms Quantum basically handles how much bytes at once can from a Flow queue leave (FQ_C internal one). The reason why you want to use Quantum at your MTU size when your BW is above 100Mbit is to serve 1 packet per flow (there can be thousands flows, 1 flow = 1 internal FQ_Codel queue). Higher Quantum sizes could starve smaller packets. And too small Quantum sizes could starve bigger packet sizes. Both related to the configured Interface MTU.


Regards,
S.