Recent posts

#1
German - Deutsch / Re: WAN-Umstellung von PPPoE a...
Last post by meyergru - Today at 07:19:21 PM
Gateway <> WAN-IP.
#2
26.1, 26,4 Series / Re: Previously working os-apcu...
Last post by mrzaz - Today at 06:52:35 PM
Quote from: viragomann on Today at 02:21:05 PM
Quote from: mrzaz on Today at 05:12:04 AMI have traced the port 161 signalling out of OpnSense on LAN going out OK.
I then traced the port 161 signalling in to server with "PowerShute Serial Shutdown" application and it is comming in.
But still nothing.
So OPNsense doesn't get a response from the server?
If so you should rather look for the reason on the server.

Was the OPNsense interface address changed by any chance?
In this case you might have to update the access control list of the SNMP server.


I have enabled some debugging in the PowerShute and I could see the following:

OpnSense
2026-05-24 18:13:23,492 [DefaultUDPTransportMapping_0.0.0.0/161] DEBUG - [Util.ExtendedCommandProcessor.()] got Request from:[B@3611beffCommandResponderEvent[securityModel=1, securityLevel=1, maxSizeResponsePDU=2147483647, pduHandle=PduHandle[476310], stateReference=StateReference[msgID=0,pduHandle=PduHandle[476310],securityEngineID=null,securityModel=null,securityName=private,securityLevel=1,contextEngineID=null,contextName=null,retryMsgIDs=null], pdu=GETNEXT[requestID=476310, errorStatus=Success(0), errorIndex=0, VBS[1.3.6.1.4.1.318.1.1.1.1.1.2 = Null]], messageProcessingModel=0, securityName=private, processed=true, peerAddress=192.168.120.20/37256, transportMapping=org.snmp4j.transport.DefaultUdpTransportMapping@16a362a3, tmStateReference=null]
2026-05-24 18:13:23,492 [DefaultUDPTransportMapping_0.0.0.0/161] DEBUG - [Util.ExtendedCommandProcessor.()] Successfull Connection

Synology
2026-05-24 18:29:35,601 [DefaultUDPTransportMapping_0.0.0.0/161] DEBUG - [Util.ExtendedCommandProcessor.()] got Request from:[B@b420132CommandResponderEvent[securityModel=1, securityLevel=1, maxSizeResponsePDU=2147483647, pduHandle=PduHandle[1113222366], stateReference=StateReference[msgID=0,pduHandle=PduHandle[1113222366],securityEngineID=null,securityModel=null,securityName=private,securityLevel=1,contextEngineID=null,contextName=null,retryMsgIDs=null], pdu=GET[requestID=1113222366, errorStatus=Success(0), errorIndex=0, VBS[1.3.6.1.2.1.1.2.0 = Null]], messageProcessingModel=0, securityName=private, processed=true, peerAddress=192.168.120.64/44555, transportMapping=org.snmp4j.transport.DefaultUdpTransportMapping@16a362a3, tmStateReference=null]
2026-05-24 18:29:35,601 [DefaultUDPTransportMapping_0.0.0.0/161] DEBUG - [Util.ExtendedCommandProcessor.()] Successfull Connection

However, Synology gets more connections and readout that looks more OK than OpnSense.
I have saved 2 logs. One for OpnsSense NON-working and one from Synology workign.

Will try to investigate some more with debugging in Apcupsd.

I changed from private to public to separate some other SNMP that was going from Opn to Synology about disks and could see that it sends
the following but never gets any response (and could not find anything in the other logs to why:

1   0.000000   192.168.120.20   192.168.120.4   SNMP   89   161   get-next-request 1.3.6.1.4.1.318.1.1.1.2.2.6
2   2.007897   192.168.120.20   192.168.120.4   SNMP   89   161   get-next-request 1.3.6.1.4.1.318.1.1.1.3.2.3
9   4.019971   192.168.120.20   192.168.120.4   SNMP   89   161   get-next-request 1.3.6.1.4.1.318.1.1.1.3.2.2
10   6.030553   192.168.120.20   192.168.120.4   SNMP   89   161   get-next-request 1.3.6.1.4.1.318.1.1.1.4.1.1
15   8.037828   192.168.120.20   192.168.120.4   SNMP   89   161   get-next-request 1.3.6.1.4.1.318.1.1.1.2.2.4

Frame 1: Packet, 89 bytes on wire (712 bits), 89 bytes captured (712 bits)
Ethernet II, Src: 52:54:00:74:c0:6c (52:54:00:74:c0:6c), Dst: Intel_d5:60:9f (a0:36:9f:d5:60:9f)
Internet Protocol Version 4, Src: 192.168.120.20, Dst: 192.168.120.4
User Datagram Protocol, Src Port: 37743, Dst Port: 161
Simple Network Management Protocol
    version: version-1 (0)
    community: public
    data: get-next-request (1)
        get-next-request
            request-id: 514747
            error-status: noError (0)
            error-index: 0
            variable-bindings: 1 item
                1.3.6.1.4.1.318.1.1.1.2.2.6: Value (Null)
                    Object Name: 1.3.6.1.4.1.318.1.1.1.2.2.6 (iso.3.6.1.4.1.318.1.1.1.2.2.6)
                    Value (Null)

I have not changed the version on PowerShute. Only the OpnSense/plugins.

Also -d 99 did not give anything either. :-/
/usr/local/sbin/apcupsd -f /usr/local/etc/apcupsd/apcupsd.conf -d 99

//Dan Lundqvist
#3
26.1, 26,4 Series / Re: Rules [new] vs. Rules
Last post by Monviech (Cedrik) - Today at 05:22:58 PM
I dont know out of my head.

Check with "pfctl -s rules" and "cat /tmp/rules.debug" how legacy vs new are loaded.

If there is an error in the docs a PR is always welcome.
#4
26.1, 26,4 Series / Re: Rules [new] vs. Rules
Last post by dseven - Today at 04:33:21 PM
I see. I didn't expect the answer to be there - I expected it either in the "Overview" (where the two implementations are called out) or under "Implementations".

So now I have another question... the processing order is given as:

1. System defined rules at the beginning of the ruleset
2. Firewall > Rules [new] and Firewall > Rules floating rules
3. Firewall > Rules [new] and Firewall > Rules group rules
4. Firewall > Rules [new] single interface rules
5. Firewall > Rules single interface rules
6. System defined rules at the end of the ruleset

Why aren't the 4th and 5th items combined as "Firewall > Rules [new] and Firewall > Rules single interface rules"? i.e. what's the difference between "and" vs two separate line items?
#5
German - Deutsch / Re: WAN-Umstellung von PPPoE a...
Last post by PrinceLG - Today at 04:22:30 PM
Hallo zusammen,

bis zum Vertragsbeginn am 18.05 kam ich mit einer privaten IP über CGN-Gateway beim Provider ins böse Internt.
Am 18.05.2026 wurde mir von der Lünecom die bestellte statische öffentliche IPv4 zugeteilt.

Diese lautet 5.xxx.xx.1x (https://www.wieistmeineip.de/)
In der OPNSense wird jedoch unter Gateway eine andere IP angezeigt: 5.xxx.xx.1  <<<--- hier fehlt die zweite Ziffer
Es sieht so aus, als wenn die Lünecom die IP intern nochmal routet.

Kann mir jemand erkären wie es dazu kommt? bisher entsprach die IPv4 Adresse in der OPNSense immer der öffentlichen IP.













 
#6
German - Deutsch / Re: Kein DNAT auf lo0: tailsca...
Last post by viragomann - Today at 03:01:32 PM
Quote from: nexo on May 18, 2026, 06:57:53 PMGibt es eine offensichtliche Möglichkeit, die ich übersehe?

Wie löst ihr das?
Den Reverse-Proxy direkt auf OPNsense betreiben. So erreichen ihn Requests an die WAN-IP, egal, woher sie kommen, und er leitet sie normal zu den Backends weiter.

Ansonsten, wenn mittels DNAT Anfragen am WAN weitergeleitet werden, sind eben Split-DNS oder NAT Reflection die üblichen Optionen, wobei letzteres für Anfragen der OPNsense selbst wahrscheinlich nicht funktioniert, ist eben auch NAT, und damit für deinen Zweck nicht infrage kommt.
#7
26.1, 26,4 Series / Re: Rules [new] vs. Rules
Last post by Monviech (Cedrik) - Today at 02:47:28 PM
In the processing order the documentation states "and", meaning both rulesets are active at the same time.
#8
26.1, 26,4 Series / Re: Rules [new] vs. Rules
Last post by dseven - Today at 02:41:51 PM
I haven't been able to find a clear answer to this in the docs (https://docs.opnsense.org/manual/firewall.html) or the UI (haven't gone trawling through forum posts to try to find it)...

What happens if rules exist in both old and new interfaces?

I'm guessing that if any legacy rules exist, then only those legacy rules are used, and any in the "new" interface are ignored? (this would give the opportunity to construct the new rule set without breaking connectivity)

If that is the case, it might be helpful to put a banner at the top of the "new" interface saying something to the effect of "Because legacy rules exist, these rules will not take effect"

Whatever the situation is, it'd be nice of the documentation could state it clearly...
#9
Ich finde die Verwaltung von Listen aber auch manuellen Ausnahmen in AdGuardHome sehr schön und benutze den in Kombination mit Unbound. Also AGH nur fürs Blocken, Unbound als rekursiven Resolver.
#10
26.1, 26,4 Series / Re: Previously working os-apcu...
Last post by viragomann - Today at 02:21:05 PM
Quote from: mrzaz on Today at 05:12:04 AMI have traced the port 161 signalling out of OpnSense on LAN going out OK.
I then traced the port 161 signalling in to server with "PowerShute Serial Shutdown" application and it is comming in.
But still nothing.
So OPNsense doesn't get a response from the server?
If so you should rather look for the reason on the server.

Was the OPNsense interface address changed by any chance?
In this case you might have to update the access control list of the SNMP server.