Recent posts

Pages1 2 3 ... 10
#1
High availability / Re: HA with prefix delegation:...
Last post by ajr - Today at 08:08:01 PM
After doing the setup (interfaces, DHCP6 and radvd) again from scratch,
tcp connections now work correctly.
In case of ping6 things get screwed up:

Incoming from WLAN shows global addresses:
Code Select
oot@opn1:~ # tcpdump -nvi vlan03 icmp6
tcpdump: listening on vlan03, link-type EN10MB (Ethernet), snapshot length 262144 bytes
16:21:57.367066 IP6 (hlim 255, next-header ICMPv6 (58), payload length 32) fe80::184b:3cc0:64c8:616b > fe80::20d:b9ff:fe48:5c1e: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has fe80::20d:b9ff:fe48:5c1e
  source link-address option (1), length 8 (1): 2a:1d:b8:a7:3c:71
16:21:57.367311 IP6 (hlim 255, next-header ICMPv6 (58), payload length 24) fe80::20d:b9ff:fe48:5c1e > fe80::184b:3cc0:64c8:616b: [icmp6 sum ok] ICMP6, neighbor advertisement, length 24, tgt is fe80::20d:b9ff:fe48:5c1e, Flags [router, solicited]

16:22:30.765033 IP6 (hlim 255, next-header ICMPv6 (58), payload length 24) fe80::20d:b9ff:fe48:5c1e > fe80::c72:8634:5d07:76c5: [icmp6 sum ok] ICMP6, neighbor advertisement, length 24, tgt is fe80::20d:b9ff:fe48:5c1e, Flags [router, solicited]
16:22:34.992643 IP6 (flowlabel 0xc0c00, hlim 64, next-header ICMPv6 (58), payload length 16) 2003:cb:170f:6f3:48cc:5883:5412:514f > 2a02:2e0:3fe:1001:302::: [icmp6 sum ok] ICMP6, echo request, id 19531, seq 0

Outgoing at WAN shows only local addresses:
Code Select
root@opn1:~ # tcpdump -nvi igb1 icmp6
tcpdump: listening on igb1, link-type EN10MB (Ethernet), snapshot length 262144 bytes
16:11:59.122356 IP6 (hlim 64, next-header ICMPv6 (58), payload length 9) fe80::20d:b9ff:fe48:5c1d > fe80::cece:1eff:feb3:757f: [icmp6 sum ok] ICMP6, echo request, id 44961, seq 15220
16:11:59.122714 IP6 (hlim 64, next-header ICMPv6 (58), payload length 9) fe80::cece:1eff:feb3:757f > fe80::20d:b9ff:fe48:5c1d: [icmp6 sum ok] ICMP6, echo reply, id 44961, seq 15220

A group rule exists to allow icmp v6 for all nets.
#2
26.7, 26.10 Series / Re: Static-port outbound NAT d...
Last post by anomaly0617 - Today at 07:25:08 PM
No, the AI anonymized/redacted information before providing the final report. The internal network is RFC1918, the external network is appropriately set static with a valid static IP, and some traffic makes it through, just not all of it. This is most frustrating because it means "sometimes" outbound calling works, and sometimes it does not. I could tell the SIP provider to accept both the default outbound IP and the one designated for VoIP, but that doesn't really resolve the underlying issue.

