"Recent posts
#1
26.1, 26,4 Series / Re: WireGuard does not start a...
Last post by AlPi - Today at 09:13:36 PMI was thinking about opening my own topic but don't want to clutter the forum.
If it turns out our cases are totally not related, I'll open another topic.
Really been pulling my hairs the last couple of days.
Had a perfectly working dual wireguard connection to Torguard in failover mode using a gateway group with separate monitor IPs. (FAR Gateway enabled and Disable routes enabled on the instance)
Currently running OPNsense 26.1.10 (amd64) on a physical box but unsure when the issues started to be honest.
I'm seeing strange issues with my wireguard setup.
With strange I mean:
packet loss with simple pings
commands like
Things I tried:
- Decreased the priority of the wireguard from 255 to 10
- Changed keepalive to 15
- Changed my dual tunnel setup to a single tunnel and deleted my gateway group..
- doubled checked mtu
- Checked github:
maybe somewhat related? https://github.com/opnsense/core/issues/10421
Things I also have that are mentioned in that thread:
UDP "no socket" drops — counter climbing continuously
sockstat — socket process ownership shows as unknown
Any additional information that maybe required, more than happy to share.
If it turns out our cases are totally not related, I'll open another topic.
Really been pulling my hairs the last couple of days.
Had a perfectly working dual wireguard connection to Torguard in failover mode using a gateway group with separate monitor IPs. (FAR Gateway enabled and Disable routes enabled on the instance)
Currently running OPNsense 26.1.10 (amd64) on a physical box but unsure when the issues started to be honest.
I'm seeing strange issues with my wireguard setup.
With strange I mean:
packet loss with simple pings
Code Select
ping -c 20 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=5 ttl=116 time=5.76 ms
64 bytes from 8.8.8.8: icmp_seq=6 ttl=116 time=5.98 ms
64 bytes from 8.8.8.8: icmp_seq=7 ttl=116 time=8.22 ms
64 bytes from 8.8.8.8: icmp_seq=8 ttl=116 time=12.6 ms
64 bytes from 8.8.8.8: icmp_seq=9 ttl=116 time=7.69 ms
64 bytes from 8.8.8.8: icmp_seq=10 ttl=116 time=7.89 ms
64 bytes from 8.8.8.8: icmp_seq=11 ttl=116 time=5.56 ms
64 bytes from 8.8.8.8: icmp_seq=12 ttl=116 time=9.48 ms
64 bytes from 8.8.8.8: icmp_seq=13 ttl=116 time=6.35 ms
64 bytes from 8.8.8.8: icmp_seq=14 ttl=116 time=5.65 ms
64 bytes from 8.8.8.8: icmp_seq=15 ttl=116 time=5.94 ms
64 bytes from 8.8.8.8: icmp_seq=16 ttl=116 time=6.88 ms
64 bytes from 8.8.8.8: icmp_seq=17 ttl=116 time=6.69 ms
64 bytes from 8.8.8.8: icmp_seq=18 ttl=116 time=5.89 ms
64 bytes from 8.8.8.8: icmp_seq=19 ttl=116 time=5.81 ms
64 bytes from 8.8.8.8: icmp_seq=20 ttl=116 time=6.22 ms
--- 8.8.8.8 ping statistics ---
20 packets transmitted, 16 received, 20% packet loss, time 19141ms
rtt min/avg/max/mdev = 5.558/7.035/12.573/1.791 ms
I do the test again a few minutes later and I get no ping timeouts. commands like
Code Select
curl ifconfig.io taking 1 second and 4-5 seconds the next minute or not giving a reply at all.Things I tried:
- Decreased the priority of the wireguard from 255 to 10
- Changed keepalive to 15
- Changed my dual tunnel setup to a single tunnel and deleted my gateway group..
- doubled checked mtu
Code Select
ifconfig wg2
wg2: flags=10080c1<UP,RUNNING,NOARP,MULTICAST,LOWER_UP> metric 0 mtu 1420
description: TorGuard_WG_Tunnel_00 (opt9)
options=80000<LINKSTATE>
inet 10.13.128.145 netmask 0xfffffffe
groups: wg wireguard
nd6 options=9<PERFORMNUD,IFDISABLED>- I'm seeing the issues from a VM that is only allowed access to the outside through wireguard so added firewall rules and outbound NAT rules to place a laptop also behind the VPN and also the same packet loss issue. (up to 70% on the first attempt, 0% on the second attempt,30% on the third attempt)- Checked github:
maybe somewhat related? https://github.com/opnsense/core/issues/10421
Things I also have that are mentioned in that thread:
UDP "no socket" drops — counter climbing continuously
Code Select
netstat -s -p udp | grep "no socket"
6154189 dropped due to no socket
sockstat — socket process ownership shows as unknown
Code Select
sockstat -4 | grep -E "57011"
? ? ? ? udp4 *:57011 *:*Code Select
netstat -I wg2
Name Mtu Network Address Ipkts Ierrs Idrop Opkts Oerrs Coll
wg2 1420 <Link#21> wg2 12511586 0 0 943160 0 0
wg2 - 10.13.128.144/31 10.13.128.145 16 - - 0 - -
I'm now going to try to connect to another ip at the VPN provider to see if that makes any difference.Any additional information that maybe required, more than happy to share.
#2
General Discussion / Help with OSFP setup and defau...
Last post by Linwood - Today at 09:08:34 PMI'm missing something, all the postings I've found didn't wor (but I may have missed some).
I have two opnsense systems that are local and trying to set up as a test bed for a future WAN deployment.
Right now I have them connected via an ethernet interface (VLAN 23) and am running ospf on each to exchange routes. That works fine for the subnets attached to each (that are selected).
But I want one of them to advertise it's default gateway to the other so that this other (downstream) opnsense sees this VLAN 23 connection as a default gateway.
More specifically:
OPNsense A (upstream, internet connected) :
WAN connection (external internet) is up, marked as upstream and a gateway. It's the only (ipv4) gateway
OSPF - set to advertise default gateway (with a metric of 33 so it shows oddly)
Various settings of Route Redistribution tried, in particular Connected and Statically
Area 0.0.0.166, stub, no-summary (can't selected anything but stub or worse)
Networks: VLAN for interconnect's subnet, plus LAN subnet
Interfaces: VLAN for interconnect and LAN
Opnsense B:
WAN connection currently disabled
Interconnect VLAN does NOT inherit a default gateway from DHCP (I have it explicitly off in DHCP option 3 for A)
No default gateay under system, gateway
OSPF no redistribution set (though i've tried several)
Area: 0.0.0.166, stub, no-summary
Networks: subnet of LAN, subnet of interconnected VLAN (i.e. same as set in A)
Interfaces: VLAN for interconnect, LAN
I end up with all the routes exactly as expected to the various VLAN's.
Under diagnostics, OSPF, I see a "N IA" entry for 0.0.0.0/0 cost 2 for the address on VLAN 23 for A. Metric is not the 33(+/-) I expected.
On B a shell netstat -r shows no default gateway.
So it's seeing a default gateway (though inter-area not redistributed), but not adding it to the route table.
Nothing interesting in the frr/ospf logs (loading done)
Listing 0.0.0.0/0 on A as a subnet seems to have no impact.
I can distribute the actual WAN's subnet and that works fine, but it doesn't yield a default gateway, only an external subnet's visibility.
Am I missing something? Do I have to create a static route to the default gateway (right now it's a WAN DHCP from ISP, but it's present and marked upstream)?
PS. Least someone ask this is preparation for a solar powered remote device which will have a cellular modem and also a RF connection. That RF connection will normally provide the default gateway when it's up, but when down the cellular should, so I want to inject the default via OSPF otherwise it gets "stuck" if it comes in via DHCP as due to the hardware involved the ethernet interface can still be up if the RF connection is down, but OSPF will go away, which will take its routes away, and I want 0.0.0.0 included.
I have two opnsense systems that are local and trying to set up as a test bed for a future WAN deployment.
Right now I have them connected via an ethernet interface (VLAN 23) and am running ospf on each to exchange routes. That works fine for the subnets attached to each (that are selected).
But I want one of them to advertise it's default gateway to the other so that this other (downstream) opnsense sees this VLAN 23 connection as a default gateway.
More specifically:
OPNsense A (upstream, internet connected) :
WAN connection (external internet) is up, marked as upstream and a gateway. It's the only (ipv4) gateway
OSPF - set to advertise default gateway (with a metric of 33 so it shows oddly)
Various settings of Route Redistribution tried, in particular Connected and Statically
Area 0.0.0.166, stub, no-summary (can't selected anything but stub or worse)
Networks: VLAN for interconnect's subnet, plus LAN subnet
Interfaces: VLAN for interconnect and LAN
Opnsense B:
WAN connection currently disabled
Interconnect VLAN does NOT inherit a default gateway from DHCP (I have it explicitly off in DHCP option 3 for A)
No default gateay under system, gateway
OSPF no redistribution set (though i've tried several)
Area: 0.0.0.166, stub, no-summary
Networks: subnet of LAN, subnet of interconnected VLAN (i.e. same as set in A)
Interfaces: VLAN for interconnect, LAN
I end up with all the routes exactly as expected to the various VLAN's.
Under diagnostics, OSPF, I see a "N IA" entry for 0.0.0.0/0 cost 2 for the address on VLAN 23 for A. Metric is not the 33(+/-) I expected.
On B a shell netstat -r shows no default gateway.
So it's seeing a default gateway (though inter-area not redistributed), but not adding it to the route table.
Nothing interesting in the frr/ospf logs (loading done)
Listing 0.0.0.0/0 on A as a subnet seems to have no impact.
I can distribute the actual WAN's subnet and that works fine, but it doesn't yield a default gateway, only an external subnet's visibility.
Am I missing something? Do I have to create a static route to the default gateway (right now it's a WAN DHCP from ISP, but it's present and marked upstream)?
PS. Least someone ask this is preparation for a solar powered remote device which will have a cellular modem and also a RF connection. That RF connection will normally provide the default gateway when it's up, but when down the cellular should, so I want to inject the default via OSPF otherwise it gets "stuck" if it comes in via DHCP as due to the hardware involved the ethernet interface can still be up if the RF connection is down, but OSPF will go away, which will take its routes away, and I want 0.0.0.0 included.
#3
General Discussion / [SOVLED] Re: Connecting to DHC...
Last post by gareththered - Today at 08:52:31 PMThe Intel I210 based NIC arrived and was fitted. The WAN is now stable.
Moral of the story is, don't rely on a RealTek NIC, even if it worked before. If you have to, use the vendor driver.
Moral of the story is, don't rely on a RealTek NIC, even if it worked before. If you have to, use the vendor driver.
#4
Hardware and Performance / Re: cpu-microcode-intel: no ma...
Last post by BrandyWine - Today at 08:35:14 PMProduction firewall?
Then schedule a maintenance window and run the loading from rc.local.
We're only talking about reboot times.
If the manual loading works with rc.local, then it's a ucode timing issue, leave it this way for now.
If the manual loading fails then it's something else more non-trivial.
If the manual test fails, just chmod -x rc.local and change loader.conf cpu_microcode_load back to "YES", then wait for support.
But let's clarify where to put a boot script, OPNsense is a bit "odd".
https://docs.opnsense.org/development/backend/autorun.html
stick the rc.local (or whatever you name it) in the "early" directory. I believe the daemon runs them per #, so name script 50-rc.local, etc.
/usr/local/etc/rc.syshook.d/early/
Then schedule a maintenance window and run the loading from rc.local.
We're only talking about reboot times.
If the manual loading works with rc.local, then it's a ucode timing issue, leave it this way for now.
If the manual loading fails then it's something else more non-trivial.
If the manual test fails, just chmod -x rc.local and change loader.conf cpu_microcode_load back to "YES", then wait for support.
But let's clarify where to put a boot script, OPNsense is a bit "odd".
https://docs.opnsense.org/development/backend/autorun.html
stick the rc.local (or whatever you name it) in the "early" directory. I believe the daemon runs them per #, so name script 50-rc.local, etc.
/usr/local/etc/rc.syshook.d/early/
#5
26.1, 26,4 Series / Re: Tor plugin not working?
Last post by qweqwe - Today at 05:15:21 PMthe same stuff
#6
Zenarmor (Sensei) / Re: Dashboard broken after 2.6...
Last post by Timeraider - Today at 04:40:21 PMYup, not just you sadly -_-
Always hope they test patches before pushing them out but well...
Always hope they test patches before pushing them out but well...
#7
26.1, 26,4 Series / Re: VLAN - DHCP/Gateway Issue ...
Last post by nero355 - Today at 02:40:28 PMQuote from: Mark_the_Red on June 19, 2026, 04:45:01 PMSwitch with POE+Also UniFi or something else ?!
And how were you planning to assign the correct VLAN :
- Manually configure Tagged/Untagged a.k.a. Native VLAN assigned to the Switchport.
- Perhaps RADIUS Authentication ?!
#8
26.1, 26,4 Series / Re: DNSMasq - Am I missing som...
Last post by nero355 - Today at 02:28:58 PMQuote from: besalope on June 19, 2026, 03:32:48 PMHosts:I am curious :
- .1-.89: Clients Static Reservation, use Pihole
- .90-.99: Clients Static Reservation, use Cloudflare. DNS-CloudFlare tag needs to be set on Host.
- .100-.150: Clients Dynamic, use Pihole
- .200-.253: Infrastructure/Proxmox Static Reservation, use Pihole
What was the reason for choosing to set it up like this instead of having 4 seperate networks ?
Also :
Since you have a lot of Static DHCP Mappings of which a part needs to be outside the Dynamic DHCP Scope I think KEA would have been the better path forward ?!
FYI :
- DNSmasqd wants the Static DHCP Mappings inside the Dynamic DHCP Range.
- ISC & KEA want the Static DHCP Mappings outside the Dynamic DHCP Range.
#9
General Discussion / Re: Business license question ...
Last post by DEC740airp414user - Today at 01:36:10 PMmy Only disappointment with Opnsense is when buying a new appliance the business license starts from the day of your purchase:
I did not realize this on my 2nd appliance and will be losing 3-4 months of the latest license.
when I setup the new appliance, I used my previous business licensing thinking I could then use the full new license when it expired. when it did expire and I put in the new key it showed I had 9 months remaining..
I then read the email from the appliance purchase and it said it started day of purchase. live and learn
I did not realize this on my 2nd appliance and will be losing 3-4 months of the latest license.
when I setup the new appliance, I used my previous business licensing thinking I could then use the full new license when it expired. when it did expire and I put in the new key it showed I had 9 months remaining..
I then read the email from the appliance purchase and it said it started day of purchase. live and learn
#10
26.1, 26,4 Series / Re: Change ISC DHCPv6 to KEA D...
Last post by Monviech (Cedrik) - Today at 12:16:53 PMHello,
0x17 cannot work with a reserved prefix range of 4 because 4 × /64 networks form a /62, and a /62 must start on a boundary divisible by 4.
Valid starts are:
0x10, 0x14, 0x18, 0x1c, ...
But 0x17 would require the range:
0x17, 0x18, 0x19, 0x1a
which crosses a /62 boundary and therefore cannot be represented as a single contiguous /62 prefix.
So if you want a reserved prefix range of 4, you'll need to use an aligned prefix ID such as 0x14 or 0x18.
Please note it is intentionally this way because you have to think about proper subnetting now. There are no assumptions and no magic left in the code.
I know this might seem a bit confusing at first, but it is essentially just normal IPv6 subnetting. The same alignment rules apply as when splitting IPv4 networks into smaller subnets.
0x17 cannot work with a reserved prefix range of 4 because 4 × /64 networks form a /62, and a /62 must start on a boundary divisible by 4.
Valid starts are:
0x10, 0x14, 0x18, 0x1c, ...
But 0x17 would require the range:
0x17, 0x18, 0x19, 0x1a
which crosses a /62 boundary and therefore cannot be represented as a single contiguous /62 prefix.
So if you want a reserved prefix range of 4, you'll need to use an aligned prefix ID such as 0x14 or 0x18.
Please note it is intentionally this way because you have to think about proper subnetting now. There are no assumptions and no magic left in the code.
I know this might seem a bit confusing at first, but it is essentially just normal IPv6 subnetting. The same alignment rules apply as when splitting IPv4 networks into smaller subnets.
