Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

IPBan memory usage on windows server 2025 #316

Open
fhm20 opened this issue Nov 18, 2024 · 16 comments
Open

IPBan memory usage on windows server 2025 #316

fhm20 opened this issue Nov 18, 2024 · 16 comments

Comments

@fhm20
Copy link

fhm20 commented Nov 18, 2024

I'm testing IPBan on Windows Server 2025.

Server1: W2025 without IPBan. The process svchost.exe -k LocalServiceNoNetworkFirewall -p uses 6MB of RAM.
Server2: W2025 with IPBan 1.8.1 or 2.0.1. The process svchost.exe -k LocalServiceNoNetworkFirewall -p uses 2.1GB of RAM. Uptime: 15 days.
Server3: W2022 with IPBan 1.8.1. The process svchost.exe -k LocalServiceNoNetworkFirewall -p uses 22MB of RAM. Uptime: 30 days.
The RAM usage of svchost.exe -k LocalServiceNoNetworkFirewall on W2025 increases every day and does not release memory. In two days, it increased by 400MB.
I have the same 3 rules, "IPBan_GlobalBlacklist," each with 1000 IPs (3000 IPs in total), on all 3 servers.

This issue does not occur on W2022. Could you check if there is a memory problem with IPBan or if it is an issue with the firewall of Windows Server 2025?

Thanks

@jjxtra
Copy link
Collaborator

jjxtra commented Nov 19, 2024

Please zip and send logfile*.txt to [email protected]

@jjxtra
Copy link
Collaborator

jjxtra commented Nov 20, 2024

Out of curiosity, does IPBanProDatacenter have the same issue? There's a free trial you can install to test: https://ipban.com/products/ipban-pro-datacenter-free-trial-download/

This one doesn't use Windows firewall

@fhm20
Copy link
Author

fhm20 commented Nov 25, 2024

I installed version ipban 3.0 (.net9) and the final version of Windows Server 2025 (previously, I had Windows Server Preview), and the error persists. In two days, the svchost process increased to 500MB of RAM on two different machines. I’m going to try IPBanProDatacenter now.

@fhm20
Copy link
Author

fhm20 commented Nov 27, 2024

With the datacenter version, memory consumption is correct.

DigitalRuby.IPBanProDatacenter.exe 42.6 MB RAM
DigitalRuby.IPBanProWFPEvents.exe 2.4 MB RAM
svchost.exe -k LocalServiceNoNetworkFirewall 10.3 MB RAM

IPBan 3.0
DigitalRuby.IPBan 34 MB RAM
svchost.exe -k LocalServiceNoNetworkFirewall 850 MB RAM

@jjxtra
Copy link
Collaborator

jjxtra commented Nov 27, 2024

99% sure this is a problem with Windows firewall then. Will have to investigate what changed with COM or their implementation in server 2025. Could be a MSFT bug ...

@Maddymask
Copy link

99% sure this is a problem with Windows firewall then. Will have to investigate what changed with COM or their implementation in server 2025. Could be a MSFT bug ...

I'm just about to install your product on Windows Server 2025 on production. Is it not recommended to do this yet?

@jjxtra
Copy link
Collaborator

jjxtra commented Nov 27, 2024

I forgot to ask, does restarting ipban clear the memory usage of the firewall service @fhm20 ?

@fhm20
Copy link
Author

fhm20 commented Nov 27, 2024

No. If I restart the service, the memory is not released. I opened a case with Microsoft. I'm waiting for their response.

@jjxtra
Copy link
Collaborator

jjxtra commented Nov 27, 2024

99% sure this is a problem with Windows firewall then. Will have to investigate what changed with COM or their implementation in server 2025. Could be a MSFT bug ...

I'm just about to install your product on Windows Server 2025 on production. Is it not recommended to do this yet?

Unfortunately not recommended until memory leaks can be fixed in Windows

@jjxtra
Copy link
Collaborator

jjxtra commented Nov 28, 2024

This Win32 api call has had a memory leak for years, too: FwpmNetEventEnum

To work around it and surface firewall events properly in IPBan Pro, I had to write a separate executable, read it's std out from the main service, then kill the child process periodically as it filled up with RAM. You'd think calling FwpmFreeMemory would actually free the memory, but alas.

All this is to say this wouldn't be the first time a memory leak crept it's way into Microsoft's firewall code.

@jjxtra
Copy link
Collaborator

jjxtra commented Nov 30, 2024

@fhm20 Does restarting the LocalServiceNoNetworkFirewall service clear the memory usage?

@fhm20
Copy link
Author

fhm20 commented Dec 3, 2024

I can't restart the process cleany. I have to kill the process, which causes the server to lose connectivity for a few seconds. After that, the memory is released. Microsoft technical support is still investigating the issue.

@jjxtra
Copy link
Collaborator

jjxtra commented Dec 3, 2024

What if the ipban service restarted this process daily at 3am for win2025 only, would that be acceptable? Or just wait for Microsoft response?

@fhm20
Copy link
Author

fhm20 commented Dec 4, 2024

It's not enough to restart the IPBan service to clean the memory. I would need to kill the svchost process, but I can't do that at night either. Would it be possible for you to adapt the DigitalRuby.IPBanProWFPEvents.exe to the free version?
If not, I’ll have to stop using IPBan on Windows 2025 until Microsoft fixes the issue.

@jjxtra
Copy link
Collaborator

jjxtra commented Dec 4, 2024

I mean restarting the LocalServiceNoNetworkFirewall. That should free up the memory while causing just a few seconds blip, if I understand your prior comments right.

DigitalRuby.IPBanProWFPEvents.exe simply listens for block/allow events and writes them to std out, it doesn't do anything with firewall rules.

@fhm20

@fhm20
Copy link
Author

fhm20 commented Dec 17, 2024

I am still analyzing the case with Microsoft. They are asking for memory dumps of the LocalServiceNoNetworkFirewall process to try to locate the issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants