Recent posts

#1

Russian - Русский / Re: x2ray + tun2socks. Сделал ...

Last post by monderlog - Today at 04:19:30 AM

В interfaces: overview он присутсвует, но помечен как down

Code Select Expand

root@OPNsense:~ # ls -la /usr/local/etc/rc.syshook.d/early/
total 28
drwxr-xr-x  2 root wheel  8 Mar  4 05:50 .
drwxr-xr-x  12 root wheel  12 Dec 28 10:48 ..
-rwxr-xr-x  1 root wheel 137 Feb 11 17:58 05-upgrade
-rwxr-xr-x  1 root wheel  63 Feb 11 17:58 10-configd
-rwxr-xr-x  1 root wheel  95 Feb 11 17:58 15-templates
-rwxr-xr-x  1 root wheel  93 Feb 11 17:58 20-backup
-rw-r--r--  1 root wheel  74 Jan 21 13:09 50-tun2socks
-rwxr-xr-x  1 root wheel 631 Feb 11 17:58 90-carp
надо смотреть сообщения системы во время загрузки, у меня вот прав не хватало для применения, решил так:

Code Select Expand

root@OPNsense:~ # chmod +x /usr/local/etc/rc.syshook.d/early/50-tun2socks

#2

26.1 Series / HDHomeRun any successful cases...

Last post by FullyBorked - Today at 03:18:34 AM

Been banging my head on the desk trying to solve this to no resolve. I have an HDHomeRun box in a seperate IoT vlan.  I've installad the udp broadcast relay plugin.  I have a floating firewall rule for UDP port 65001 for IoT and LAN networks and see allowed packets in the log. 

UDP Broacast relay config -

Port: 65001
Relay interface: IoT/LAN
Broadcast address: I've tried all kinds of combos even blank. I see traffic on 255.255.255.255 but I guess I can't use that in the plugin as it fails to start with that.  So what can I should I use here?
Source address: 1.1.1.1

Not sure how to troubleshoot this, I see allowed traffic, I see a single UDP 65001 packet from my computer, then two (return?) packets from the HDHomeRun box both UDP 65001.  But the app seems to not see the traffic. 

I welcome any help getting this figured out if it's possible. 

#3

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

Last post by multazimd - Today at 01:56:33 AM

This is what shows in cost.

PublisherType   Marketplace
ChargeType   Usage
ServiceFamily   Azure Marketplace Services
ServiceName   Virtual Machine Licenses
Meter           OPNsense® Firewall/Router/VPN/IDPS - OPNsense - 8 Core Hours

Though it shows 8 core hours but I actually charged cost is flat, quite low but it does has some little bit extra than $0.05/hour price mentioned on image. Maybe its Azure marketplace fees/commission or taxes, idk. Will observe for few days to confirm that's the case, if needed will ask Azure support.

#4

General Discussion / Re: Unifi VLANs with new OPNse...

Last post by Yosh1 - Today at 01:49:25 AM

Thanks @meyergru for the help. I made the adjustments as you proposed, but kept them on 1 for the 3rd octet:

• UDM: 192.168.1.2/24
  
  • DHCP disabled
  • DHCP Relay to 192.168.1.1
  • All other options disabled (e.g. no DHCP guarding, no isolation)
• OPNsense "MGMT" (VLAN 1): 192.168.1.1/24
  
  • Separate NIC port
  • Plugged into Unifi switch port: Untagged/Native VLAN 1, None tagged
  • No DHCP server... Is that correct?
• OPNsense "LAN" (VLAN 10): 192.168.1.5/24
  
  • Shared NIC port with other VLANs (But the physical interface is not assigned)
  • Plugged into Unifi switch port: No Untagged/Native, All tagged
  • I gave this a *.5 address so that I could enable a DHCP server on it... Is that correct?
    
    • DHCP server has range 192.168.1.160-192.168.1.250
    • DNS servers and gateway both set to "192.168.1.1"
• ** Disabled the other VLAN interfaces (99 & 107) for now, to simplify debugging
• Unbound DNS:
  
  • Network interfaces: All
  • Listen port 53
• Firewall rule for MGMT:
  
  • "Default allow any rule for MGMT"
  • Interface: MGMT
  • Version: IPv4
  • Protocol: *
  • Source: MGMT net
  • Source Port: *
  • Destination: *
  • Destination Port: *
  • Gateway: *
• Firewall rule for LAN:
  
  • "Default allow any rule for LAN"
  • Interface: LAN
  • Version: IPv4
  • Protocol: *
  • Source: LAN net
  • Source Port: *
  • Destination: *
  • Destination Port: *
  • Gateway: *

As it stands, I still cannot get out to the net from a device connected to VLAN 10 through a Unifi AP. The WiFi network is set to VLAN 10. The path between the switches and the AP is the same as I showed in the image in post #3 (Untagged with VLAN 1 and tagged with all). I connect to the WiFi, get an IP address from the DHCP server (it shows in Leases), the client gets "192.168.1.1" for the DNS server, but I cannot get out to the net.

I enabled logging for the pass any rules and see that there's a duplication of actions - an event shows on the "ix0" interface (the parent interface of all of the VLANs, which is not assigned to anything and is not enabled), which gets a "block" but the same exact event is then passed as the next event, now showing as the MGMT interface. What's going on? See image:


You cannot view this attachment.

#5

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

Last post by OPNenthu - Today at 12:05:23 AM

That makes more sense.

I'm not on Windows so didn't realize that -f and -l meant something different, but I should have questioned why I was trying to flood (-f) ping a specific number of preload packets (-l)

;-)

Linux:

-M do - don't fragment
-s - size

I'm seeing times of 30-40ms on my end, so note to self:  maybe time to ditch cable for good.  Not seeing the packet loss though (OPNsense 26.1.2_5).

#6

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

Last post by Patrick M. Hausen - March 03, 2026, 11:32:56 PM

Windows:

-f - don't fragment
-l - size

FreeBSD:

-D - don't fragement
-s - size

It helps to read the documentation:

Code Select Expand

man ping

HTH,
Patrick

#7

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

Last post by pfry - March 03, 2026, 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.

#8

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

Last post by OPNenthu - March 03, 2026, 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.

#9

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

Last post by OPNenthu - March 03, 2026, 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

#10

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

Last post by GreenMatter - March 03, 2026, 09:52:44 PM

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