"Recent posts
#1
26.7 Series / Re: 26.7.1: "state-insert,bloc...
Last post by fastboot - Today at 08:16:27 AM #2
26.7 Series / Re: 26.7.1: "state-insert,bloc...
Last post by fastboot - Today at 08:00:15 AMHi @SonicJoe,
that was my first assumption. I disabled the divert to of the rules that allow the flows. But in my case it did not help. I also checked the corresponding logs for suricata and could not find any blocks. For example "dest_port:123" should trigger a hit in the suricata logs, as this was blocked.
@franco: Help please
that was my first assumption. I disabled the divert to of the rules that allow the flows. But in my case it did not help. I also checked the corresponding logs for suricata and could not find any blocks. For example "dest_port:123" should trigger a hit in the suricata logs, as this was blocked.
@franco: Help please
#3
26.7 Series / Re: 26.7.1: "state-insert,bloc...
Last post by SonicJoe - Today at 03:15:24 AMI am seeing this too in relation to Suricata in Divert mode. Inbound packets on my WAN rules are getting evaluated twice (occasionally 3 times), first time is a pass and then the second (or last) time it is dropped for "state-insert,block". If I remove the divert-to from the rule, then it works normally.
Example:
The affected rules are associated with destination NATs. In the example its TCP/UDP 5060 (SIP) from the WAN to the DMZ server 10.7.0.10, but I also have rules for 80 and 443 with the same results.
Edit: I forgot to mention that mine was working fine on 26.1, and I only saw this behavior after updating to 26.7.1.
Example:
Code Select
root@home:~ # tail -f /var/log/filter/latest.log | grep 5060
<134>1 2026-07-25T20:52:58-04:00 home.example.com filterlog 30391 - [meta sequenceId="420777"] 187,,,55e761c8-fbf4-4921-a72a-5824b67416b7,igc0,match,pass,in,4,0x68,,122,22381,0,none,17,udp,1188,34.226.36.34,10.7.0.10,5060,5060,1168
<134>1 2026-07-25T20:52:58-04:00 home.example.com filterlog 30391 - [meta sequenceId="420778"] 187,,,55e761c8-fbf4-4921-a72a-5824b67416b7,igc0,match,pass,in,4,0x68,,122,22381,0,none,17,udp,1188,34.226.36.34,10.7.0.10,5060,5060,1168
<134>1 2026-07-25T20:52:58-04:00 home.example.com filterlog 30391 - [meta sequenceId="420779"] 187,,,55e761c8-fbf4-4921-a72a-5824b67416b7,igc0,state-insert,block,in,4,0x68,,122,22381,0,none,17,udp,1188,34.226.36.34,10.7.0.10,5060,5060,1168
<134>1 2026-07-25T20:52:59-04:00 home.example.com filterlog 30391 - [meta sequenceId="420785"] 187,,,55e761c8-fbf4-4921-a72a-5824b67416b7,igc0,match,pass,in,4,0x68,,122,22403,0,none,17,udp,1188,34.226.36.34,10.7.0.10,5060,5060,1168
<134>1 2026-07-25T20:52:59-04:00 home.example.com filterlog 30391 - [meta sequenceId="420786"] 187,,,55e761c8-fbf4-4921-a72a-5824b67416b7,igc0,state-insert,block,in,4,0x68,,122,22403,0,none,17,udp,1188,34.226.36.34,10.7.0.10,5060,5060,1168
<134>1 2026-07-25T20:52:59-04:00 home.example.com filterlog 30391 - [meta sequenceId="420795"] 187,,,55e761c8-fbf4-4921-a72a-5824b67416b7,igc0,match,pass,in,4,0x68,,122,22456,0,none,17,udp,1188,34.226.36.34,10.7.0.10,5060,5060,1168
<134>1 2026-07-25T20:52:59-04:00 home.example.com filterlog 30391 - [meta sequenceId="420796"] 187,,,55e761c8-fbf4-4921-a72a-5824b67416b7,igc0,state-insert,block,in,4,0x68,,122,22456,0,none,17,udp,1188,34.226.36.34,10.7.0.10,5060,5060,1168
<134>1 2026-07-25T20:53:00-04:00 home.example.com filterlog 30391 - [meta sequenceId="420799"] 187,,,55e761c8-fbf4-4921-a72a-5824b67416b7,igc0,match,pass,in,4,0x68,,122,40213,0,none,17,udp,1190,34.210.91.112,10.7.0.10,5060,5060,1170
<134>1 2026-07-25T20:53:00-04:00 home.example.com filterlog 30391 - [meta sequenceId="420800"] 187,,,55e761c8-fbf4-4921-a72a-5824b67416b7,igc0,match,pass,in,4,0x68,,122,40213,0,none,17,udp,1190,34.210.91.112,10.7.0.10,5060,5060,1170
<134>1 2026-07-25T20:53:00-04:00 home.example.com filterlog 30391 - [meta sequenceId="420801"] 187,,,55e761c8-fbf4-4921-a72a-5824b67416b7,igc0,state-insert,block,in,4,0x68,,122,40213,0,none,17,udp,1190,34.210.91.112,10.7.0.10,5060,5060,1170
<134>1 2026-07-25T20:53:00-04:00 home.example.com filterlog 30391 - [meta sequenceId="420806"] 187,,,55e761c8-fbf4-4921-a72a-5824b67416b7,igc0,match,pass,in,4,0x68,,122,40233,0,none,17,udp,1190,34.210.91.112,10.7.0.10,5060,5060,1170
<134>1 2026-07-25T20:53:00-04:00 home.example.com filterlog 30391 - [meta sequenceId="420807"] 187,,,55e761c8-fbf4-4921-a72a-5824b67416b7,igc0,state-insert,block,in,4,0x68,,122,40233,0,none,17,udp,1190,34.210.91.112,10.7.0.10,5060,5060,1170
<134>1 2026-07-25T20:53:01-04:00 home.example.com filterlog 30391 - [meta sequenceId="420811"] 187,,,55e761c8-fbf4-4921-a72a-5824b67416b7,igc0,match,pass,in,4,0x68,,122,40250,0,none,17,udp,1190,34.210.91.112,10.7.0.10,5060,5060,1170
<134>1 2026-07-25T20:53:01-04:00 home.example.com filterlog 30391 - [meta sequenceId="420812"] 187,,,55e761c8-fbf4-4921-a72a-5824b67416b7,igc0,state-insert,block,in,4,0x68,,122,40250,0,none,17,udp,1190,34.210.91.112,10.7.0.10,5060,5060,1170
<134>1 2026-07-25T20:53:01-04:00 home.example.com filterlog 30391 - [meta sequenceId="420813"] 187,,,55e761c8-fbf4-4921-a72a-5824b67416b7,igc0,match,pass,in,4,0x68,,122,40271,0,none,17,udp,1190,34.210.91.112,10.7.0.10,5060,5060,1170
<134>1 2026-07-25T20:53:01-04:00 home.example.com filterlog 30391 - [meta sequenceId="420814"] 187,,,55e761c8-fbf4-4921-a72a-5824b67416b7,igc0,state-insert,block,in,4,0x68,,122,40271,0,none,17,udp,1190,34.210.91.112,10.7.0.10,5060,5060,1170
<134>1 2026-07-25T20:53:02-04:00 home.example.com filterlog 30391 - [meta sequenceId="420818"] 187,,,55e761c8-fbf4-4921-a72a-5824b67416b7,igc0,match,pass,in,4,0x68,,122,40298,0,none,17,udp,1190,34.210.91.112,10.7.0.10,5060,5060,1170
<134>1 2026-07-25T20:53:02-04:00 home.example.com filterlog 30391 - [meta sequenceId="420819"] 187,,,55e761c8-fbf4-4921-a72a-5824b67416b7,igc0,state-insert,block,in,4,0x68,,122,40298,0,none,17,udp,1190,34.210.91.112,10.7.0.10,5060,5060,1170
<134>1 2026-07-25T20:53:02-04:00 home.example.com filterlog 30391 - [meta sequenceId="420825"] 187,,,55e761c8-fbf4-4921-a72a-5824b67416b7,igc0,match,pass,in,4,0x68,,122,40337,0,none,17,udp,1190,34.210.91.112,10.7.0.10,5060,5060,1170
<134>1 2026-07-25T20:53:02-04:00 home.example.com filterlog 30391 - [meta sequenceId="420826"] 187,,,55e761c8-fbf4-4921-a72a-5824b67416b7,igc0,state-insert,block,in,4,0x68,,122,40337,0,none,17,udp,1190,34.210.91.112,10.7.0.10,5060,5060,1170
<134>1 2026-07-25T20:53:03-04:00 home.example.com filterlog 30391 - [meta sequenceId="420830"] 187,,,55e761c8-fbf4-4921-a72a-5824b67416b7,igc0,match,pass,in,4,0x68,,122,22595,0,none,17,udp,1188,34.226.36.34,10.7.0.10,5060,5060,1168
<134>1 2026-07-25T20:53:03-04:00 home.example.com filterlog 30391 - [meta sequenceId="420831"] 187,,,55e761c8-fbf4-4921-a72a-5824b67416b7,igc0,state-insert,block,in,4,0x68,,122,22595,0,none,17,udp,1188,34.226.36.34,10.7.0.10,5060,5060,1168
<134>1 2026-07-25T20:53:03-04:00 home.example.com filterlog 30391 - [meta sequenceId="420834"] 187,,,55e761c8-fbf4-4921-a72a-5824b67416b7,igc0,match,pass,in,4,0x68,,122,22606,0,none,17,udp,1188,34.226.36.34,10.7.0.10,5060,5060,1168
<134>1 2026-07-25T20:53:03-04:00 home.example.com filterlog 30391 - [meta sequenceId="420835"] 187,,,55e761c8-fbf4-4921-a72a-5824b67416b7,igc0,state-insert,block,in,4,0x68,,122,22606,0,none,17,udp,1188,34.226.36.34,10.7.0.10,5060,5060,1168
<134>1 2026-07-25T20:53:04-04:00 home.example.com filterlog 30391 - [meta sequenceId="420838"] 187,,,55e761c8-fbf4-4921-a72a-5824b67416b7,igc0,match,pass,in,4,0x68,,122,22636,0,none,17,udp,1188,34.226.36.34,10.7.0.10,5060,5060,1168
<134>1 2026-07-25T20:53:04-04:00 home.example.com filterlog 30391 - [meta sequenceId="420839"] 187,,,55e761c8-fbf4-4921-a72a-5824b67416b7,igc0,state-insert,block,in,4,0x68,,122,22636,0,none,17,udp,1188,34.226.36.34,10.7.0.10,5060,5060,1168
The affected rules are associated with destination NATs. In the example its TCP/UDP 5060 (SIP) from the WAN to the DMZ server 10.7.0.10, but I also have rules for 80 and 443 with the same results.
Edit: I forgot to mention that mine was working fine on 26.1, and I only saw this behavior after updating to 26.7.1.
#4
General Discussion / Re: Periodic NIC issues (?) wi...
Last post by BrandyWine - Today at 02:54:34 AMThis is a good read, seems more like router tuning.
https://docs.opnsense.org/manual/interfaces_settings.html
What's the status of your fix?
https://docs.opnsense.org/manual/interfaces_settings.html
What's the status of your fix?
#5
General Discussion / Re: WAN Static IP Breaks LAN I...
Last post by wiring8228 - Today at 01:00:11 AMThank you both for your help :)
I was able to fix the problem with a Source NAT rule in hybrid mode, for which I used the following settings:
Interface: WAN
Version: IPv4
Protocol: any
Source Address: LAN network
Destination Address: any
Destination port: any
Translate Source IP: WAN address
Translate Source Port: any
I suspect I'll need to create a second rule for IPv6 here, since I can't select both in the same rule. Should I adjust the rule in any other way? I haven't worked much with NAT so far — usually just inbound NAT.
I was able to fix the problem with a Source NAT rule in hybrid mode, for which I used the following settings:
Interface: WAN
Version: IPv4
Protocol: any
Source Address: LAN network
Destination Address: any
Destination port: any
Translate Source IP: WAN address
Translate Source Port: any
I suspect I'll need to create a second rule for IPv6 here, since I can't select both in the same rule. Should I adjust the rule in any other way? I haven't worked much with NAT so far — usually just inbound NAT.
#6
26.7 Series / Re: Upgrade 26.7.1 to 26.7.1_1...
Last post by MoonbeamFrame - Today at 01:00:02 AMI've seen this behavior as well:
https://forum.opnsense.org/index.php?topic=52494.msg271271#msg271271
https://forum.opnsense.org/index.php?topic=52494.msg271271#msg271271
#7
26.7 Series / Re: slow dhcp on wan -> broken...
Last post by synfinatic - July 25, 2026, 10:24:42 PMMeant to mention that for outbound NAT I'm using "Manual outbound NAT rule generation" and selecting NAT Address: "interface address"
#8
Zenarmor (Sensei) / Re: Important Announcement for...
Last post by dirtyfreebooter - July 25, 2026, 08:41:28 PMi had the same random cloudflare rate limits: https://forum.opnsense.org/index.php?topic=52181.0
i also reported this a few months ago. nothing was done or even acknowledged
i also reported this a few months ago. nothing was done or even acknowledged
#9
26.7 Series / slow dhcp on wan -> broken NAT
Last post by synfinatic - July 25, 2026, 07:47:57 PMThis was happening on 26.1.x and continues on 26.7.1. I'm on AT&T fiber and using an AZORES WAS-110 fiber module/ONT to bypass the AT&T provided gateway. For this to work, my `ixl0` interface uses DHCP/DHCPv6 to get IP addresses and I create a virtual IP (192.168.11.10/24) on `ixl0` in order to manage the WAS-110 module.
The problem is that for whatever reason, getting an IP address from AT&T is _slow_. After rebooting the firewall, I often have to login and manually run `dhclient ixl0` to force it to try again and that works. Once an IPv4 address is obtained, DHCPv6 seems to happen automatically.
The problem is that the system seems to not really register that an IPv4 address has been obtained and so NAT is broken- running `tcpdump -ni ixl0` shows traffic egressing with a source IP of 192.168.11.10- not the public IP that AT&T has given via DHCP. I've figured out that I can fix this by going into the interface config setting and re-applying the existing settings, but this sucks.
Seems like the root cause of the issue is AT&T being slow to give out an IP address over DHCP- any way to make things more robust?
The problem is that for whatever reason, getting an IP address from AT&T is _slow_. After rebooting the firewall, I often have to login and manually run `dhclient ixl0` to force it to try again and that works. Once an IPv4 address is obtained, DHCPv6 seems to happen automatically.
The problem is that the system seems to not really register that an IPv4 address has been obtained and so NAT is broken- running `tcpdump -ni ixl0` shows traffic egressing with a source IP of 192.168.11.10- not the public IP that AT&T has given via DHCP. I've figured out that I can fix this by going into the interface config setting and re-applying the existing settings, but this sucks.
Seems like the root cause of the issue is AT&T being slow to give out an IP address over DHCP- any way to make things more robust?
#10
26.1, 26,4 Series / Re: 26.1 upgrade chaos, Realte...
Last post by nero355 - July 25, 2026, 07:39:02 PMQuote from: computer_freak_8 on July 25, 2026, 07:27:32 PMRTL8111EAFAIK that's a very old RealTek NIC Chip used as Onboard NIC for a lot of devices and might be declared as EOL by the people who build the FreeBSD Kernel so you could check that and see if there is a solution available for those who want to use it anyway ?
