search

skullone / android_firewall

This is a fork of Droidwall by Rodrigo Zechin Rosauro - http://code.google.com/p/droidwall/
128 stars 91 forks source link

Conflict Between droidwall-3g and droidwall-vpn Chains #37

Closed necopinus closed 10 years ago

necopinus commented 10 years ago

The "droidwall" chain matches the ppp+ interface for BOTH the droidwall-3g and droidwall-vpn chains. Since all rules end in a RETURN, this means that if your cellular radio shows up as ppp0 (as it does on a Samsung Epic 4g running CyanogenMod 10.1.2) and you're using a white list (the default), then any app which is permitted to use a data connection but denied the use of a VPN connection (or vice versa) will be denied access to both.

Note that it looks like this behavior probably effects other interface pairs (for example, eth+ shows up in a couple of places), but I haven't tested these.

I'm honestly not sure if there's a good way to fix this. More fine-grained interface matching might work, but this is probably going to be REALLY device-specific. Another option might be to add some logic that tries to deduce which interfaces are in use (and what connections they correspond to), but that detection will probably need to be re-run every time the network changes and may still very well require device-specific code.

At the very least, there probably needs to be some kind of warning message about these sorts of conflicts.

skullone commented 10 years ago

I'll look into what I can do about it. On Jul 29, 2013 9:58 AM, "necopinus" notifications@github.com wrote:

The "droidwall" chain matches the ppp+ interface for BOTH the droidwall-3g and droidwall-vpn chains. Since all rules end in a RETURN, this means that if your cellular radio shows up as ppp0 (as it does on a Samsung Epic 4g running CyanogenMod 10.1.2) and you're using a white list (the default), then any app which is permitted to use a data connection but denied the use of a VPN connection (or vice versa) will be denied access to both.

Note that it looks like this behavior probably effects other interface pairs (for example, eth+ shows up in a couple of places), but I haven't tested these.

I'm honestly not sure if there's a good way to fix this. More fine-grained interface matching might work, but this is probably going to be REALLY device-specific. Another option might be to add some logic that tries to deduce which interfaces are in use (and what connections they correspond to), but that detection will probably need to be re-run every time the network changes and may still very well require device-specific code.

At the very least, there probably needs to be some kind of warning message about these sorts of conflicts.

— Reply to this email directly or view it on GitHubhttps://github.com/skullone/android_firewall/issues/37 .

skullone commented 10 years ago

This will be corrected in 2.2.7. ppp and ppp0 are now only in the 3g chain. I have also decided to move the bluetooth tether interfaces to the VPN chain for more fine grained control with BT tether. There are no more duplicates in any of the interface lists.

So VPN interfaces will now be tun, tun0, bnep0, bt-pan. bnep0 and bt-pan are BT tether interfaces and tun/tun0 are typical VPN tunnel interfaces.

The moving of the BT tether interfaces will probably cause some users to have to modify their rule lists (and I apologize for that) but for the ease of use in the future and hopefully no further complications like this I believe it is the right decision.