Do any modern firewalls support cookie blocking/http log/plugins ?

Maybe someone can help an "old-school" firewall user migrate to something more modern?

I started with atguard which was light and fantastic.

After norton bought and ruined it, moved to Outpost 4.0

Stuck on that because they removed everything from the newer versions, like plugins, cookie filtering, http log, etc. Unfortunately it doesn't work beyond windows xp which is gettting beyond end-of-life now.

I don't see any modern firewalls with such features, it's like we are going backwards with software development.

I use many browsers and I do not want to setup individual rules or use plugins inside each one, I want it done at the firewall level.

Cookies will be delivered as they are part of the URL, requested by your browser, therefore are legit returning packets.
Firewalls do not stop malware or cookies, firewall block unrequested data packets-traffic.
Block 3rd party cookies all the time in all browsers that you use.

Cookies are most certainly not part of a url, they are part of the inbound or outbound traffic, and as long as it's not https, Outpost 4.0 and it's ancestor atguard was able to filter http traffic just fine.

From the client (browser) POV, cookies can be received via HTTP response header and sent via HTTP request header. It is generally easy for an intermediary component (could be a "firewall") to effectively proxy the HTTP connections and strip out cookies. Cookies can also be received via HTTPS response header and sent via HTTPS request header. It is less easy for an intermediary component to effectively proxy these connections, because they must use a (certificate based) MITM technique to carry out a decrypt, inspect/modify, encrypt. Cookies can also be created/deleted/modified via manipulation of the document.cookie object (via Javascript for example). Unlike "header cookies" which are trivially easy to spot, these aren't always easy for an intermediary to spot (eval). It would have to be javascript/DOM aware and evaluate things in the same manner that the client software would. Despite not being able to reliably tell what the client software actually is (User-Agent may or may not be accurate). It isn't unusual for a user to want to selectively block cookies based on whether they are "first party" or "third party". The intermediary can try to judge this based on Referrer header but that isn't guaranteed to be present (blocking Referrer where it isn't necessary is SOP for privacy-conscious entities).

Cookies are but one example of a larger unique identifier threat which could involve things like Flash LSOs, browser storage and caching mechanisms, etc. So there are even more client and server specific hurdles an intermediary filtering device would have to contend with when trying to block "cookies" in the broadest possible sense.

For such reasons and possibly others I've missed, blocking cookies via intermediary component (software firewall, hardware firewall, whatever) is problematic (as Fabian Wosar previously pointed out). Then again, so too is blocking such things only in your main browser or specific browsers, because any software can use its own (possibly separate, rather than OS common) component for handling web requests/responses, javascript, etc. Software which could also ignore system installed MITM certificates, use alternate ports not proxied, etc. If you add to that the possibility for secondary devices within your environment to be making web connections (smart TV, smartphone via WiFi, etc) and perhaps also the possibility of using your notebook or SmartPhone when connected to networks other than your own, you end up with quite a mess when it comes to setting up filters/blocks.

It may make sense to use an HTTP+HTTPS filtering gateway device on your network and/or HTTP+HTTPS filtering proxy on each of your devices. I don't have specific recommendations there, except that you include HTTPS. However, I would point out that even if you do that it will likely be beneficial to control things in individual browsers. Thus, if you standardize on one for most activities and pick one that supports easily deployed configuration files (which you create once and roll out to your different devices), that would be a good first step in the right direction.