pfSense gateway error

I see the following sendto error in the gateway logs occurring daily at the same time on the WAN interface. I’m thinking it’s trying to obtain a new lease from Craptastic’s dhcp server but not succeeding. My WAN IP address never changes unless I manually release and renew. Is there a configuration I am missing? It’s not causing any issue other than noise in the logs.

Jun 13 00:33:04 dpinger WAN_DHCP 73.114.232.1: sendto error: 65

netgate docs for error 65 indicate:

Either there is no possible route to the target locally, or status information was received from an upstream router that indicated the same condition elsewhere along the path to the target.

This can happen due to a lack of default route, missing interface link route, or similar conditions.

https://docs.netgate.com/pfsense/en/latest/routing/gateway-monitoring-errors.html

Not sure what to do with the above

Does it cause a drop in your network?

No, just noise in logs, but my IP NEVER changes and I tried manual release/renew and it keeps the same address. I’m running bridge mode with comcast router. Seems like I should get a new IP; it’s been the same for a couple of years.

the comcast router has a different gateway subnet and IP address than my pfsense

@LTS_Tom

Found this: https://forum.netgate.com/topic/98656/gateway-send-to-error-65

But I am not having disconnect issue. Just daily spamming of gateway logs with dozens of sendto error 65 messages. Jimp says error 65 means there’s no route to host; so why would there be no route to host? My setup is WAN -> comcast-modem (in bridge mode) -> pfsense -> LAN and I can ping gateway address.

Also, should my ip address rotate or just be reassigned? Looking at dhcp logs, I see it being renewed. If it’s being renewed, why sendto error? How can I force a renewal (interfaces > release and renew does not obtain a new IP). Is this a bridge mode issue?

I re-configured WAN on a different interface got a new IP and a DHCP gateway server assigned. Will see what happens with logs.

Interestingly, the new IP address and gateway are on different subnets. The previous interface had been assigned an IP in the same subnet as the gateway server.

sorry, it’s in the same subnet; it’s masked /22