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

Exclude multicast and broadcast on WinDivert's filter #146

Merged
merged 5 commits into from
Nov 6, 2024

Conversation

Osherz5
Copy link
Contributor

@Osherz5 Osherz5 commented Jun 17, 2024

This change is proposed in order to deal with DHCP issues, where the entire machine loses connectivity after a while with mitmproxy running (see mitmproxy/mitmproxy#6902)

Copy link
Member

@mhils mhils left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, greatly appreciated! Have you looked at how this works / interacts with IPv6?
Can we do something like this (untested)?

(tcp || udp) && !loopback && !(224.0.0.0 <= remoteAddr && remoteAddr <= 255.255.255.255) && (remoteAddr < ff00::)

@Osherz5
Copy link
Contributor Author

Osherz5 commented Jul 16, 2024

I noticed the filter doesn't work with "!(...)" type of exclusions for some reason, I used the following equivalent instead:

!loopback && (remoteAddr < 224.0.0.0 && remoteAddr < ff00::) && (tcp || udp)

I didn't get to test it with IPv6 yet due to time constraints, but might try to look into it soon

It's a bit hard to debug since we're lacking the redirector's output (mitmproxy/mitmproxy#6970)

In addition I've encountered two other connectivity issues where SMB does not work (I tried excluding TCP port 445 and it worked partially), and also encountered some DNS issues (when redirector was running on Windows Server which acted as a DNS server). I'm not sure if it's relevant to this PR , but worth looking into...

@mhils
Copy link
Member

mhils commented Jul 16, 2024

Thanks! 🍰

(remoteAddr < 224.0.0.0 && remoteAddr < ff00::)

I think this will fail for IPv6 because remoteAddr < 224.0.0.0 is not satisfied.

FWIW you can get the redirector output if you compile in debug mode (maturin develop). In that case a console window should open. But I agree it's something we need to improve.

@niconorsk
Copy link
Contributor

Hi, I've been looking at this merge request and I believe the following should work to address the latest comment re IPv6:

!loopback && ((ip && remoteAddr < 224.0.0.0) || (ip6 && remoteAddr < ff00::)) && (tcp || udp)

I have tested this enough to know that mitmproxy in local redirect mode accepts that filter and works for ignoring DHCP traffic. It also does not blanket ignore all IPv6 traffic. I have not been able to test DHCPv6 because the only IPv6 I have available to me relies on SLAAC which just uses ICMP and isn't diverted

@Osherz5
Copy link
Contributor Author

Osherz5 commented Nov 6, 2024

Hey thanks for looking into it! I updated the filter with the ipv6 multicast exclusion, and also reverted the change on the socket operation filters back to "tpc || udp" which was enough to begin with.

Copy link
Member

@mhils mhils left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks great now, thank you both! 🍰 😃

@mhils mhils merged commit 05d1b28 into mitmproxy:main Nov 6, 2024
18 checks passed
@Osherz5
Copy link
Contributor Author

Osherz5 commented Nov 7, 2024

Hey, I thought it would be caught in the tests but just realized the syntax should be 'ipv6 && ...' and not 'ip6 && ...' , should I open a new PR for fixing it?

@Osherz5
Copy link
Contributor Author

Osherz5 commented Nov 7, 2024

Here it is, sorry for the mess
#193

@mhils
Copy link
Member

mhils commented Nov 7, 2024

No worries at all, thanks for double-checking! Our mitmproxy_rs CI isn't great. In the best case this would have shown up in mitmproxy's CI, at which point fixing would have already been annoying. So glad you caught it early. :)

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

Successfully merging this pull request may close these issues.

3 participants