Workaround to avoid Web protection slowdowns in tcp loopback connections

[TolosBand]

I know it's not common but I use some applications written in .net that act as client/server on the same machine using socket connections.

Disabling web protection the communication works very faster otherwise I have lags of 2-3 seconds in the beginning of the connection.

Adding them in the exclusions as app that connect to internet does nothing.

The only workaround I've found is to use an external machine i.e. a raspberry that acts as a "bridge" doing port forwarding.

Excample:

machine with client/server app -> ip 192.168.1.1

server listens to 192.168.1.1:821 <--> client calls 192.168.1.1:821 from another process in the SAME machine --> I get lags

workaround:

raspberry on 192.168.1.2 with iptables configured in this way:

iptables -t nat -A PREROUTING -p tcp --dport 821 -j DNAT --to-destination 192.168.1.1:821
iptables -t nat -A POSTROUTING -p tcp -d 192.168.1.1 --dport 821 -j SNAT --to-source 192.168.1.2

the client on 192.168.1.1 is configured to connect to 192.168.1.2 but actually it is redirected to its ip using my iptables rule. --> in this way no lags even with web protection active.

Mbam version is 3.7.1.2839 on windows 10

 

 

[exile360]

Greetings,

Thanks for the info.  The long delay is likely related to the way that the Web Protection component plugs in directly to the network stack via WFP, the same APIs used by the built in Windows Firewall in modern Windows versions (including 10) and it's probably having trouble with IP/domain lookups when using a local loopback address.  I'm not sure if there's anything you could do about it to improve the situation on the local system, however I will present this information to the Product team to make them aware of it as they may have a workaround or the Developers may be able to further improve/optimize the performance of Web Protection in scenarios like the one you describe.

[TolosBand]

Thanks: I think that since my scenario is unusual the lack of this optimization is venial but when you face with it ... well.. understanding the cause could bring some headaches 😅. I think the Product team will not have difficulties to solve it now that they know this issue exists! 🙂

Let me know if there's a way to know when an update will do that: usually I read the changelog of every update.

[TolosBand]

On 2/19/2019 at 11:28 PM, exile360 said:

Greetings,

Thanks for the info.  The long delay is likely related to the way that the Web Protection component plugs in directly to the network stack via WFP, the same APIs used by the built in Windows Firewall in modern Windows versions (including 10) and it's probably having trouble with IP/domain lookups when using a local loopback address.  I'm not sure if there's anything you could do about it to improve the situation on the local system, however I will present this information to the Product team to make them aware of it as they may have a workaround or the Developers may be able to further improve/optimize the performance of Web Protection in scenarios like the one you describe.

Issue resolved with last updates: tested on Jul 29 2019. Thanks to all.

[exile360]

That's great news, thanks for letting us know

I knew they made a lot of changes and bugfixes for Web Protection in this most recent release, but I wasn't certain if any of those changes/fixes would impact this particular issue or not, so thanks for the confirmation.  I will be sure to let them know.