Https packets on WAN bypassing VPN

wtw

I am packet capturing on WAN, excluding all port 1194 (VPN) traffic, yet I see some port 443 traffic (not a lot). I checked the IPs and they are mostly owned by either Microsoft or a cloud infrastructure company (Cloudflare, Akamai Technologies, Zayo Colocation). Also saw one for Facebook Ireland Ltd. I do not know how a LAN device could bypass the VPN tunnel. There are no bypass rules or anything Microsoft on the router device (a PC, Intel x64 running Ubuntu 20.04LTS with KVM running pfSense 2.4.5). There is a Skype instance running on a LAN device. The router is running DNS Resolver (unbound) for DNS over TLS to Quad9 with DNSSEC. There is also pfBlockerNG doing DNS filtering for ad/malware URL blocking. I have a LAN rule to reject any port 53 packets not addressed to the gateway/DHCP DNS advertised server (one and the same). There are Floating rules to reject all port 853 packets on the WAN. All incoming port 53 packets on LAN and WAN are tagged and then all tagged packets are rejected on outbound WAN, since they should all be DoT and should also be going out the VPN tunnel. I cannot just block all DNS on the WAN, or the VPN will not autostart on bootup. It will not be able to get the VPN provider IP. It uses the provider's URL.
To combat this leak issue, a rule was added to block all outgoing packets for ports 80 and 443. The system still boots up with VPN running, and I no longer see these packets on the WAN. This is not what I would call a real solution.

Are there methods that applications on Windows PCs could be using to bypass the router based VPN, with no special router configuration for the devices?
How would I try to determine where these wayward packets are comming from?
The captures seem to indicate that local requests are initiating this traffic (request followed by reply).

Gertjan

@wtw said in Https packets on WAN bypassing VPN:

It uses the provider's URL.

Not a part of the final solution, but why supplying an URL ?
Give it an IP, and the VPN-client doesn't need DNS over WAN any more : it would connect, saving even a lookup :)

When pfSense establishes the WAN at boot, just before the VPN comes up, is it possible that some LAN devices detected the lost link, and hammer facebook and the like, so you're seeing states to these sites that go over WAN, as that is initially available ?
Reboot pfSense, and keep the LAN shut of - remove the main LAN cable.
As soon as you you know that the VPN comes up, connect LAN. Do some devices still go out over WAN instead of VPN ?

wtw

I use the URL because the VPN service has several entry points for a given URL access name, probably for load balancing. So I allow it (and desire it) to float around IP addresses. I am not worried about an initial contact to the VPN and DNS to do that at the start, which the ISP can see. The ISP knows a VPN is in use based on the traffic.

Didn't consider the short down time access requests. I have been testing router config changes and reboot it or restart pfSense occationally to make sure it comes up as desired. During that time, LAN devices are connected and running with browsers open with many tabs and other Apps as well. That would explain what looked like a leak. I will try the test to verify.

If this is what is occurring (which it probably is), then my rule is a appropriate to at least block http(s) traffic during that time. I will create a logging monitor rule at the end for all non-WAN-net-non-VPN traffic as an additional test.
Thanks for the hint. I sometimes lose track of all the asynchronousness.

wtw

Yes, you were right about the state issue. Being kind of new to this, I did not understand what was happening in the state table. If I physically do not allow LAN traffic prior to bootup and VPN starting, I see no issue.
The real solution is to reset the state table: Diagnostics > States> Reset States > Reset "when the dust settles", which will remove all these types of issues. This does not normally happen on start up, so the filtering rule hack accomplishes the task by not allowing these very few traffic types from creating states that allow them to continue.

Thanks for the hint and the small lesson on firewall operation.
I consider this issue resolved. It was my error due to ignorance.