Messages

[version]

Hello everybody!

I have an OPNsense server on a remote network and I'm trying to configure the Captive Portal.

My Opnsense version: OPNsense 25.7.6 (amd64)

The setup is as follows:

• Interface wg0 is configured for WireGuard.
• I have a WireGuard client configuration on my local machine that connects successfully.
• When I access http://192.168.45.1:8000 after connecting, I expect to see the Captive Portal login page, but instead I get an "Empty reply from server."

Details

The interface wg0 is up and active, with IP 10.20.0.1/24.


The firewall allows access to the portal:

root@opnsense:~ # pfctl -sr | grep 8000
pass in log quick on wg0 proto tcp from any to (self) port = 8000 flags S/SA keep state label "x"

WireGuard client it's correct, I think, (local and endpoint IPs)

The OPNsense GUI shows the Captive Portal zone enabled on the WireGuard interface.
However:
When I open the portal URL --> http://192.168.45.1:8000
 I get "Empty reply from server."
No logs are produced when restarting the Captive Portal.
The directory --> /var/etc/captiveportal   does not exist although I don't know if it should exist
Would appreciate guidance on how to make the Captive Portal actually start and serve content when accessed through the WireGuard interface.

Oh you are right, sorry, the post and the examples are a bit confusing.

I've simplified everything now.

With this IP --> 178.215.228.24, which is from 0.es.pool.ntp.org, these are the results:


--> ntpq -pn

 remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 178.215.228.24  .INIT.          16 u    -   64    0    0.000   +0.000   0.000

--> ping 0.es.pool.ntp.org
PING 0.es.pool.ntp.org (178.215.228.24): 56 data bytes
64 bytes from 178.215.228.24: icmp_seq=0 ttl=53 time=33.199 ms
64 bytes from 178.215.228.24: icmp_seq=1 ttl=53 time=33.755 ms

Hi everyone,

I'm running into an issue where my OPNsense firewall isn't synchronizing time via NTP, and I can't figure out why.

1. My setup:
- OPNsense version:  25.1.11
- Outbound firewall rules allow UDP/123.
- WAN and LAN traffic is visible for NTP in packet captures.
- DNS works fine and NTP server IPs resolve correctly.

From the shell, I can ping NTP servers:

PING 92.113.12.77 (92.113.12.77): 56 data bytes
64 bytes from 92.113.12.77: icmp_seq=0 ttl=56 time=17.904 ms
64 bytes from 92.113.12.77: icmp_seq=1 ttl=56 time=18.382 ms
--- 92.113.12.77 ping statistics ---
2 packets transmitted, 2 packets received, 0.0% packet loss

2. DNS resolution works:

host 0.opnsense.pool.ntp.org

0.opnsense.pool.ntp.org has address 195.95.153.59
0.opnsense.pool.ntp.org has address 212.227.232.46
0.opnsense.pool.ntp.org has address 162.159.200.123
0.opnsense.pool.ntp.org has address 185.134.42.7


3. But ntpdate fails with:

ntpdate -u 92.113.12.77
no server suitable for synchronization found

4. ntpq -pn shows all servers stuck in .INIT. state:

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 92.113.12.77    .INIT.          16 u    -  256    0    0.000   +0.000   0.000
 130.206.3.166   .INIT.          16 u    -  256    0    0.000   +0.000   0.000

5. Packet captures on igb0 (LAN) and WAN interfaces show NTP requests and responses coming back from the server, e.g.:

192.168.10.2.58914 > 178.255.228.77.123: NTPv4, Client, length 48
178.255.228.77.123 > 192.168.10.2.58914: NTPv4, Server, length 48

Even though packets are flowing in both directions, OPNsense never syncs time. All NTP servers remain in unreachable (reach = 0) state.

I've already:

- Restarted the NTP daemon (service ntpd restart)
- Tried ntpdate -b, -u, -t, etc.
- Different NTP servers (using their IP addresses directly in case it was a DNS issue)
- Contacted my ISP to ask whether they might be blocking NTP traffic, but I'm still waiting for a response

What else could I check or try? Any help would be greatly appreciated!

I'm still fairly new to all of this, so it's entirely possible I've missed something or misconfigured a step along the way while trying to troubleshoot.