Patch to support custom port ("to-port") in filter --> dnat v1 PROPOSED

Paul Kilar: 1
 Patch to support custom port ("to-port") in filter --> dnat

 1 files changed, 11 insertions(+), 0 deletions(-)

[alpine-devel] [PATCH] Patch to support custom port ("to-port") in filter --> dnat Export this patch

---
 main/awall/filter.patch | 11 +++++++++++
 1 file changed, 11 insertions(+)
 create mode 100644 main/awall/filter.patch

diff --git a/main/awall/filter.patch b/main/awall/filter.patch
new file mode 100644
index 0000000..924bf8e
--- /dev/null
+++ b/main/awall/filter.patch
@@ -0,0 +1,11 @@
+--- a/awall/modules/filter.lua
++++ b/awall/modules/filter.lua
+@@ -166,7 +166,7 @@
+ 	 self:error(self.dnat..' does not resolve to any IPv4 address')
+       end
+ 
+-      extrarules('dnat', 'dnat', {update={['to-addr']=dnataddr}, discard='out'})
++      extrarules('dnat', 'dnat', {update={['to-addr']=dnataddr, ['to-port']=self['to-port']}, discard='out'})
+    end
+ 
+    if self.action == 'tarpit' or self['no-track'] then
-- 
1.8.2.3



---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---

Kaarle Ritvanen <kaarle.ritvanen@datakunkku.fi>

10 years ago

Hello Paul,

We have actually been planning to introduce the possibility to specify the 
port number in DNAT rules embedded to filters. We agreed on a syntax like 
this to make it clear that "to-port" is related to DNAT:

"dnat": { "to-addr": "<IP address>", "to-port": <port> }

Unfortunately, a valid implementation is a bit more complex than your 
patch. Please check out the class named TranslatingRule to see how the 
IPv4 addresses are overridden by the DNAT target address, in order to make 
the iptables filter rules match. A similar translation is needed for the 
port number in the IPv4 (but not IPv6) rules. Preferably, the 
implementation would also verify that the affected services are not using 
any other protocol than TCP and UDP when port translation is applied.

In case you still want to try to implement the feature, here are a couple 
of hints: You might need to add some hooks to the base class, i.e. 
awall.model.Rule. In addition, it might make sense to move the 
functionality of Rule:servoptfrags to a new class (Service) to make it 
available via the awall.model.ConfigObject:create mechanism.

BR,
Kaarle


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---