awall issueshttps://gitlab.alpinelinux.org/alpine/awall/-/issues2024-01-12T18:26:21Zhttps://gitlab.alpinelinux.org/alpine/awall/-/issues/9658awall broken with nft backend due to missing /proc/net/ip_tables_name2024-01-12T18:26:21ZNatanael Copaawall broken with nft backend due to missing /proc/net/ip_tables_nameWith alpine 3.19 we ship iptables with nft backend as the default backend.
I get this warning:
```
alpine:~# awall activate
Warning: firewall not enabled for inet6
Warning: firewall not enabled for inet
Firewall is not active
Press RETU...With alpine 3.19 we ship iptables with nft backend as the default backend.
I get this warning:
```
alpine:~# awall activate
Warning: firewall not enabled for inet6
Warning: firewall not enabled for inet
Firewall is not active
Press RETURN to perform initial configuration and activation:
```
But it seems to work sort of.
We should fix awall to work with nft backend.3.19.1https://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/9657How to do forward only filter2023-07-30T19:17:41ZKévin GuignardHow to do forward only filterHello
I set up a router between two networks (with two interaces) using awall.
```json
"zone": {
"WAN": { "iface": "eth0" },
"LAN": { "iface": "eth1" }
}
```
I'm using **dnat rule** (NOT the dnat attribute of filter rule)...Hello
I set up a router between two networks (with two interaces) using awall.
```json
"zone": {
"WAN": { "iface": "eth0" },
"LAN": { "iface": "eth1" }
}
```
I'm using **dnat rule** (NOT the dnat attribute of filter rule) because I need both IPv4 and IPv6.
Let's say I want dest nat SSH port:
```json
"dnat": [
{
"in": "WAN",
"service": "ssh",
"to-addr": "some.hostname.tld.",
"family": [ "inet", "inet6" ]
}
]
```
this will create a **PREROUTING** rule
```bash
-A PREROUTING -i eth0 -p tcp -m tcp --dport 22 -j DNAT --to-destination A.B.C.D
```
However as I'm leaving the host I need a **FORWARD** rule, but of course if I put in this filter
```json
"filter": [
{
"in": "WAN",
"service": "dns",
"action": "accept"
}
]
```
or this filter
```json
"filter": [
{
"out": "LAN",
"service": "dns",
"action": "accept"
}
]
```
this will create an additional
```bash
-A INPUT -i eth0 -p tcp -m tcp --dport 22 -j ACCEPT
```
or
```bash
-A OUTPUT -o eth1 -p tcp -m tcp --dport 22 -j ACCEPT
```
and theses rules are irrelevant in my case (DNATed request from WAN to another host are not handle neither by INPUT nor OUTPUT)
am I missing something ? Is there a way to do forward rule ? I don't want to handle this with global policy.https://gitlab.alpinelinux.org/alpine/awall/-/issues/9656managing iptables2023-03-10T11:30:41ZGhost Usermanaging iptablesIs there a way to manage iptables with its own config file without using awall? Where sould I place iptables.conf?Is there a way to manage iptables with its own config file without using awall? Where sould I place iptables.conf?https://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
```https://gitlab.alpinelinux.org/alpine/awall/-/issues/9655awall doesn't handle forwarding out the same interface a packet is received on2022-09-09T15:36:54ZAndrew Hendrixawall doesn't handle forwarding out the same interface a packet is received onThis set of awall rules
```json
{
"description": "Default awall policy",
"zone": {
"LAN": { "iface": "eth0" },
"VPN": { "iface": "wg0"}
},
"policy": [
{ "in": "_fw", "action": "accept" },
{ "in": "VPN", "out": "...This set of awall rules
```json
{
"description": "Default awall policy",
"zone": {
"LAN": { "iface": "eth0" },
"VPN": { "iface": "wg0"}
},
"policy": [
{ "in": "_fw", "action": "accept" },
{ "in": "VPN", "out": "VPN", "action": "accept"},
{ "in": "VPN", "out": "LAN", "action": "accept"},
{ "action": "reject" }
]
}
```
results in
```
-A FORWARD -i wg0 -o eth0 -j ACCEPT
```
as expected from `{ "in": "VPN", "out": "LAN", "action": "accept"},`
but does not result in
```
-A FORWARD -i wg0 -o wg0 -j ACCEPT
```
as expected from `{ "in": "VPN", "out": "VPN", "action": "accept"},`
Which is a necessary rule to allow wireguard clients to communicate with each other through a central router if for no other reason. (Just to show that there is a valid use case)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/9654Provide -U3 to diff2022-09-02T12:20:37ZKevin DaudtProvide -U3 to diff`awall diff` uses the `diff` util to show the differences between the current rules and the rules to be applied. When you have diffutils installed, the diff output switches from unified (`-U3`) to context (`-C3`), as that's the default f...`awall diff` uses the `diff` util to show the differences between the current rules and the rules to be applied. When you have diffutils installed, the diff output switches from unified (`-U3`) to context (`-C3`), as that's the default for diffutils.
Please consider providing `-U3` to the diff command to make the output consistent, not matter what version of diff you have installed.https://gitlab.alpinelinux.org/alpine/awall/-/issues/3911Reset iptable policies when executing awall flush2022-08-31T15:03:54ZKevin DaudtReset iptable policies when executing awall flushIt would be nice if executing Awall flush would also reset the iptable
policies, or at least warn about it.
Currently, when after executing the command, you lock the network of the
entire machine, which I think is usually not desireable...It would be nice if executing Awall flush would also reset the iptable
policies, or at least warn about it.
Currently, when after executing the command, you lock the network of the
entire machine, which I think is usually not desireable .
*(from redmine: issue id 3911, created on 2015-02-04)*https://gitlab.alpinelinux.org/alpine/awall/-/issues/9651Support timeout for ipsets2022-06-30T07:18:26ZKevin DaudtSupport timeout for ipsetscrowdsec-firewall-bouncer has a mode to add entries to ipsets. By using ipsets, the iptables chains don't need to be touched by crowdsec-firewall-bouncer, but the ipsets created by awall miss a timeout setting. The documentation says to ...crowdsec-firewall-bouncer has a mode to add entries to ipsets. By using ipsets, the iptables chains don't need to be touched by crowdsec-firewall-bouncer, but the ipsets created by awall miss a timeout setting. The documentation says to create the ipsets with the following commands:
```
ipset create crowdsec-blacklists hash:ip timeout 0 maxelem 150000
ipset create crowdsec6-blacklists hash:ip timeout 0 family inet6 maxelem 150000
```
Without `timeout 0`, it complains it cannot set a timeout on entries because the ipset itself has no timeout.
<details>
<summary>Example policy</summary>
{
"description": "Integration with cs-firewall-bouncer in ipset mode",
"ipset": {
"crowdsec-blacklists": { "type": "hash:ip", "family": "inet" },
"crowdsec6-blacklists": { "type": "hash:ip", "family": "inet6" }
},
"filter": [
{
"in": "adp-wan",
"ipset": [
{ "name": "crowdsec-blacklists", "args": ["in"] },
{ "name": "crowdsec6-blacklists", "args": ["in"] }
],
"action": "drop"
}
]
}
</details>Kaarle RitvanenKaarle Ritvanenhttps://gitlab.alpinelinux.org/alpine/awall/-/issues/9652Support for dhcp62022-06-30T06:42:28ZNatanael CopaSupport for dhcp6Currently dhcpv6 packets are dropped even if `dhcp` service is enabled.
Suggested fix:
```diff
diff --git a/mandatory/services.json b/mandatory/services.json
index 19c4c10..e39188c 100644
--- a/mandatory/services.json
+++ b/mandatory/se...Currently dhcpv6 packets are dropped even if `dhcp` service is enabled.
Suggested fix:
```diff
diff --git a/mandatory/services.json b/mandatory/services.json
index 19c4c10..e39188c 100644
--- a/mandatory/services.json
+++ b/mandatory/services.json
@@ -7,7 +7,10 @@
"bacula-fd": { "proto": "tcp", "port": 9102 },
"bacula-sd": { "proto": "tcp", "port": 9103 },
"bgp": { "proto": "tcp", "port": 179 },
- "dhcp": { "family": "inet", "proto": "udp", "port": [ 67, 68 ] },
+ "dhcp": [
+ { "family": "inet", "proto": "udp", "port": [ 67, 68 ] },
+ { "family": "inet6", "proto": "udp", "port": [ 546, 547 ] }
+ ],
"discard": [
{ "proto": "tcp", "port": 9 },
{ "proto": "udp", "port": 9 }
```https://gitlab.alpinelinux.org/alpine/awall/-/issues/9650REDIRECT to DNAT2022-06-06T13:30:02ZLukáš VoborskýREDIRECT to DNATMaybe im complete newbie, but setting up
```
{
"description": "Forward SSH to srv",
"filter": [
{
"in": "WAN",
"service": { "proto": "tcp", "port": 22202 },
"action": "accept",
"conn-limit": { "count":...Maybe im complete newbie, but setting up
```
{
"description": "Forward SSH to srv",
"filter": [
{
"in": "WAN",
"service": { "proto": "tcp", "port": 22202 },
"action": "accept",
"conn-limit": { "count": 3, "interval": 20 }
}
],
"dnat": [
{
"in": "WAN",
"dest": "192.168.1.202",
"service": { "proto": "tcp", "port": 22202 },
"to-port": "22"
}
]
}
```
Generates REDIRECT command for iptables not DNAT
```
-A PREROUTING -d 192.168.1.202/32 -p tcp -m tcp --dport 22202 -j REDIRECT --to-ports 22
```
I think it should generate
```
-A PREROUTING -p tcp --dport 22202 -j DNAT --to-destination 192.168.1.202:22
```
maybe i dont quite understand your documentation. But i have not found solution to thishttps://gitlab.alpinelinux.org/alpine/awall/-/issues/9643Add comment to iptables rules2021-12-15T15:05:53ZKévin GuignardAdd comment to iptables rulesHello,
I have a use case (collectd with iptables plugin) where I *must* have a comments in iptables.
Manually it means adding `-m comment --comment mycomment` to the rule.
Awall doesn't support this so I'm currently using a dirty patc...Hello,
I have a use case (collectd with iptables plugin) where I *must* have a comments in iptables.
Manually it means adding `-m comment --comment mycomment` to the rule.
Awall doesn't support this so I'm currently using a dirty patch based on rule label, but it could be a new Awall module.https://gitlab.alpinelinux.org/alpine/awall/-/issues/9649Crash when trying to throw "Invalid host name" error2021-12-15T10:42:07ZtuedelCrash when trying to throw "Invalid host name" errorVersion: awall-1.11.0-r0
When awall is unable to resolve a host name in my config (NXDOMAIN), it crashes with the following trace:
```
/usr/share/lua/5.4/awall/host.lua:49: attempt to index a nil value (local 'context')
stack traceback...Version: awall-1.11.0-r0
When awall is unable to resolve a host name in my config (NXDOMAIN), it crashes with the following trace:
```
/usr/share/lua/5.4/awall/host.lua:49: attempt to index a nil value (local 'context')
stack traceback:
/usr/share/lua/5.4/awall/uerror.lua:25: in metamethod 'index'
/usr/share/lua/5.4/awall/host.lua:49: in function 'awall.host.resolve'
/usr/share/lua/5.4/awall/host.lua:78: in function 'awall.host.resolveunique'
/usr/share/lua/5.4/awall/modules/filter.lua:115: in function </usr/share/lua/5.4/awall/modules/filter.lua:106>
(...tail calls...)
/usr/share/lua/5.4/awall/modules/filter.lua:163: in function </usr/share/lua/5.4/awall/modules/filter.lua:162>
(...tail calls...)
/usr/share/lua/5.4/awall/modules/filter.lua:228: in method 'init'
/usr/share/lua/5.4/awall/class.lua:36: in field 'morph'
/usr/share/lua/5.4/awall/init.lua:75: in method 'init'
/usr/share/lua/5.4/awall/class.lua:36: in function </usr/share/lua/5.4/awall/class.lua:29>
(...tail calls...)
/usr/sbin/awall:231: in upvalue 'f'
/usr/share/lua/5.4/awall/uerror.lua:20: in function </usr/share/lua/5.4/awall/uerror.lua:20>
[C]: in function 'xpcall'
/usr/share/lua/5.4/awall/uerror.lua:19: in function 'call'
/usr/sbin/awall:163: in main chunk
[C]: in ?
```
This change fixed it for me:
```diff
diff --git a/awall/host.lua b/awall/host.lua
index 2d59e41..c93083e 100644
--- a/awall/host.lua
+++ b/awall/host.lua
@@ -75,7 +75,7 @@ end
function M.resolveunique(list, families, context)
local res = {}
- for _, addr in M.resolve(list, self, {range=true}) do
+ for _, addr in M.resolve(list, context, {range=true}) do
local family = addr[1]
if util.contains(families, family) then
if res[family] then context:error('Address must be unique') end
```
On a related note I'd like to suggest changing the error message in question from "Invalid host name" to something like "Unable to resolve host name", because that's what is really happening here.https://gitlab.alpinelinux.org/alpine/awall/-/issues/9640Awall silently ignores wrong attributes in policy files2021-11-25T13:35:47ZPhilippe FryciaAwall silently ignores wrong attributes in policy filesUnknown attributes in policy files are ignored, which may lead to
unexpected iptables configuration.
E.g.:
"filter":
[
{
"family": "inet",
"proto": "tcp",
"port": 22,
"action":...Unknown attributes in policy files are ignored, which may lead to
unexpected iptables configuration.
E.g.:
"filter":
[
{
"family": "inet",
"proto": "tcp",
"port": 22,
"action": "accept"
}
]
Will translate without warning, but will allow all traffic (which is
probably not what was intended), because only the action is translated,
and the expected service is not present.
Maybe at least a warning could be generated if a known attribute is used
at a wrong place like in the above example.
Ideally, anything unexpected should be reported.
*(from redmine: issue id 9640, created on 2018-11-12)*https://gitlab.alpinelinux.org/alpine/awall/-/issues/9645Problem with example configuration from wiki article2021-11-25T13:35:47ZMichał PolańskiProblem with example configuration from wiki articleI followed the example configuration from: https://wiki.alpinelinux.org/wiki/Zero-To-Awall and got `attempt to index a nil value (field 'zone')` error.
Steps to reproduce:
1) Create `/etc/awall/private/base.json` with:
```
{
"descrip...I followed the example configuration from: https://wiki.alpinelinux.org/wiki/Zero-To-Awall and got `attempt to index a nil value (field 'zone')` error.
Steps to reproduce:
1) Create `/etc/awall/private/base.json` with:
```
{
"description": "Base zones and policies",
"zone": {
"WAN": { "iface": "eth0" },
"LAN": { "iface": "eth1" },
"VPN": { "iface": "tun+" }
},
"policy": [
{ "in": "VPN", "action": "accept" },
{ "out": "VPN", "action": "accept" },
{ "in": "LAN", "action": "accept" },
{ "out": "LAN", "action": "accept" },
{ "in": "_fw", "action": "accept" },
{ "in": "_fw", "out": "WAN" , "action": "accept" },
{ "in": "WAN", "action": "drop" }
],
"snat": [ { "out": "WAN" } ],
"clamp-mss": [ { "out": "WAN" } ]
}
```
2) Create `/etc/awall/optional/ssh.json` with:
```
{
"description": "Allow rate-limited SSH on WAN",
"filter": [
{
"in": "WAN",
"out": "_fw",
"service": "ssh",
"action": "accept",
"conn-limit": { "count": 3, "interval": 20 }
}
]
}
```
3) Enable the `ssh` policy using `awall enable ssh`.
4) Verify new configuration with `awall translate --verify`.
After that I get this error:
```
/usr/share/lua/5.3/awall/model.lua:194: attempt to index a nil value (field 'zone')
stack traceback:
/usr/share/lua/5.3/awall/uerror.lua:25: in metamethod '__index'
/usr/share/lua/5.3/awall/model.lua:194: in local 'func'
/usr/share/lua/5.3/awall/util.lua:44: in function 'awall.util.map'
(...tail calls...)
/usr/share/lua/5.3/awall/model.lua:189: in function </usr/share/lua/5.3/awall/model.lua:185>
(...tail calls...)
/usr/share/lua/5.3/awall/modules/filter.lua:104: in function </usr/share/lua/5.3/awall/modules/filter.lua:103>
(...tail calls...)
/usr/share/lua/5.3/awall/modules/filter.lua:160: in function </usr/share/lua/5.3/awall/modules/filter.lua:159>
(...tail calls...)
/usr/share/lua/5.3/awall/modules/filter.lua:226: in method 'init'
/usr/share/lua/5.3/awall/class.lua:31: in field 'morph'
/usr/share/lua/5.3/awall/init.lua:129: in method 'init'
/usr/share/lua/5.3/awall/class.lua:31: in function </usr/share/lua/5.3/awall/class.lua:29>
(...tail calls...)
/usr/sbin/awall:235: in upvalue 'f'
/usr/share/lua/5.3/awall/uerror.lua:20: in function </usr/share/lua/5.3/awall/uerror.lua:20>
[C]: in function 'xpcall'
/usr/share/lua/5.3/awall/uerror.lua:19: in function 'call'
/usr/sbin/awall:163: in main chunk
[C]: in ?
```
I have Awall version 1.8.0-r0 on up to date Alpine Linux Edge.https://gitlab.alpinelinux.org/alpine/awall/-/issues/9648dns names starting with numbers are ignored2021-09-21T18:31:45ZAlex Xu (Hello71)dns names starting with numbers are ignored```
$ drill acme-staging-v02.api.letsencrypt.org
[ ... ]
56a5f4b0bc8146689ec3e272c43525f9.pacloudflare.com. 300 IN A 172.65.46.172
```
rejected by https://gitlab.alpinelinux.org/alpine/awall/-/blob/master/awall/famil...```
$ drill acme-staging-v02.api.letsencrypt.org
[ ... ]
56a5f4b0bc8146689ec3e272c43525f9.pacloudflare.com. 300 IN A 172.65.46.172
```
rejected by https://gitlab.alpinelinux.org/alpine/awall/-/blob/master/awall/family.lua#L10 but according to https://serverfault.com/questions/638260/is-it-valid-for-a-hostname-to-start-with-a-digit this was made valid by RFC 1123https://gitlab.alpinelinux.org/alpine/awall/-/issues/9647adp-router.json spoofing error2021-06-21T07:42:03ZTheThiefadp-router.json spoofing errorThe anti-spoofing filter in adp-router.json looks like this:
```json
"filter": [
{
"in": "adp-wan",
"dest": "$adp_lan_private_addrs",
"action": "drop"
}
]
```
but this has the side effect of dropping any port forwarding ...The anti-spoofing filter in adp-router.json looks like this:
```json
"filter": [
{
"in": "adp-wan",
"dest": "$adp_lan_private_addrs",
"action": "drop"
}
]
```
but this has the side effect of dropping any port forwarding rules also, as dnat (for port forward rules) happens in _pre-routing_ and so the packet ends up being processed in the in/forward/out as having an _in interface of WAN_ and a _dest of an internal IP_ - matching this drop rule! This can be worked around by adding `"before": "adp-router",` to any port-forwarding rules.
Unfortunately the above also breaks the default icmp-routing rules that are supposed to allow icmp types 3, 11, and 12 - but get added to the chains _after_ the above supposed anti-spoofing rule and as such get blocked by it.
Shouldn't anti-spoofing be `"src": "$adp_lan_private_addrs",` anyway? A packet with a dest addr of your private IP would never be routed to your WAN interface in the first place, spoofing attacks normally use a forged "src", not "dest".https://gitlab.alpinelinux.org/alpine/awall/-/issues/9644ip6tables-restore v1.8.5 (legacy): Couldn't load match `limit':No such file o...2021-04-22T15:49:13ZEllieip6tables-restore v1.8.5 (legacy): Couldn't load match `limit':No such file or directoryI tried blocking all tcp/ip listener ports on all interfaces (including localhost) other than ssh/port 22 with this policy:
```
{
"description": "Home firewall",
"zone": {
"inet": { "iface": ["eth+", "wwan+", "usb+"] }
},
"...I tried blocking all tcp/ip listener ports on all interfaces (including localhost) other than ssh/port 22 with this policy:
```
{
"description": "Home firewall",
"zone": {
"inet": { "iface": ["eth+", "wwan+", "usb+"] }
},
"policy": [
{ "in": "_fw", "action": "drop" },
{ "in": "inet", "action": "drop" },
{ "in": "_fw", "service": "ssh", "action": "accept" },
{ "in": "inet", "service": "ssh", "action": "accept" },
{ "out": "inet", "action": "accept" },
{ "out": "_fw", "action": "accept" }
],
"snat": [
{ "out": "inet" }
]
}
```
(I assumed later policies have higher priority, sadly I haven't been able to find any clear mention of priority on the wiki so I'm just guessing this)
Sadly, when I try to verify it I get an error I don't understand:
```
# awall translate --verify
ip6tables-restore v1.8.5 (legacy): Couldn't load match `limit':No such file or directory
Error occurred at line: 42
Try `ip6tables-restore -h' or 'ip6tables-restore --help' for more information.
/usr/share/lua/5.2/awall/iptables.lua:92: assertion failed!
stack traceback:
/usr/share/lua/5.2/awall/uerror.lua:25: in function </usr/share/lua/5.2/awall/uerror.lua:21>
[C]: in function 'assert'
/usr/share/lua/5.2/awall/iptables.lua:92: in function 'restore'
/usr/share/lua/5.2/awall/iptables.lua:101: in function 'test'
/usr/share/lua/5.2/awall/init.lua:185: in function 'test'
/usr/sbin/awall:337: in function 'f'
/usr/share/lua/5.2/awall/uerror.lua:20: in function </usr/share/lua/5.2/awall/uerror.lua:20>
[C]: in function 'xpcall'
/usr/share/lua/5.2/awall/uerror.lua:19: in function 'call'
/usr/sbin/awall:163: in main chunk
[C]: in ?
```
Would it be possible to make awall output a better error here to help me understand what is wrong about my config? Or is this a bug?https://gitlab.alpinelinux.org/alpine/awall/-/issues/1535IPSet support in Awall: family option not supported.2021-01-01T09:16:13ZFrancesco ColistaIPSet support in Awall: family option not supported.I’m trying to use ipset with awall.
This is the json i’m using:
```
{
“description”: “Mac Filtering on No-DHCP Interface”,
“import”: “bsna-resnet-base”,
“ipset”: {
“netnodhcp”: {
“type”: “bitmap:ip,mac”,
“range”: “172.17.48....I’m trying to use ipset with awall.
This is the json i’m using:
```
{
“description”: “Mac Filtering on No-DHCP Interface”,
“import”: “bsna-resnet-base”,
“ipset”: {
“netnodhcp”: {
“type”: “bitmap:ip,mac”,
“range”: “172.17.48.0/22”,
“family”: “inet”
}
},
“filter”: \[
{
“in”: “D601”,
“ipset”: { “name”: “netnodhcp”, “args”: “in” },
“out”: “E”,
“action”: “accept”
}
\]
}
```
applying this rule with awall activate, i got this error:
ipset v6.14: Unknown argument: \`family’
Try \`ipset help’ for more information.
ipset creation failed: netnodhcpWarning: inet6 rules not tested
New firewall configuration activated
Problem seems exists because ipset command receive “family” as
arguments, that ipset does not handle.
I found make it works with the following patch, substituting “family”
options with “range”:
```
—- ./usr/share/lua/5.1/awall/ipset.lua
<span class="underline"></span>+ ipset.lua
@@ –17,7 +17,8 @@
local ipset = self.config\[name\]
if not ipset.type then ipset:error(‘Type not defined’) end
if not ipset.family then ipset:error(‘Family not defined’) end
- return {ipset.type, ‘family’, ipset.family}
+ return {ipset.type, ‘range’, ipset.range }
+— return {ipset.type, ‘family’, ipset.family}
end
function IPSet:dumpfile(name, ipsfile)
@@ –28,10 +29,9 @@
function IPSet:create()
for name, ipset in pairs(self.config) do
\- local pid = lpc.run(‘ipset’, ‘-!’, ‘create’, name,
\- unpack(self:options(name)))
+ local pid = lpc.run(‘ipset’, ‘-!’, ‘create’, name,
unpack(self:options(name)))
if lpc.wait(pid) ~= 0 then
- io.stderr:write(‘ipset creation failed: ’..name)
+ io.stderr:write(‘ipset creation failed: ’..name)
end
end
end
```
I’d like to know your opinion at this regard.
Thanks.
*(from redmine: issue id 1535, created on 2013-01-07, closed on 2013-02-08)*
* Changesets:
* Revision a7c8d0718ea806423dce46c1b0163ee058fe1037 by Kaarle Ritvanen on 2013-01-18T18:19:43Z:
```
properly support ipset types other than hashes
move ipset config object handling to model.lua
fixes #1535
```Kaarle RitvanenKaarle Ritvanen