I've been testing on this for a few days now to make sure it's not something internal or external to the firewall, but the config prior to upgrading to 26.7 was stable for years. So this is something new in the 26.x line, it's just a question of whether it's an OPNsense problem, a PF problem, or a FreeBSD problem.
#3
26.7, 26.10 Series / Re: tailscale interface down (...
Last post by Bossybear - Today at 06:56:02 PM
I installed tailscale on another machine on my LAN and it works fine.
I've deleted tailscale from OPNSense. :(
#4
26.7, 26.10 Series / tailscale interface down (red ...
Last post by Bossybear - Today at 06:08:15 PM
OPNsense v26.7.9_1-amd64
I installed the os-tailscale plugin (v1.104.5) and followed the usual and customary setup instructions.
My firewall is listed as authorized in the devices list on the tailscale web ui.
Tailscale status says it is running, it has an IP address assigned.

When I go to the Interfaces to assign the tailscale interface to a local (opt4) the network status is red (offline)

No matter what I do from here on out, this interface never goes online.

What am I doing wrong?
#5
26.7, 26.10 Series / Re: Static-port outbound NAT d...
Last post by keeka - Today at 04:45:33 PM
You or your AI don't set out the fw/NAT rules involved, but given the PBX internal IP is not RFC1918, do you have a typo somewhere in your opnsense config?
#6
26.7, 26.10 Series / Static-port outbound NAT drops...
Last post by anomaly0617 - Today at 04:21:44 PM
OPNsense 26.7.8_1: static-port outbound NAT drops UDP/5060 packets with map-failed when a WAN redirect uses the reverse tuple


Environment

  • OPNsense 26.7.8_1 (opnsense-26.7.8_1)
  • FreeBSD 15.1-RELEASE-p6, stable/26.7-n284176-c962f76493b6, amd64
  • WAN ix0, LAN ix1
  • WAN VIP 203.0.113.10; LAN VIP 192.0.2.1
  • PF state limits were not exhausted; the preserved snapshots show zero memory exhaustion.
  • Exact PF userland/source revision: unknown in the preserved evidence.

Topology
Code Select
SIP carrier                      OPNsense                        PBX
198.51.100.128:5060  <---- ix0/WAN ---- ix1/LAN ---->  192.0.2.11:5060
                                    WAN VIP
                                  203.0.113.10:5060
The WAN UDP/5060-5063 port forward redirects inbound traffic to the PBX UDP/5060. A manual outbound NAT rule for the PBX uses the same WAN VIP with static-port.

Problem statement

Independent PBX-originated SIP OPTIONS packets reach the LAN interface and are accepted by PF, but PF fails to create the outbound NAT mapping. No corresponding request leaves the WAN. The LAN-created state has no translated tuple and remains NO_TRAFFIC:SINGLE. PF's global map-failed counter increments once per failed packet, while the dedicated outbound NAT rule's packet and state counters do not change.

At the same time, inbound carrier transactions to the WAN VIP UDP/5060 continue to be redirected to the PBX and replies continue to leave the WAN.

Observed evidence

Capture interval: 2026-11-13T18:10:37Z through 2026-11-13T18:12:37Z. Packet display timestamps were local EST and are normalized to UTC below.
Code Select
Measurement                                                    Before  After  Delta
LAN ix1 PBX 192.0.2.11:5060 -> 198.51.100.128:5060 packets  -      21      +21
WAN ix0 matching PBX-originated OPTIONS                    -      0      0
PF global map-failed                                          5431    5452    +21
Rule 164 state packets                                          55      76      +21
Rule 5 NAT packets                                              10387  10387  0
Rule 5 NAT active states                                        0      0      0
Rule 5 NAT evaluations                                          498732  500117  +1385
The 21 LAN packets are retransmissions spanning two unique outbound SIP Call-IDs. Four inbound carrier transactions used four other Call-IDs; the outbound and inbound Call-ID sets did not intersect. Exact Call-ID values are omitted.

The first failed LAN packet was observed at 2026-11-13T18:11:08.397959Z; the last was observed at 2026-11-13T18:12:35.898063Z.

Representative successful inbound correlation:
Code Select
UTC time          Interface  Packet
18:11:04.134366  ix0      198.51.100.128:5060 -> 203.0.113.10:5060 OPTIONS
18:11:04.134379  ix1      198.51.100.128:58653 -> 192.0.2.11:5060 redirected request
18:11:04.136388  ix1      192.0.2.11:5060 -> 198.51.100.128:58653 200 OK
18:11:04.136398  ix0      203.0.113.10:5060 -> 198.51.100.128:5060 translated 200 OK
The two-interface timestamps differ by 13 microseconds on the inbound redirection and 10 microseconds on the reverse path, supporting synchronized capture rather than a capture mismatch.

Expected behavior

The independent PBX flow should match the dedicated outbound static-port NAT rule and leave ix0 as:
Code Select
203.0.113.10:5060 -> 198.51.100.128:5060
The generated state should contain a valid translated tuple, and the reply should return to the PBX.

Actual behavior

The LAN filter accepts the packets and creates this state:
Code Select
all udp 198.51.100.128:5060 <- 192.0.2.11:5060  NO_TRAFFIC:SINGLE
age 00:06:59, 76:0 pkts, 35775:0 bytes, rule 164
origif: ix1
There is no translated tuple in the state, no WAN request, and no reply. map-failed increases by the same number as the LAN packets.

The simultaneously valid inbound state is:
Code Select
all udp 192.0.2.11:5060 (203.0.113.10:5060)
  <- 198.51.100.128:58653 (198.51.100.128:5060)  MULTIPLE:MULTIPLE
This inbound state's working external endpoint pair uses the same two host:port endpoints in the opposite direction from the desired outbound static NAT tuple.

Hypothesis under test

The leading hypothesis is that PF's fixed-port outbound mapping cannot create the desired tuple while the active WAN redirect state occupies the reverse endpoint tuple, or that this configuration reaches a first-packet NAT/state ordering edge case. This is not proven.

The following are not established:

  • that this is an OPNsense-specific defect;
  • that this is a FreeBSD PF defect;
  • that the behavior is intentional PF behavior;
  • that CARP or pfsync contributed;
  • that the exact internal branch responsible for map-failed has been identified.

Questions for maintainers

  • Is a static-port outbound mapping expected to fail when an active port redirect creates the reverse WAN endpoint tuple?
  • If this is expected, where is that restriction documented, and which read-only diagnostic should distinguish a fixed-port collision from other map-failed causes?
  • Which NAT state or rule evaluation is attempted after the LAN keep state rule has accepted the packet but before the outbound NAT counter advances?
  • Is the unchanged packet/state count on the matched NAT rule, while the global evaluation counter advances, expected for failed fixed-port allocation?
  • Does PF intentionally rewrite the redirect-side source port but reject or decline the inverse static-port mapping? If so, what prevents allocation of an alternate outbound source port when static-port is present?
  • Can PF debug logging expose the precise mapping conflict without packet modification? Which counter, zone, anchor, or log should maintainers expect to identify it?
  • Is the kernel revision stable/26.7-n284176-c962f76493b6 affected by a known fix, limitation, or source change involving fixed-port NAT and reverse redirect state?
  • Would a vanilla FreeBSD installation with equivalent manually loaded PF rules be expected to behave identically?

Reproduction request

Please reproduce in an isolated lab using:

  • the exact OPNsense build above;
  • WAN 203.0.113.10 and PBX 192.0.2.11;
  • WAN UDP/5060-5063 redirect to PBX UDP/5060;
  • outbound NAT from the PBX to 203.0.113.10 with static-port;
  • one inbound carrier packet from 198.51.100.128:5060 to the VIP to establish the redirect state;
  • one independent PBX packet from 192.0.2.11:5060 to 198.51.100.128:5060;
  • captures on WAN, LAN, and the carrier simulator;
  • before/after pfctl -si, pfctl -sn -vv, pfctl -sr -vv, pfctl -ss -vv, and pfctl -sl -vv.

Repeat without the redirect, with PBX source port 5062, without static-port, and with equivalent rules on vanilla FreeBSD. The annex contains the full control matrix and expected discriminators.

Disclosure

AI tools were used to correlate preserved read-only captures, PF state, NAT rules, counters, routing, interface, and CARP evidence and to prepare this draft. A human reporter has reviewed the final evidence, confirmed the sanitized address substitutions, and approved any submission.
#7
26.7, 26.10 Series / Re: FreeRADIUS MAC-Based Auth ...
Last post by firemywall - Today at 03:19:29 PM
Quote from: franco on <strong>Today</strong> at 10:33:05 AMWeird, but files are back now.

Thanks, my guest network lives again!
#8
Portuguese - Português / Re: FTP LIST/LS retorna erro 5...
Last post by zakrot93t - Today at 03:11:55 PM
A hipótese sobre a segmentação TCP é interessante, principalmente porque o problema acontece apenas no OPNsense. Uma captura simultânea nas interfaces pode ajudar a comparar os pacotes antes e depois do firewall e identificar exatamente onde ocorre a diferença.


Além de manter firewalls e sistemas bem configurados, também é importante cuidar dos drivers do computador para evitar problemas de compatibilidade. O Download Drive Booster Atualizado pode ser uma opção para usuários de Windows que desejam identificar e atualizar drivers desatualizados.
#9
General Discussion / Re: Has anyone heard of / trie...
Last post by Nullman - Today at 01:30:21 PM
Quote from: sopex on November 06, 2026, 09:24:20 PMThe biggest issue with these projects is that the person will get bored and abandon it... At that point, it will start breaking and you will have to either get your own AI to maintain or uninstall it.

Exactly this !!

Also, some people think just because its open source, if the author abandons it, someone else will just take over and continue development. But thats not how it works in real world. Once its abandoned, its abandoned forever. You are on your own.
#10
Hardware and Performance / Re: N150 Mini PC, RTL8153, AX8...
Last post by dogshome - Today at 12:44:55 PM
I am aware. This cable is screened and the sheath suitable for UV and outdoor weather. The cost difference is negligible for the one run and if I ever upgrade again, I won't be pulling it off the wall. I'd have put fibre if I'd thought about it, because it is tiny and robust :-)
Pages1 2 3 ... 10