Messages

placeholder

placeholder

[after]

The first (pass) rule discussed above will look like this:

You cannot view this attachment.

The second (block) rule is this and it has to be placed after the pass rule:

You cannot view this attachment.

The alternative method uses just a single block rule with a modified alias instead of the two rules:

You cannot view this attachment.

and no advanced options (i.e. no explicit disable-reply-to):

You cannot view this attachment.

[Complex Case: WAN interface = ONT interface]

Complex Case: WAN interface = ONT interface

This is when your WAN interface is the same as the management interface (often via DHCP). 
You must assign a second IP in addition to the DHCP address, using a Virtual IP.

Now for the question on how to block WAN traffic for RFC1918 destinations.

Apparent solution: Use an "out" firewall rule to block all RFC1918 traffic, but create exceptions for your ONT network.

Code Select Expand

Allow "out" quick from any to 192.168.100.0/24 
Block "out" quick from any to RFC1918 

This will pass outbound packets, but replies may not return unless Disable reply-to is enabled, because the resulting rules in /tmp/rules.debug would show:

pass in quick on igc3 reply-to ( igc3 100.87.0.1 ) inet from {any} to {192.168.100.0/24} keep state # Allow ONT access 
block out log quick on igc3 reply-to ( igc3 100.87.0.1 ) inet from {any} to $RFC1918 # Never expose internal IPs

Correct approach: Enable Disable reply-to in the advanced rule options for both allow and block rules:

Code Select Expand

Allow "out" quick from any to 192.168.100.0/24 with disable reply-to 
Block "out" quick from any to RFC1918 with disable reply-to 

Another method: exclude the ONT network from the RFC1918 block. 
Note: You cannot use an exception in the RFC1918 alias. You must manually list all subnets except the ONT subnet.  On the other hand, you need no "disable-reply-to" in your (single) rule.

Example alias "RFC1918_WITHOUT_ONT":

Code Select Expand

10.0.0.0/8 
172.16.0.0/12 
192.168.0.0/18 
192.168.64.0/19 
192.168.96.0/22 
192.168.101.0/24 
192.168.102.0/23 
192.168.104.0/21 
192.168.112.0/20 
192.168.128.0/17 

Them use the new alias in your block rule:

Code Select Expand

Block "out" quick from any to RFC1918_WITHOUT_ONT 



Actual steps with screendumps

So, to configure for the complex case, first create the virtual IP:

You cannot view this attachment.

Do not forget the outbound NAT rule (you cannot use "Interface address" for the NAT address because of the virtual IP):

You cannot view this attachment.

Again, you can use either hybrid or manual mode for this.

Also, unlike in the easy case, you cannot use "ONT net" with a virtual IP in your client access rule:

You cannot view this attachment.

[Basic Requirements]

OPNsense – Accessing ONT / Modem Management Interfaces (Complete Guide)

I know that there are existing guides to do this, like this, yet those threads have become quite cluttered.
This guide does not want to take away from these efforts, rather expand them for a complex edge case that warrants a new guide, so here goes:


Basic Requirements

First off, there are some basic requirements for this to work:

• You must not block RFC1918 IPs on the OPNsense interface connected to the ONT for obvious reasons.
• Your ONT's (or modem's) management IP must be outside of any of your local networks, including remote VPN sites. This is why you should never use some well-known network ranges that ONTs often use (also covered here).
• Some ONTs shut off management access once they establish internet access (i.e., O5 state). Nokia ONTs only react to ARP, but neither ICMP nor IP access works once connected on the fiber side.
• You most probably need outbound NAT to access the ONT because it is statically configured and does not have a default gateway. By using NAT, the translated IP the ONT sees lies inside its own local network, so it can respond correctly. You could theoretically install a route via OPNsense instead, but that does not work for all ONTs. Outbound NAT is the more general solution.
• You need a firewall rule allowing access from your management client(s) to your ONT's management IP.

In what follows, I assume 192.168.100.1 is the ONT management IP and 192.168.100.2/24 is the OPNsense interface IP. Adjust as needed for your setup.

Important warning: Some providers (e.g., Deutsche Glasfaser) block your internet access for a few minutes if they detect traffic to RFC1918 or BOGON IPs outside your networks. 

• This can happen if devices (Fritzboxes, IoT devices) attempt to reach hardcoded RFC1918 IPs that are not local.
• Such traffic goes out via your ISP router and triggers provider protections.

You cannot simply block RFC1918 on the WAN interface because it violates requirement a).

I like to have an "out" rule on the WAN interface to suppress traffic to RFC1918 destinations, but that is not so easy sometimes...


Two Main Cases

You have two separate cases if you want to enable ONT (or modem) access:

Easy Case: WAN interface ≠ ONT interface

You have the actual WAN interface on a separate interface than your ONT. 
This applies if your WAN uses either a VLAN, PPPoE, or both.

In this case, you can assign the ONT interface to the management subnet, because the interface is not being used otherwise.

