"Recent posts
#1
General Discussion / Re: Help with GeoIP and csv fo...
Last post by meyergru - Today at 09:45:12 AMInteresting. Their database seems to be bigger at 17 MByte than Maxmind's GeoIP Lite at 11 MByte.
I just emailed them if they could provide a compressed CSV version like Maxmind.
That being said, if you need more accurate data than Maxmind's, which is also free, you can use ipinfo.io, like explained here.
I just emailed them if they could provide a compressed CSV version like Maxmind.
That being said, if you need more accurate data than Maxmind's, which is also free, you can use ipinfo.io, like explained here.
#2
Virtual private networks / Re: Alias in openVPN's routing...
Last post by henri9813 - Today at 09:24:49 AMHello,
This would be very great !
We have many users, in differnt team, when we add a new host to a team, it's a nightmare, we must pass time on EACH account to add the SAME entry whreeas for the same node's adding on the Firewall rule, the simple fact of updating the alias is enough.
Best regards !
This would be very great !
We have many users, in differnt team, when we add a new host to a team, it's a nightmare, we must pass time on EACH account to add the SAME entry whreeas for the same node's adding on the Firewall rule, the simple fact of updating the alias is enough.
Best regards !
#3
Virtual private networks / Re: Always On VPN (Wireguard) ...
Last post by keeka - Today at 09:13:29 AMQuote from: foss-johnny on Today at 08:46:31 AMI'm finding when switching from 5g to wifi, I need to turn off/on wifi and wg off/on and then it works correctly again. As if the routing needs to be reset.
Do you ever need to do this?
Other than brief delays when the phone switches from wifi to mobile, no. I never need to restart android client or toggle wifi/mobile. Having said that I am not a heavy mobile user. But the only times I experience VPN connection issues is if I am out and lose mobile signal.
#4
26.1, 26,4 Series / Unbound TCP drops every 7.5min...
Last post by Multiplex - Today at 08:58:52 AMSystem Admin here, looking for a permanent fix for the following issue (without manual system file edits). Since networking isn't my primary focus, I've used AI to help document the technical details, which I've pasted below.
## Environment
- **OPNsense version:** 26.1.6_2-amd64
- **FreeBSD:** 14.3-RELEASE-p10
- **OpenSSL:** 3.0.20
- **ISP:** Optus NBN Australia
- **WAN:** DHCP with 900 second lease (renews every 7.5 minutes)
- **Unbound:** DNS over TLS (DoT) to 1.1.1.1:853 and 9.9.9.9:853
- **Downstream:** Two Pi-hole instances forwarding to Unbound at 192.168.9.254:53
- Pi-hole Core v6.4.1
- FTL v6.6
- Web Interface v6.5
---
## The Problem
Both Pi-hole instances intermittently log the following warning:
```
WARNING Connection error (192.168.9.254#53): TCP connection failed while
receiving payload length from upstream (Connection prematurely closed by
remote server)
```
The errors occur with precise regularity — every 7.5 minutes — matching exactly the Optus DHCP lease renewal interval.
---
## Investigation
### Step 1 — Ruled out Unbound restarts
Checked the resolver log for Unbound stop/start events during the error windows:
```
grep "start of service\|service stopped" /var/log/resolver/latest.log
```
Unbound was **not restarting** during the error windows. The TCP connection was being closed without Unbound being killed.
---
### Step 2 — Found the DHCP correlation
Cross-referencing the Pi-hole FTL log against the OPNsense system log revealed a consistent pattern:
**System log:**
```
2026-05-09T15:33:59 dhclient-script: Reason RENEW on igc0 executing
2026-05-09T15:33:59 dhclient-script: Creating resolv.conf
2026-05-09T15:41:29 dhclient-script: Reason RENEW on igc0 executing
2026-05-09T15:41:29 dhclient-script: Creating resolv.conf
2026-05-09T15:48:59 dhclient-script: Reason RENEW on igc0 executing
2026-05-09T15:48:59 dhclient-script: Creating resolv.conf
```
**Pi-hole FTL log:**
```
2026-05-09 15:38:15 WARNING Connection error (192.168.9.254#53): TCP connection failed
2026-05-09 15:41:46 WARNING Connection error (192.168.9.254#53): TCP connection failed
2026-05-09 15:50:07 WARNING Connection error (192.168.9.254#53): TCP connection failed
```
Every single TCP error correlates with a preceding DHCP RENEW. No RENEW = no error.
---
### Step 3 — Confirmed IP is not changing
The DHCP lease file confirms the WAN IP is stable across renewals:
```
option dhcp-lease-time 900;
```
The cached IP file also confirms no change:
```
cat /tmp/igc0_oldip
175.32.32.48
```
The renewal is a simple lease extension — the IP, gateway, and DNS servers do not change.
---
### Step 4 — Traced the dhclient script
Reading `/usr/local/opnsense/scripts/interfaces/dhclient-script`, the `BOUND|RENEW|REBIND|REBOOT` block contains the following:
```sh
changes="no"
if [ -n "$old_ip_address" ]; then
if [ "$old_ip_address" != "$new_ip_address" ]; then
delete_old_address
delete_old_routes
changes="yes"
fi
fi
if [ "$reason" = BOUND ] || \
[ "$reason" = REBOOT ] || \
[ -z "$old_ip_address" ] || \
[ "$old_ip_address" != "$new_ip_address" ]; then
add_new_address
add_new_routes
changes="yes"
fi
add_new_resolv_conf # <-- called unconditionally on every RENEW
if [ "$changes" = "yes" ] ; then
/usr/local/sbin/configctl -d interface newip $interface force
fi
```
`add_new_resolv_conf` is called **unconditionally** on every RENEW, regardless of whether anything has actually changed. When the IP has not changed, `changes` remains `"no"` and `configctl interface newip` is correctly skipped — but `add_new_resolv_conf` still runs every time.
---
### Step 5 — Traced what add_new_resolv_conf does
```sh
add_new_resolv_conf()
{
$LOGGER "Creating resolv.conf"
ARGS="-i ${interface} -4nd"
for nameserver in ${new_domain_name_servers}; do
ARGS="${ARGS} -a ${nameserver}"
done
/usr/local/sbin/ifctl ${ARGS}
/usr/local/sbin/ifctl -i ${interface} -4sd ${new_domain_name:+"-a ${new_domain_name}"}
return 0
}
```
This calls `ifctl` to update the interface nameserver state on every RENEW. Even though the nameservers haven't changed, this briefly disrupts Unbound's **outgoing DNS over TLS connections** to 1.1.1.1:853 and 9.9.9.9:853.
---
### Step 6 — Connected to Pi-hole FTL behaviour
Pi-hole FTL v6 holds TCP connections open for reuse as a performance feature. During the DoT disruption window caused by `add_new_resolv_conf`, Unbound closes the inbound TCP connection from Pi-hole. FTL doesn't detect the closure until it tries to reuse the connection — at which point it logs the warning.
The Pi-hole dnsmasq log confirms the connection fails and then immediately succeeds on retry with a new connection:
```
11:44:13 dnsmasq[928]: TCP connection failed: Connection prematurely closed by remote server
11:44:13 dnsmasq[928]: config error is REFUSED (EDE: network error)
11:44:13 dnsmasq[929]: forwarded rumt-zh.com to 192.168.9.254
11:44:13 dnsmasq[929]: reply rumt-zh.com is 113.240.76.236
```
DNS resolution continues normally — this is a reliability and logging noise issue rather than a complete outage.
---
## Things Tried That Did Not Fix It
- `edns-tcp-keepalive: yes` on Unbound — Pi-hole FTL does not send the EDNS keepalive option in requests so Unbound never includes it in responses
- `tcp-idle-timeout: 120000` on Unbound — does not address DoT disruption triggered by RENEW
- Outgoing Network Interfaces → All — stopped Unbound from fully restarting on RENEW but `add_new_resolv_conf` still disrupts DoT
- `serve-expired-client-timeout` adjustments — no effect
- `edns-packet-max=1232` on Pi-hole — reduces TCP usage but does not eliminate it
---
## Suggested Fix
Wrap `add_new_resolv_conf` with a condition so it only runs when the IP actually changes, or on first `BOUND`/`REBOOT` — not on every `RENEW` when nothing has changed:
```sh
# Current (runs unconditionally on every RENEW):
add_new_resolv_conf
# Suggested (only runs when something has actually changed):
if [ "$changes" = "yes" ] || [ "$reason" = "BOUND" ] || [ "$reason" = "REBOOT" ]; then
add_new_resolv_conf
fi
```
This prevents `ifctl` from unnecessarily updating the interface nameserver state on RENEW events where the IP, gateway, and nameservers are identical to what was already configured.
---
## Note
I have not applied this fix directly as the file `/usr/local/opnsense/scripts/interfaces/dhclient-script` is owned by an OPNsense package and would be overwritten on upgrades. Ideally this would be addressed in the script itself in a future release.
Happy to provide any additional logs or information if helpful.
## Environment
- **OPNsense version:** 26.1.6_2-amd64
- **FreeBSD:** 14.3-RELEASE-p10
- **OpenSSL:** 3.0.20
- **ISP:** Optus NBN Australia
- **WAN:** DHCP with 900 second lease (renews every 7.5 minutes)
- **Unbound:** DNS over TLS (DoT) to 1.1.1.1:853 and 9.9.9.9:853
- **Downstream:** Two Pi-hole instances forwarding to Unbound at 192.168.9.254:53
- Pi-hole Core v6.4.1
- FTL v6.6
- Web Interface v6.5
---
## The Problem
Both Pi-hole instances intermittently log the following warning:
```
WARNING Connection error (192.168.9.254#53): TCP connection failed while
receiving payload length from upstream (Connection prematurely closed by
remote server)
```
The errors occur with precise regularity — every 7.5 minutes — matching exactly the Optus DHCP lease renewal interval.
---
## Investigation
### Step 1 — Ruled out Unbound restarts
Checked the resolver log for Unbound stop/start events during the error windows:
```
grep "start of service\|service stopped" /var/log/resolver/latest.log
```
Unbound was **not restarting** during the error windows. The TCP connection was being closed without Unbound being killed.
---
### Step 2 — Found the DHCP correlation
Cross-referencing the Pi-hole FTL log against the OPNsense system log revealed a consistent pattern:
**System log:**
```
2026-05-09T15:33:59 dhclient-script: Reason RENEW on igc0 executing
2026-05-09T15:33:59 dhclient-script: Creating resolv.conf
2026-05-09T15:41:29 dhclient-script: Reason RENEW on igc0 executing
2026-05-09T15:41:29 dhclient-script: Creating resolv.conf
2026-05-09T15:48:59 dhclient-script: Reason RENEW on igc0 executing
2026-05-09T15:48:59 dhclient-script: Creating resolv.conf
```
**Pi-hole FTL log:**
```
2026-05-09 15:38:15 WARNING Connection error (192.168.9.254#53): TCP connection failed
2026-05-09 15:41:46 WARNING Connection error (192.168.9.254#53): TCP connection failed
2026-05-09 15:50:07 WARNING Connection error (192.168.9.254#53): TCP connection failed
```
Every single TCP error correlates with a preceding DHCP RENEW. No RENEW = no error.
---
### Step 3 — Confirmed IP is not changing
The DHCP lease file confirms the WAN IP is stable across renewals:
```
option dhcp-lease-time 900;
```
The cached IP file also confirms no change:
```
cat /tmp/igc0_oldip
175.32.32.48
```
The renewal is a simple lease extension — the IP, gateway, and DNS servers do not change.
---
### Step 4 — Traced the dhclient script
Reading `/usr/local/opnsense/scripts/interfaces/dhclient-script`, the `BOUND|RENEW|REBIND|REBOOT` block contains the following:
```sh
changes="no"
if [ -n "$old_ip_address" ]; then
if [ "$old_ip_address" != "$new_ip_address" ]; then
delete_old_address
delete_old_routes
changes="yes"
fi
fi
if [ "$reason" = BOUND ] || \
[ "$reason" = REBOOT ] || \
[ -z "$old_ip_address" ] || \
[ "$old_ip_address" != "$new_ip_address" ]; then
add_new_address
add_new_routes
changes="yes"
fi
add_new_resolv_conf # <-- called unconditionally on every RENEW
if [ "$changes" = "yes" ] ; then
/usr/local/sbin/configctl -d interface newip $interface force
fi
```
`add_new_resolv_conf` is called **unconditionally** on every RENEW, regardless of whether anything has actually changed. When the IP has not changed, `changes` remains `"no"` and `configctl interface newip` is correctly skipped — but `add_new_resolv_conf` still runs every time.
---
### Step 5 — Traced what add_new_resolv_conf does
```sh
add_new_resolv_conf()
{
$LOGGER "Creating resolv.conf"
ARGS="-i ${interface} -4nd"
for nameserver in ${new_domain_name_servers}; do
ARGS="${ARGS} -a ${nameserver}"
done
/usr/local/sbin/ifctl ${ARGS}
/usr/local/sbin/ifctl -i ${interface} -4sd ${new_domain_name:+"-a ${new_domain_name}"}
return 0
}
```
This calls `ifctl` to update the interface nameserver state on every RENEW. Even though the nameservers haven't changed, this briefly disrupts Unbound's **outgoing DNS over TLS connections** to 1.1.1.1:853 and 9.9.9.9:853.
---
### Step 6 — Connected to Pi-hole FTL behaviour
Pi-hole FTL v6 holds TCP connections open for reuse as a performance feature. During the DoT disruption window caused by `add_new_resolv_conf`, Unbound closes the inbound TCP connection from Pi-hole. FTL doesn't detect the closure until it tries to reuse the connection — at which point it logs the warning.
The Pi-hole dnsmasq log confirms the connection fails and then immediately succeeds on retry with a new connection:
```
11:44:13 dnsmasq[928]: TCP connection failed: Connection prematurely closed by remote server
11:44:13 dnsmasq[928]: config error is REFUSED (EDE: network error)
11:44:13 dnsmasq[929]: forwarded rumt-zh.com to 192.168.9.254
11:44:13 dnsmasq[929]: reply rumt-zh.com is 113.240.76.236
```
DNS resolution continues normally — this is a reliability and logging noise issue rather than a complete outage.
---
## Things Tried That Did Not Fix It
- `edns-tcp-keepalive: yes` on Unbound — Pi-hole FTL does not send the EDNS keepalive option in requests so Unbound never includes it in responses
- `tcp-idle-timeout: 120000` on Unbound — does not address DoT disruption triggered by RENEW
- Outgoing Network Interfaces → All — stopped Unbound from fully restarting on RENEW but `add_new_resolv_conf` still disrupts DoT
- `serve-expired-client-timeout` adjustments — no effect
- `edns-packet-max=1232` on Pi-hole — reduces TCP usage but does not eliminate it
---
## Suggested Fix
Wrap `add_new_resolv_conf` with a condition so it only runs when the IP actually changes, or on first `BOUND`/`REBOOT` — not on every `RENEW` when nothing has changed:
```sh
# Current (runs unconditionally on every RENEW):
add_new_resolv_conf
# Suggested (only runs when something has actually changed):
if [ "$changes" = "yes" ] || [ "$reason" = "BOUND" ] || [ "$reason" = "REBOOT" ]; then
add_new_resolv_conf
fi
```
This prevents `ifctl` from unnecessarily updating the interface nameserver state on RENEW events where the IP, gateway, and nameservers are identical to what was already configured.
---
## Note
I have not applied this fix directly as the file `/usr/local/opnsense/scripts/interfaces/dhclient-script` is owned by an OPNsense package and would be overwritten on upgrades. Ideally this would be addressed in the script itself in a future release.
Happy to provide any additional logs or information if helpful.
#5
Virtual private networks / Re: Always On VPN (Wireguard) ...
Last post by foss-johnny - Today at 08:46:31 AMQuote from: keeka on Today at 07:54:14 AMI also use a cloudflare A record for my vpn client conf.
wg client conf specifies a local DNS server (pihole) and search domain (local.lan).
Opnsense's unbound is the upstream server for the pihole.
Wireguard interface wg0 is assigned to a specific interface (VPN) and rules on there permit access to the local pihole instance amongst other things.
When using openvpn, prior to wireguard, I tried various configs to get the smoothest roaming experience. I ended up with port forwarding to localhost (for both WAN and LAN) because I found the openvpn server not reliably listening on all interfaces. When I switched to wireguard, all I did was modify port aliases and of course configure wireguard.
I tried wireguard for first time very recently, after using openvpn for a long time. After setting up the FQ Codel scheduler as per the buffer bloat recipe, I began to see increased openvpn warnings re out of sequence packets. So, thought it a good time to try Wireguard.
I am not sure why you see intermittent connectivity when connected to WG on the LAN. I notice the WG android client log is not very detailed.
Thanks for the further info and insights on your config.
Do you have any issues when roaming from 5g to wifi, or does it seamlessly roam without a problem?
I'm finding when switching from 5g to wifi, I need to turn off/on wifi and wg off/on and then it works correctly again. As if the routing needs to be reset.
Do you ever need to do this?
#6
Virtual private networks / Re: Always On VPN (Wireguard) ...
Last post by keeka - Today at 07:54:14 AMI also use a cloudflare A record for my vpn client conf.
wg client conf specifies a local DNS server (pihole) and search domain (local.lan).
Opnsense's unbound is the upstream server for the pihole.
Wireguard interface wg0 is assigned to a specific interface (VPN) and rules on there permit access to the local pihole instance amongst other things.
When using openvpn, prior to wireguard, I tried various configs to get the smoothest roaming experience. I ended up with port forwarding to localhost (for both WAN and LAN) because I found the openvpn server not reliably listening on all interfaces. When I switched to wireguard, all I did was modify port aliases and of course configure wireguard.
I tried wireguard for first time very recently, after using openvpn for a long time. After setting up the FQ Codel scheduler as per the buffer bloat recipe, I began to see increased openvpn warnings re out of sequence packets. So, thought it a good time to try Wireguard.
I am not sure why you see intermittent connectivity when connected to WG on the LAN. I notice the WG android client log is not very detailed.
wg client conf specifies a local DNS server (pihole) and search domain (local.lan).
Opnsense's unbound is the upstream server for the pihole.
Wireguard interface wg0 is assigned to a specific interface (VPN) and rules on there permit access to the local pihole instance amongst other things.
When using openvpn, prior to wireguard, I tried various configs to get the smoothest roaming experience. I ended up with port forwarding to localhost (for both WAN and LAN) because I found the openvpn server not reliably listening on all interfaces. When I switched to wireguard, all I did was modify port aliases and of course configure wireguard.
I tried wireguard for first time very recently, after using openvpn for a long time. After setting up the FQ Codel scheduler as per the buffer bloat recipe, I began to see increased openvpn warnings re out of sequence packets. So, thought it a good time to try Wireguard.
I am not sure why you see intermittent connectivity when connected to WG on the LAN. I notice the WG android client log is not very detailed.
#7
Virtual private networks / Re: Always On VPN (Wireguard) ...
Last post by foss-johnny - Today at 06:47:11 AM...
#8
Virtual private networks / Re: Always On VPN (Wireguard) ...
Last post by foss-johnny - Today at 06:46:41 AMWhen I am on the internal wi-fi, I connect to wireguard, and can see the tunnel is connected in the WG status page. The IP address of the client is from the internal wifi subnet.
However, when I ping the wireguard gateway IP address, I get patchy responses, one reply, followed by timeouts.
Sometimes I ping, and I don't even get one reply back.
For minute I thought I had a asymmetric route, but after taking a packet capture on all interfaces, I can see that when the ping traffic fails, there is not tcmpdump entry.
It's as if the traffic from the mobile client is not being routed down the wireguard tunnel at all.
My wireguard config states to route 0.0.0.0/0 (all) traffic via the wireguard tunnel connected, so I'm not sure why it's not doing that.
Any ideas?
However, when I ping the wireguard gateway IP address, I get patchy responses, one reply, followed by timeouts.
Sometimes I ping, and I don't even get one reply back.
For minute I thought I had a asymmetric route, but after taking a packet capture on all interfaces, I can see that when the ping traffic fails, there is not tcmpdump entry.
It's as if the traffic from the mobile client is not being routed down the wireguard tunnel at all.
My wireguard config states to route 0.0.0.0/0 (all) traffic via the wireguard tunnel connected, so I'm not sure why it's not doing that.
Any ideas?
#9
Virtual private networks / Re: Always On VPN (Wireguard) ...
Last post by foss-johnny - Today at 04:56:35 AMQuote from: keeka on May 08, 2026, 07:39:55 AMNot sure where your issue lies but the way I have done this (for both openvpn and wireguard) is one destination NAT rule on the WAN, and another on the relevant lan interface. Both forwarding wireguard port to 127.0.0.1. I found that to be the most reliable way to get mobile/wifi roaming whilst only using WAN IP in any vpn client config. The WAN version of the port forward and fw rule filters src by my mobile provider's ASN.
Thanks for sharing and explaining your setup Keeka.
One question - How is your DNS configured within wireguard on the client and in Unbound DNS and external DNS server (e.g. cloudflare)?
I'm use a DNS A record in Cloudflare that points to my WAN IP. Internally, when on the Wireless LAN, the mobile client resolves the Wireguard DNS name (e.g. vpn.domain.com) to my WAN IP address, I have a rule to allow the traffic from the wireless network to the WAN interface.
I don't have any destination NAT rules configured for Wireguard, because Wireguard is listenting on the WAN IP on UDP 51821 already.
Can you please help me understand how you have your DNS configured?
Will give your configuration a try.
p.s. Really like how you've filtered on ASN for the WAN rule
#10
26.1, 26,4 Series / Re: 26.1.7_3 - Firewall Logs a...
Last post by lmoore - Today at 04:47:29 AMA fresh install of 26.1.2 sets the mode to Disable outbound NAT rule generation (outbound NAT is disabled).
With 26.1 we now use Source NAT and Destination NAT.
I would suggest you create your outbound NAT rules using Source NAT and enable the Log option there.
When creating rules, you can enable the Log option too.
The default installation includes two rules on the LAN interface which have the Log option disabled by default. To enable logging of these rules go to Firewall -> Rules [new];
With 26.1 we now use Source NAT and Destination NAT.
I would suggest you create your outbound NAT rules using Source NAT and enable the Log option there.
When creating rules, you can enable the Log option too.
The default installation includes two rules on the LAN interface which have the Log option disabled by default. To enable logging of these rules go to Firewall -> Rules [new];
- Enable Inspect
- Enter LAN network in the search field
- Click on link under Commands for Default allow LAN to any rule and enable logging, then save
- Click on link under Commands for Default allow LAN IPv6 to any rule and enable logging then, save
