Messages

Actually, allocation only happens on DISCOVER with ISC:
https://kb.isc.org/docs/isc-dhcp-44-manual-pages-dhcpdconf#dynamic-address-allocation

The fact that IP conflict prevention happens (ICMP echo attempted) indicates that clients are in INIT state, sending a DISCOVER (versus requesting an extension of their current lease via REQUEST). That the next chapter.

Yes, you are right. Forgive my inaccurate choice of words, my point is that the first step comes from the endpoint device, but not the DHCP server.

You cannot view this attachment.

Nortant, what leads you to think on Apple device might not discover and request?

Nono, I don't mean that the Apple device might not discover and request, I mean, the new feature on the Apple device (presumably after ios 18?), private WLAN address could be rotating, I guess if the endpoint device changes its WLAN address (for instance, the signal is weak, the device disconnects and reconnects again and again), it might request a new IP address.

Compared with the DHCP server and the endpoint device, I believe the issue is the endpoint, not the server.

Yeah, I admit that my belief depends on the descriptions he provided.

Maybe DNS is his problem, since records are automatically added for all interfaces. Set Services: Unbound DNS: General -> "Do not register system A/AAAA records" and create a specific DNS override for the DNS name of the OpnSense box yourself.

Yeah, if I didn't do this, it would always get stuck every several seconds when using a domain URL instead of an IP address.

I also fixed the https security issue :-)

You cannot view this attachment.

I'm afraid the OP is complicating things for no reason.
He should probably pick one interface/IP as the "preferred" way to access OPN and adjust his FW rules to allow that (the simplest is to allow HTTPS to "this firewall" - or the preferred interface address - on all 3 interfaces).

Making a DNS entry pointing to that preferred IP is the next step.
Don't use .local for the OPN domain though. There's an explicit warning about that (it messes up mDNS).
I personally wouldn't use an override on a .com domain. At some point, .home might be more appropriate.

yes, you are right, I changed it to another one, .com domain may cause the conflict.

I believe the issue is with your Apple device.

The first step of the DHCP is for the client device to broadcast a DHCP Discover message to identify available DHCP servers on the network. Which means, the DHCP server won't assign any IP to any device unless it receives a request.

have you tried to use nslookup from your LAN device and your OPNsense?

on your LAN device, the server should be your OPNsense IP address.
You cannot view this attachment.

on your OPNsense, the server should be what you configured.
You cannot view this attachment.

检查OPNsense的路由表，是否能够正常转发ping包到自己的子网。
你的子网设备是直接连接到OPNsense的吗？是否还有一层交换机或者路由，检查这一层设备的路由表，检查OSPF或者静态路由。

我之前遇到的问题是，IPSec是通的，ping内网网段的网关（OPNsense的interface地址）也是通的，但是OPNsense没有学到内网的网段，所以即便从tunnel收到数据包也不知道往哪转发。

我知道的可能会造成DNS影响的设置有：

1. OPNsense的DNS设置
2. Unbound DNS的状态是否开启
3. Services: Unbound DNS: General -> Do not register system A/AAAA records 状态
4. Services: Unbound DNS: General -> Network Interfaces 配置
5. 终端设备DNS配置

需要逐步排查问题，你说的"从外面接入"的意思，应该是说从外网通过VPN接入内网，你说的延迟会变，source和host分别是什么，因为这里涉及不止一层的网络关系。

1. VPN会有一个tunnel的私有网络。
2. OPNsense和这个VPN连接的interface有一个私有网络。
3. OPNsense至少有个wan网络？
4. OPNsense是否还有其他lan网络？

如果可以，先尝试从VPN设备开始ping，到internet，到wan，到lan，到远端VPN设备，观察延迟。

内部VPN是否有开exit node，内部VPN是否有广播内部网络。

如果这些问题都排查完毕，OPNsense的规则也需要根据你的实际拓扑和连接情况来设置。

我提供我的情况供参考。

这是我的拓扑结构：
You cannot view this attachment.

我的VPN在OPNsense内连接了虚拟的interface并有自己的内网网段。
我的要求是，通过VPN连接到我内网的设备，可以访问WAN,VE,VM，但不可以访问LAN。
那么我需要做的设置如下：
1. VPN需要设置为exit node。
2. VPN需要广播VE，VM网段。
3. OPNsense的规则，有两种方式可以配置：
（1）VPN的interface入站规则source：any，destination：any。入站规则需要显式配置。同时，LAN出站规则对VPN进行阻止，看情况对VE和VM的出站规则配置，因为OPNsense的出站规则默认是允许。
（2）VPN的interface入站规则的destination，需要先配置一个alias，确定需要包含的网络，然后再在配置规则的时候反选，我用的就是这种方法。

这里需要注意的是，VPN的tunnel出来的流量，是否会被VPN进行一次NAT，这个在设置OPNsense规则的时候要清楚，否则虽然是针对VPN的interface进行设置，但源头如果只选VPN network的话，可能会不起作用，因为有可能VPN没有通过NAT转换地址，source地址仍然是VPN内部的私有地址，那么防火墙规则就不会被套用，又因为是显式配置，没有匹配到条目的话就会被drop。

Hi czmirek,

Here is my solution.
You cannot view this attachment.

you can see when I ping this domain, the IP address is my WAN IP address.

Also, you should check the Listen Interfaces.
You cannot view this attachment.