So, you simply configure the ONT interface like this:

You cannot view this attachment.

This is the outbound NAT rule (you can use it via manual or hybrid NAT):

You cannot view this attachment.

Now for the question on how to block WAN traffic for RFC1918 destinations - this is easy in this case, because the rule applies to WAN only (and not to ONT):

You cannot view this attachment.

And lastly, the firewall rule to allow management clients to access your ONT (in case your LAN does not have an "allow any" rule):

You cannot view this attachment.

Thank you, Franco. After:

Code Select Expand

opnsense-patch -c update fbe231e8f5
opnsense-code -uo sysutils/nextcloud-backup -r 25.7 plugins
pkg lock os-nextcloud-backup-1.0_1
configctl webgui restart

os-nextcloud-backup-1.0_1 is back and locked for now.

I also created an issue: https://github.com/opnsense/plugins/issues/5181

I had a rule exactly like this for interface "enc0" in my export which I needed to delete manually before migrating. No idea what the cause of this might be atm.

Same here. That specific rule was "hidden" before - I was unable to find it in the old rules under 26.1., but apparently, it was exported.

At this point, I do not think further discussion in this thread will be productive.

From a technical perspective, the core issues described earlier were explained and resolved to the extent possible based on the information provided. The remaining problems clearly require a systematic, local troubleshooting approach (interface isolation, DHCP logs, packet captures), not a forum discussion about general perception, branding, or community culture.

This forum is a community-driven space. Participation is voluntary, and responses reflect individual experience and time availability, not official positions of Deciso or OPNsense. Expectations beyond that inevitably lead to frustration on all sides.

I wish you success in resolving your setup and in finding a solution that fits your requirements. I will step back from this thread now.

Actually, that was not a "little" bug. But did that rule come out of the blue or was it present before?

Because you obviously have used the migration assistant, you should be able to look at the rules before the migration.

This would be helpful to tell if there is a potential "HUGE" bug or just a misconfiguration on your part.

[including the reflection settings]

Because it does not work for interfaces that are created on-the-fly or change their IPs if the BIND is not done to the anonymous socket 0.0.0.0, which denotes "all" interfaces, including such that do not exist (yet).

Just try to use a VPN interface: It will seem to work, but on the next reboot, the service fails because it cannot bind to a non-existing interface.

So, the usual way is to bind services to "all" interfaces and block access using firewall rules.

However:

I still do not understand how this could happen unless there is some other misplaced rule or - even more likely - the smartphone was connected via WiFi and that causes a false positive test.

As I said, I use the same settings including the reflection settings and see no such thing.

+1

This "fix" should really be undone with the next release.


BTW: How do I roll that package back? "opnsense-revert -r 25.7.11 os-nextcloud-backup" fails with:

Code Select Expand

Fetching os-nextcloud-backup.pkg: ..[fetch: https://pkg.opnsense.org/FreeBSD:14:amd64/26.1/MINT/25.7.9/latest/Latest/os-nextcloud-backup.pkg.sig: Not Found] failed


I have the Anti-Lockout rules enabled and administration on all interfaces, too. During 26.1 upgrade, two separate non-editable rules have shown up on top of the destination NAT rules, for IPv4 and IPv6. The source interface for both is LAN.

I have done no rules migration to new rules and also created no new rules. Reflection settings are all on in "Firewall: Settings: Advanced".

SSH and Web GUI are not open on WAN.

How would that work? The anti-lockout rules are for the LAN interface as source only. Did you actually see those two ports open from the WAN side?

That is a fundamental question, but note: I never promoted to do that. Actually, I would do it only for good reasons, which do exist.

If you assume a Linux driver issue that can be exploited on the PVE host, OpnSense will not protect you. You can impede that somewhat by using passthru, where OpnSense itself drives the hardware, which could be useful for the WAN NIC. On the other hand that will undermine purposes such as Linux drivers often being more stable than FreeBSD ones, like for Realtek cards, where you would want to use virtio.

However, usually, you will have to reach the NIC via IP first and PVE does not have control over the network layer, such that your attacks must be crafted to reach the IP, but attack lower layers. Otherwise, the packets will not even get through to your system.

Most attacks aim at higher layers these days and you could argue that there are many more lower layer attacks which you cannot prevent. Think of Intel I226-LM adapters which allow for remote administration OUTSIDE anything your "machine" does by virtue of Intel vPro/AMT.

Note that the PVE interface itself is hidden "behind" OpnSense, on the logical LAN interface, which usually exists on a (virtual) bridge and is often reachable only from VMs behind OpnSense or internal clients. In the case of a cloud-hosted instance, you will probably allow access only through a VPN configured in OpnSense - at least I do it like that.

That way, the outside attack surface is small - and also, since OpnSense and all other instances are VMs in this case, I can always roll back to snapshots or backups.

Remember: there is no 100% security - this will always be a tradeoff.

My problem seems unrelated as of now, probably just a glitch. At least it never turned up again.