awall issueshttps://gitlab.alpinelinux.org/alpine/awall/-/issues2023-12-26T14:58:27Zhttps://gitlab.alpinelinux.org/alpine/awall/-/issues/9653nftables and future direction for development2023-12-26T14:58:27ZKaarle Ritvanennftables and future direction for developmentInspired by aports#14058, I am opening this issue to collect feedback from
`awall` users to decide on its future direction.
The Linux kernel has a new firewall subsystem called `nftables`, which is
intended to replace the old `iptables`...Inspired by aports#14058, I am opening this issue to collect feedback from
`awall` users to decide on its future direction.
The Linux kernel has a new firewall subsystem called `nftables`, which is
intended to replace the old `iptables` over time. `awall` was created ten years
ago as an abstraction layer on top of `iptables` to address [its
shortcomings](https://gitlab.alpinelinux.org/alpine/awall#introduction). Some
of these have been addressed by the newer `nftables` and the corresponding
user-space tool `nft`. For example, it is possible to define variables and
combined IPv4/6 rules, as well as split rules into modules. On the other hand,
it is not possible to define e.g. zones, inter-module dependencies, nor fall
back to the previous configuration.
So I would like to hear your opinions on whether `awall` still has value
despite the introduction of `nftables` and what is the best way forward. At
least the following alternatives come to my mind:
1. Co-exist with `nftables` with minimal changes leveraging the compatible
`iptables` tools
2. Convert `awall` to interface with `nft` instead of `iptables`, retaining
compatibility on `awall` policy file level
3. Implement a more lightweight layer on top of `nft`, providing the missing
abstractions that are deemed useful
4. Address the gaps by working with upstream to have the essential features
implemented in `nft`https://gitlab.alpinelinux.org/alpine/awall/-/issues/3689MAC address support2022-09-09T15:20:02ZMiguel DiasMAC address supportIt would be nice to have MAC address support in the json
configuration.
As “iface” and “addr” is already possible, one could create “mac”.
Something like this:
"zone":{
"internet":{
"iface":"eth0"
}...It would be nice to have MAC address support in the json
configuration.
As “iface” and “addr” is already possible, one could create “mac”.
Something like this:
"zone":{
"internet":{
"iface":"eth0"
},
"tablet":{
"addr": "192.168.1.10"
},
"smartphone": {
"mac":"08:00:27:C0:E6:DC"
}
}
*(from redmine: issue id 3689, created on 2015-01-09)*Kaarle RitvanenKaarle Ritvanenhttps://gitlab.alpinelinux.org/alpine/awall/-/issues/2220Need UPnP/NAT-PMP support2022-09-09T15:51:42ZEric WangNeed UPnP/NAT-PMP supportMost of devices behind the Alpine Linux router are Windows PC and/or
Apple Mac.
In order for these internal client to be fully benefited from
UPnP/NAT-PMP applications, such as bittorrent client, video streaming,
gaming, etc., AWall ne...Most of devices behind the Alpine Linux router are Windows PC and/or
Apple Mac.
In order for these internal client to be fully benefited from
UPnP/NAT-PMP applications, such as bittorrent client, video streaming,
gaming, etc., AWall need to support UPnP/NAT-PMP and provide a
configuration interface to switch on/off (for security reason, and users
owns the risk)
One of the feasible solution is to loop-in the existing solution, the
popular miniupnpd (http://miniupnp.free.fr). We also could take
reference from pfSense OS.
*(from redmine: issue id 2220, created on 2013-08-13)*
* Changesets:
* Revision b4573a1dddec7011870401b918130e247518898c by Natanael Copa on 2014-05-30T14:24:29Z:
```
testing/miniupnpd: upgrade to 1.8.20140523
ref #2220
```