Posted: Sun Aug 12, 2018 2:02 Post subject: BUG with "catch all P2P protocols" and iOS clients
When I checked "catch all P2P protocols" and set everything up correctly to enable that blocking, I noticed my iPhone went from quickly connecting to taking over 30 seconds to fully connect.
After some investigation, I found that deleting one rule from advgrp_1 fixed it:
iptables -D advgrp_1 -m ndpi --apple -j DROP
After looking at the NDPI documentation, '--apple' appears to be a catch all for various Apple iOS/Mac protocols. What DD-WRT clearly meant to block was --applejuice, which is apparently a lesser known P2P protocol. The confusion probably comes from the fact that the ipp2p rule for applejuice is --apple.
Looking at the source on DD-WRT's svn, the offending code is in src/router/services/networking/firewall.c at line 1487. It appears it has been this way for years as it was there when I checked even some pretty old revisions. Hopefully someone with commit privs will see this and make the fix (or at least file it as a bug in DD-WRT's bug tracker so it is fixed someday)
I think I can confirm this issue. I don't use any iOS devices, but I tried going to Apple.com today and signing in, and I noticed the sign in page wouldn't load at all. The only thing in my router that could have been the issue was "Catch all P2P protocols," and sure enough, turning it off allowed me to access the sign-in page.
The domain for the sign in page is: secure1.store.apple.com
Can you confirm that you were having this blocked as well? The normal apple.com website works fine, just that one domain seems to be broken. Are they trying to use a non-standard protocol for that page that's being picked up? It's bizarre that it would even be included in this, I thought it would just use HTTPS.
Is there a quick-fix I can do on my router to still be able to use "Catch all P2P protocols," without having to recompile anything?
I think I can confirm this issue. I don't use any iOS devices, but I tried going to Apple.com today and signing in, and I noticed the sign in page wouldn't load at all. The only thing in my router that could have been the issue was "Catch all P2P protocols," and sure enough, turning it off allowed me to access the sign-in page.
The domain for the sign in page is: secure1.store.apple.com
Can you confirm that you were having this blocked as well? The normal apple.com website works fine, just that one domain seems to be broken. Are they trying to use a non-standard protocol for that page that's being picked up? It's bizarre that it would even be included in this, I thought it would just use HTTPS.
Is there a quick-fix I can do on my router to still be able to use "Catch all P2P protocols," without having to recompile anything?
Yes, the fix is to add the iptables rule I listed above to your firewall script. That will remove the problematic filter while still allowing you all the real P2P protection.
I'm not surprised you had that problem trying to go to apple.com, there is a LOT of stuff getting blocked by that NDPI "--apple" filter.
I'm not even sure why NDPI has such an overly broad filter. I could see wanting to block people from doing iOS app updates and so forth if you had a cellular connection with a small cap or something, but it ends up blocking a lot of normal web browsing and even affects the speed of connection for iOS devices.
I filed a bug report and it is still in "new" state, I guess maybe Brainslayer is an Android user and doesn't care but Kong uses iOS so he ought to
