Feature Request: A UI for rules editing.

[TriMoon]

What I miss most on this app is a User-interface (UI) to add/edit/remove custom rules.
If done well it would also eliminate errors like illegal chars.

I imagine the UI to be like this or or similar:

1. Multi-view of current rules:
   1. A view like it is now, listing all apps.
   2. A view per chain.
   3. A view per application (user id)
2. Short tap on an entry:
   Current functionality to view the log entries related to the one tapped.
   Or switch to view-mode (1.iii)
3. Long tap on entry:
   In all views except the overview mentioned in (1.i) view-mode.
   A pop up with edit/remove option for the entry.
4. Edit/Add entry mode:
   1. Checkbox + listbox with UID's available on the device.
      When the checkbox is selected, the entry will only apply to the UID selected in the listbox.
      The listbox should be automatically populated with the current available UID's on the device and it's entries accompanied with the description of the corresponding application for visual ease.
   2. Input part of rule.
      1. A listbox to select the protocol type, like ANY/TCP/UDP/ICMP etc.
      2. A textbox to enter the source address in CIDR format.
   3. Output part of rule.
      1. A listbox to select the protocol type, like ANY/TCP/UDP/ICMP etc.
      2. A textbox to enter the destination address in CIDR format.
   4. Target part of rule.
      1. A radio selection to select the jump target of the rule, to select either:
         1. Build-in targets like REJECT/DROP/etc.
         2. Chain names that are available.
      2. A listbox to select from, the automatically populated, entries of the choice of the radio selection.
   5. A commit button ofcourse.

Feel free to comment, im sure there is more that can be added that i forgot now :)

[ukanth]

Thanks for the details. I was thinking of custom rules with wizard like interface. If possible, can you prepare some mockups for the above UI ?

[TriMoon]

Unfortunately, i have never coded for android yet.
The parts mentioning "automatically populated", is the wizard part you are referring to i guess...
But feel free to use your imagination when it comes to the visual for the functionality mentioned :)

[cernekee]

Edit/Add entry mode:

Hmm, one of the main benefits of allowing custom rules is that they do not have to follow a specific pattern. They can reference arbitrary netfilter modules, arbitrary targets, and use any of the dozens of flags in the iptables(8) man page.

Some people will use custom rules to allow/deny certain IPs/ports, others will use it to configure stateful connection tracking, others may use it to transparently redirect/proxy traffic, and still others may use it to modify default netd behavior (such as the VPN marks in 4.4+). For rules that involve long lists of IP addresses (e.g. ad blocking) it will not be practical to use a GUI to maintain the list.

If you're just looking for an easy way to build a list of rules, can you use one of the online generators as a starting point:

http://www.perturb.org/content/iptables-rules.html
http://easyfwgen.morizot.net/gen/
http://www.mista.nu/iptables/

I can think of a couple of other ways to enhance the custom rules interface, though:

• Allow importing the custom rules file directly into the AFWall configuration, rather than sourcing a file under /sdcard and running it as root. We can reuse the FileSelect activity from ics-openconnect for this.
• Create aliases based on app names (e.g. "$UID{dev.ukanth.ufirewall}") to translate package names to UIDs, as raw UIDs are not portable between devices and make the rules harder to understand.
• Perform rudimentary syntax checking. This might not necessarily know how to validate chain/target/module names but it could flag obvious errors like missing arguments or non-ASCII characters.
• Create an $IP6TABLES alias, to allow the user to specify different rules for IPv4 vs. IPv6. Run the custom rules once, rather than once for IPv4 + once for IPv6.

[Magissia]

It would also allow port forwarding, seems nice to me.

[ukanth]

Duplicate of #15