"Recent posts
#1
26.7 Series / Re: Setting up IPv6 - Firewall...
Last post by dseven - Today at 09:24:15 AMIf you're really only getting a /64 delegated prefix from your ISP (go to Interfaces -> Overview, click on the Details (magnifier) button for your WAN interface, and look for "Dynamic IPv6 prefix received"), you should not set a prefix ID at all for your WAN interface, since you need the one /64 that you have (prefix 0) for LAN. It'd be a bit curious if setting to "1" actually works - does your WAN interface have an address from that prefix now?
#2
26.7 Series / Re: Unbound stopps suddenly
Last post by Kinerg - Today at 08:24:32 AMQuote from: MiRei on August 26, 2026, 10:53:11 AMI have 4 GB of RAM in the system. The system is running at 30% capacity.
When unbound crashing it occurs after the DNS blocklist is updated,
which is done via cron once a day.
However, unbound does not crash every day after the cron job runs.
4 GB is not enough for newer versions with larger blocklists. It doesn't consume much while running, but dynamically it can shoot up rather high, especially for Unbound using blocklists. Try disabling them and see if the crashing changes.
#3
26.7 Series / Re: can't find where to delete...
Last post by RobLatour - Today at 04:27:41 AMJust to close this off ...
With the changes above I was still not able to assign my device 192.168.7.24 eventhough its lease had expired and the device was clearly defined to that ip address based on its mac address in the hosts table.
However, after additional trial and error I finally found what was blocking it.
On the OPNSense - Interace window related to this device, the is a field entitled IPv4 Address.
I had it populated with:
192.168.7.24 /24
In any case, I changed it to:
192.168.7.1 /24
and, Bob's your uncle, after I rebooted my device it picked up the IP address 192.168.7.24
Mystery solved.
With the changes above I was still not able to assign my device 192.168.7.24 eventhough its lease had expired and the device was clearly defined to that ip address based on its mac address in the hosts table.
However, after additional trial and error I finally found what was blocking it.
On the OPNSense - Interace window related to this device, the is a field entitled IPv4 Address.
I had it populated with:
192.168.7.24 /24
In any case, I changed it to:
192.168.7.1 /24
and, Bob's your uncle, after I rebooted my device it picked up the IP address 192.168.7.24
Mystery solved.
#4
26.1, 26,4 Series / Re: Unbound reporting stop wor...
Last post by jiggsjedi - Today at 02:04:18 AMFranco,
Are you able to share any updates here yet?
Thank you
Are you able to share any updates here yet?
Thank you
#5
Virtual private networks / Re: IPSec VTI
Last post by volga629 - Today at 02:01:42 AMAs I mention that opnsense BUG which I can reproduce 100%. Incorrect route is installed.
Opnsense Team please let me know what the process to get fix it permanently.
Reproduce
1. Setup UI VTI tunnel per doc
2. No traffic is pass through sometimes bidirectional, sometimes not.
3. Inspect route tables ( as you can see that route incorrect that will cause route loop )
Solution
Opnsense Team please let me know what the process to get fix it permanently.
Reproduce
1. Setup UI VTI tunnel per doc
2. No traffic is pass through sometimes bidirectional, sometimes not.
3. Inspect route tables ( as you can see that route incorrect that will cause route loop )
Code Select
[b]root@fw01:~ # route -n get 10.0.31.2
route to: 10.0.31.2
destination: 10.0.31.2
gateway: 10.0.31.1
fib: 0
interface: lo0[/b]
flags: <UP,GATEWAY,HOST,DONE,STATIC>
recvpipe sendpipe ssthresh rtt,msec mtu weight expire
0 0 0 0 16384 1 0
Code Select
root@fw01:~ # swanctl --list-sas
no files found matching '/usr/local/etc/strongswan.opnsense.d/*.conf'
da254f91-ea8e-49ef-b1ba-c1727fa06ec9: #1, ESTABLISHED, IKEv2, 99f3bd62c6f5692a_i 3220d485f8f7d532_r*
local 'local_pub_ip' @ local_pub_ip[500]
remote 'remote_pub_ip' @ remote_pub_ip[500]
AES_GCM_16-256/PRF_HMAC_SHA2_384/MODP_2048
established 137s ago, rekeying in 12896s
a9d737db-caa5-46a3-abd7-23b4a655c683: #3, reqid 10, INSTALLED, TUNNEL, ESP:AES_GCM_16-256
installed 137s ago, rekeying in 3213s, expires in 3823s
in c77db5ec, 7780 bytes, 264 packets
out c692722b, 0 bytes, 0 packets
local 0.0.0.0/0
remote 0.0.0.0/0
root@fw01:~ # ping 10.0.31.2
PING 10.0.31.2 (10.0.31.2): 56 data bytes
92 bytes from 127.0.0.1: Time to live exceeded
Vr HL TOS Len ID Flg off TTL Pro cks Src Dst
4 5 00 0054 32d6 0 0000 01 01 0000 127.0.0.1 10.0.31.2
92 bytes from 127.0.0.1: Time to live exceeded
Vr HL TOS Len ID Flg off TTL Pro cks Src Dst
4 5 00 0054 f40f 0 0000 01 01 0000 127.0.0.1 10.0.31.2
^C
--- 10.0.31.2 ping statistics ---
2 packets transmitted, 0 packets received, 100.0% packet loss
Solution
Code Select
root@fw01:~ # route -n delete 10.0.31.2
delete host 10.0.31.2
root@fw01:~ # route add -host 10.0.31.2 -iface ipsec10
add host 10.0.31.2: gateway ipsec10
root@fw01:~ # ping 10.0.31.2
PING 10.0.31.2 (10.0.31.2): 56 data bytes
64 bytes from 10.0.31.2: icmp_seq=0 ttl=64 time=33.805 ms
64 bytes from 10.0.31.2: icmp_seq=1 ttl=64 time=34.316 ms
64 bytes from 10.0.31.2: icmp_seq=2 ttl=64 time=30.993 ms
64 bytes from 10.0.31.2: icmp_seq=3 ttl=64 time=38.312 ms
64 bytes from 10.0.31.2: icmp_seq=4 ttl=64 time=32.543 ms
^C
--- 10.0.31.2 ping statistics ---
5 packets transmitted, 5 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 30.993/33.994/38.312/2.445 ms
root@fw01:~ #
#6
26.7 Series / Re: Setting up IPv6 - Firewall...
Last post by bawjaws - August 26, 2026, 11:50:30 PMAs always seems to be the case - typing out this message was all that was needed for the fix to be found! In my WAN config I had prefix ID 0 selected. Changing it to 1 seems to have fixed things!
#7
26.1, 26,4 Series / reply-to on outbound rules
Last post by ChristopherL - August 26, 2026, 11:44:05 PMI am doing outbound filtering on some interfaces. And I seem to have struck a similar issue to this person.
Eg. I have this rule on an interface:
I can allow traffic out of that interface with the following rule:
And then I can establish a TCP connection:
And I can see the states in PF:
However, if I replace the above floating rule with one that matches the interface:
I get responses, but the local firewall never completes the TCP handshake:
This is even worse when attempting to connect to something not on the same subnet as my device, where I never even see the Syn packet:
[Edit] I successfully recreated this now.
Though, I have sometimes seen the same behaviour as with local addresses (Syns and Syn-Acks but nothing more), I just haven't been able to recreate it for the sake of this post.
The issue appears to be that any rule on an interface with a gateway configured (inbound or outbound) will have a reply-to value created automatically by OPNsense. You can disable this with the Disable reply-to check-box in the Edit-rule pop-up, which fixes the problem.
But from my reading of man PF:
For reference:
Eg. I have this rule on an interface:
Code Select
root@opnsense-test:~ # pfctl -vvs rules | grep -A 3 "drop out log quick on ixl0"
@195 block drop out log quick on ixl0 reply-to (ixl0 192.0.2.1) inet all label "83448bc8-ca97-401d-86f2-57d67fb16fb2"
[ Evaluations: 211 Packets: 211 Bytes: 22618 States: 0 ]
[ Inserted: uid 0 pid 90386 State Creations: 0 ]
[ Last Active Time: Wed Aug 26 05:53:29 2026 ] I can allow traffic out of that interface with the following rule:
Code Select
root@opnsense-test:~ # pfctl -vvs rules | grep -A 3 5443b2cb-c3ca-4e0c-81cf-88c04c85f00f
@120 pass out log quick inet from (self:10) to any flags S/SA keep state label "5443b2cb-c3ca-4e0c-81cf-88c04c85f00f"
[ Evaluations: 11 Packets: 18 Bytes: 1946 States: 4 ]
[ Inserted: uid 0 pid 24 State Creations: 11 ]
[ Last Active Time: Wed Aug 26 05:45:02 2026 ] And then I can establish a TCP connection:
Code Select
root@opnsense-test:~ # telnet 192.0.2.49 8443
Trying 192.0.2.49...
Connected to 192.0.2.49.
Escape character is '^]'.
^]
telnet> Connection closed. And I can see the states in PF:
Code Select
root@opnsense-test:~ # pfctl -vvs states | grep -A3 192.0.2.49
all tcp 192.0.2.47:45666 -> 192.0.2.49:8443 ESTABLISHED:ESTABLISHED
[3811272169 + 16711936] wscale 7 [181588979 + 65792] wscale 7
age 00:00:02, expires in 23:59:58, 2:1 pkts, 112:60 bytes, rule 120
id: bddd8c6a00000000 creatorid: 3610e121 However, if I replace the above floating rule with one that matches the interface:
Code Select
@148 pass out quick on ixl0 reply-to (ixl0 192.0.2.1) inet all flags S/SA keep state label "ed13d8d2-e403-4cf7-ba41-6b698f76643e"
[ Evaluations: 36 Packets: 33 Bytes: 3751 States: 22 ]
[ Inserted: uid 0 pid 70434 State Creations: 22 ]
[ Last Active Time: Wed Aug 26 06:14:36 2026 I get responses, but the local firewall never completes the TCP handshake:
Code Select
root@opnsense-test:~ # telnet 192.0.2.49 8443
Trying 192.0.2.49...
^C
root@opnsense-test:~ # pfctl -vvs states | grep -A 3 192.0.2.49
all tcp 192.0.2.47:59825 -> 192.0.2.49:8443 ESTABLISHED:SYN_SENT
[3105104415 + 4294902016] wscale 7 [4173125645 + 4294902016] wscale 7
age 00:00:10, expires in 00:00:28, 2:5 pkts, 120:300 bytes, rule 148
id: 07de8c6a00000000 creatorid: 3610e121 reply-to: 192.0.2.1@ixl0 Code Select
root@opnsense-test:~ # tcpdump -nevi ixl0 host 192.0.2.49
tcpdump: listening on ixl0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
06:17:38.604709 38:68:dd:66:ac:e8 > 38:68:dd:66:7d:b0, ethertype IPv4 (0x0800), length 74: (tos 0x10, ttl
64, id 0, offset 0, flags [DF], proto TCP (6), length 60)
192.0.2.47.50028 > 192.0.2.49.8443: Flags [S], cksum 0xff66 (correct), seq 4278843326, win 652
28, options [mss 1460,nop,wscale 7,sackOK,TS val 2155498607 ecr 0], length 0
06:17:38.604815 38:68:dd:66:7d:b0 > 38:68:dd:66:ac:e8, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 6
4, id 0, offset 0, flags [DF], proto TCP (6), length 60)
192.0.2.49.8443 > 192.0.2.47.50028: Flags [S.], cksum 0x5bb6 (correct), seq 1043354308, ack 42
78843327, win 65228, options [mss 1460,nop,wscale 7,sackOK,TS val 2956288629 ecr 2155498607], length 0
06:17:39.628574 38:68:dd:66:ac:e8 > 38:68:dd:66:7d:b0, ethertype IPv4 (0x0800), length 74: (tos 0x10, ttl
64, id 0, offset 0, flags [DF], proto TCP (6), length 60)
192.0.2.47.50028 > 192.0.2.49.8443: Flags [S], cksum 0xfb66 (correct), seq 4278843326, win 652
28, options [mss 1460,nop,wscale 7,sackOK,TS val 2155499631 ecr 0], length 0
06:17:39.628651 38:68:dd:66:7d:b0 > 38:68:dd:66:ac:e8, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 6
4, id 0, offset 0, flags [DF], proto TCP (6), length 60)
192.0.2.49.8443 > 192.0.2.47.50028: Flags [S.], cksum 0x57b6 (correct), seq 1043354308, ack 4$
78843327, win 65228, options [mss 1460,nop,wscale 7,sackOK,TS val 2956289653 ecr 2155498607], length 0
06:17:39.628762 38:68:dd:66:7d:b0 > 38:68:dd:66:ac:e8, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 6
4, id 0, offset 0, flags [DF], proto TCP (6), length 60)
192.0.2.49.8443 > 192.0.2.47.50028: Flags [S.], cksum 0x53b6 (correct), seq 1043354308, ack 42
78843327, win 65228, options [mss 1460,nop,wscale 7,sackOK,TS val 2956289653 ecr 2155499631], length 0
06:17:40.690948 38:68:dd:66:7d:b0 > 38:68:dd:66:ac:e8, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 6
4, id 0, offset 0, flags [DF], proto TCP (6), length 60)
192.0.2.49.8443 > 192.0.2.47.50028: Flags [S.], cksum 0x4f90 (correct), seq 1043354308, ack 42
78843327, win 65228, options [mss 1460,nop,wscale 7,sackOK,TS val 2956290715 ecr 2155499631], length 0[Edit] I successfully recreated this now.
Code Select
root@opnsense-test:~ # telnet 198.51.100.1 8443
Trying 198.51.100.1...
^C
root@opnsense-test:~ # pfctl -vvs states | grep -A 3 198.51
No ALTQ support in kernel
ALTQ related functions disabled
all tcp 192.0.2.47:18469 -> 198.51.100.1:8443 ESTABLISHED:SYN_SENT
[1406893479 + 4294705408] wscale 7 [2561759781 + 4294902016] wscale 7
age 00:01:11, expires in 00:00:23, 7:12 pkts, 420:720 bytes, rule 146
id: 8de98c6a00000000 creatorid: 3610e121 reply-to: 192.0.2.1@ixl0
Code Select
root@opnsense-test:~ # tcpdump -nevi ixl0 tcp port 8443
tcpdump: listening on ixl0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
21:55:52.902296 38:68:dd:66:ac:e8 > 00:00:5e:00:01:01, ethertype IPv4 (0x0800), length 74: (tos 0x10, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60)
192.0.2.47.61030 > 198.51.100.1.8443: Flags [S], cksum 0xef3a (correct), seq 2484399761, win 65228, options [mss 1460,nop,wscale 7,sackOK,TS val 416987146 ecr 0], length 0
21:55:52.912149 e2:39:b3:4e:bc:47 > 38:68:dd:66:ac:e8, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 59, id 0, offset 0, flags [DF], proto TCP (6), length 60)
198.51.100.1.8443 > 192.0.2.47.61030: Flags [S.], cksum 0xd0d9 (correct), seq 3967036082, ack 2484399762, win 64492, options [mss 1414,sackOK,TS val 3376431350 ecr 416987146,nop,wscale 7], length 0
21:55:53.902416 38:68:dd:66:ac:e8 > 00:00:5e:00:01:01, ethertype IPv4 (0x0800), length 74: (tos 0x10, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60)
192.0.2.47.61030 > 198.51.100.1.8443: Flags [S], cksum 0xeb52 (correct), seq 2484399761, win 65228, options [mss 1460,nop,wscale 7,sackOK,TS val 416988146 ecr 0], length 0
21:55:53.912051 e2:39:b3:4e:bc:47 > 38:68:dd:66:ac:e8, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 59, id 0, offset 0, flags [DF], proto TCP (6), length 60)
198.51.100.1.8443 > 192.0.2.47.61030: Flags [S.], cksum 0xccf1 (correct), seq 3967036082, ack 2484399762, win 64492, options [mss 1414,sackOK,TS val 3376432350 ecr 416987146,nop,wscale 7], length 0
21:55:54.940966 e2:39:b3:4e:bc:47 > 38:68:dd:66:ac:e8, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 59, id 0, offset 0, flags [DF], proto TCP (6), length 60)
198.51.100.1.8443 > 192.0.2.47.61030: Flags [S.], cksum 0xc8ec (correct), seq 3967036082, ack 2484399762, win 64492, options [mss 1414,sackOK,TS val 3376433379 ecr 416987146,nop,wscale 7], length 0
^C The issue appears to be that any rule on an interface with a gateway configured (inbound or outbound) will have a reply-to value created automatically by OPNsense. You can disable this with the Disable reply-to check-box in the Edit-rule pop-up, which fixes the problem.
But from my reading of man PF:
Code Select
reply-to
The reply-to option is similar to route-to, but routes packets that
pass in the opposite direction (replies) to the specified interface.
Opposite direction is only defined in the context of a state entry,
and reply-to is useful only in rules that create state. It can be
used on systems with multiple external connections to route all out-
going packets of a connection through the interface the incoming con-
nection arrived through (symmetric routing enforcement).It seems to me that the reply-to field on an outbound rule doesn't make sense. Shouldn't replies always be coming back to the firewall itself for an outbound rule? Or am I misunderstanding the purpose of the reply-to field here?For reference:
Code Select
Type opnsense-business
Version 26.4.1p2
Architecture amd64 #8
26.7 Series / Setting up IPv6 - Firewall can...
Last post by bawjaws - August 26, 2026, 11:38:49 PMHi! I'm trying to get IPv6 working on my local network. I've configured it as follows:
WAN: DHCPv6 (requested a /56 but been assigned a /64. I'll take that up with my ISP later, as I'm just looking to get one LAN working for now, which I think a /64 will let me do?)
LAN: SLAAC (using Identity Association)
Router Advertisements: Enabled for LAN i/f, Unmanaged mode, 30 and 60 interval timers
I've confirmed that all IPv6 capable devices are configuring themselves with an IPv6 address using the first 64 bits of the ISP-assigned address. They also have a bunch of other link-local and "temp" addresses.
I've updated the exsiting IPv4 firewall rules to now also include IPv6 traffic, and I've also allowed all IPv6 ICMP traffic.
The OPNSense box can ping on IPv6 out to the internet without a problem. However, clients on the LAN are unable to ping out to the internet. They can ping the link-local address of the default gateway (which is the OPNsense LAN interface), but they cannot ping the global IPv6 address of this interface.
I'm sort of at a loss now as to what the problem could be. I done a packet capture for the pings from clients, and it showed the ping going out to the internet, then the response coming back into the OPNsense box, but the next packet was then an ICMP unreachable back out to the internet - like the OPNSense box can't reach the IPv6 address configured on the LAN. One thing I noticed is that in the Neighbour Discovery table on OPNsense, it doesn't have an entry for the global IPv6 address for the client. I'd have expected this to have been populated.
Does anyone have any advice or suggestions?
Kevin
WAN: DHCPv6 (requested a /56 but been assigned a /64. I'll take that up with my ISP later, as I'm just looking to get one LAN working for now, which I think a /64 will let me do?)
LAN: SLAAC (using Identity Association)
Router Advertisements: Enabled for LAN i/f, Unmanaged mode, 30 and 60 interval timers
I've confirmed that all IPv6 capable devices are configuring themselves with an IPv6 address using the first 64 bits of the ISP-assigned address. They also have a bunch of other link-local and "temp" addresses.
I've updated the exsiting IPv4 firewall rules to now also include IPv6 traffic, and I've also allowed all IPv6 ICMP traffic.
The OPNSense box can ping on IPv6 out to the internet without a problem. However, clients on the LAN are unable to ping out to the internet. They can ping the link-local address of the default gateway (which is the OPNsense LAN interface), but they cannot ping the global IPv6 address of this interface.
I'm sort of at a loss now as to what the problem could be. I done a packet capture for the pings from clients, and it showed the ping going out to the internet, then the response coming back into the OPNsense box, but the next packet was then an ICMP unreachable back out to the internet - like the OPNSense box can't reach the IPv6 address configured on the LAN. One thing I noticed is that in the Neighbour Discovery table on OPNsense, it doesn't have an entry for the global IPv6 address for the client. I'd have expected this to have been populated.
Does anyone have any advice or suggestions?
Kevin
#9
26.7 Series / Re: Unbound stopps suddenly
Last post by DEC740airp414user - August 26, 2026, 11:24:37 PMtoday is the first time I have ever had ERRORS within unbound. I am not having any issues resolving
ill probably roll back to business edition now
ill probably roll back to business edition now
#10
26.7 Series / Re: Interfaces: Virtual IPs: S...
Last post by notspam - August 26, 2026, 10:18:21 PMThe problem is a bit the thread starter itself.
Without knowledge of basic network design rules all effort is in reality a waste of time.
It is important to seriously consider the issues and not just start building without a plan.
I have rarely read so many false things.
Without knowledge of basic network design rules all effort is in reality a waste of time.
It is important to seriously consider the issues and not just start building without a plan.
I have rarely read so many false things.
