Dear Zac,
Your assumption is wrong. One can still use the short form
"SRC_PORT>INT_IP~INT_PORT". So the only real problem is when people
use(d) the undocumented, no longer working, "~SRC_PORT>INT_IP~INT_PORT"
form. The version that no longer allowed this form, is ALSO the version
that introduced rule sanity checking which IS mentioned in the
CHANGELOG. This means, as I also told Julia, that the firewall does
report that it was unable to parse *ALL* rules properly. It even reports
which rule fails and it certainly doesn´t cause any security issues.
Furthermore it's impossible for us to (regression) test any previously
undocumented/unintended functionality and report it in the CHANGELOG
accordingly.
cheers,
Arno
On 24-2-2012 18:21, Slade, Zac wrote:
Arno,
It sounds to me like you made a change to the software that changes the behavior of the
NAT_FORWARD_TCP setting to no longer allow a missing source IP address. In previous versions you allowed
"~SRC_PORT>INT_IP~INT_PORT" and now you must explicitly use the more complete form of
"SRC_IP~SRC_PORT>INT_IP~INT_PORT" or you will have ignored port forwarding rules.
Correct me if I'm wrong Arno, you seem to indicate in this bug report that
the earlier behavior is a bug. If so a note in the CHANGELOG stating that you
addressed a parser BUG would be helpful to anyone. I also understand that you
probably won't be able to do this for the current upload as amending CHANGELOG
entries isn't usually done. Maybe just a note in your upstream CHANGELOG
noting the bug fix.
Julia,
Looking at the current form of the firewall.conf that ships with arno in
sid I see the following:
# NAT TCP/UDP/IP forwards. Forward ports or protocols from the gateway to
# an internal client through (D)NAT. Note that you can also use these
# variables to forward ports to DMZ hosts.
#
# TCP/UDP form:
# "{SRCIP1,SRCIP2,...~}PORT1,PORT2-PORT3,...>DESTIP1{~port} \
# {SRCIP3,...~}PORT3,...>DESTIP2{~port}"
#
# IP form:
# "{SRCIP1,SRCIP2,...~}PROTO1,PROTO2,...>DESTIP1 \
# {SRCIP3~}PROTO3,PROTO4,...>DESTIP2"
#
# TCP/UDP port forward examples:
# Simple (forward port 80 to internal host 192.168.0.10):
# NAT_FORWARD_xxx="80>192.168.0.10 20,21>192.168.0.10"
# Advanced (forward port 20& 21 to 192.168.0.10 and
# forward from 1.2.3.4 port 81 to 192.168.0.11 port 80:
# NAT_FORWARD_xxx="1.2.3.4~81>192.168.0.11~80"
#
# IP protocol forward example:
# (forward protocols 47& 48 to 192.168.0.10)
# NAT_FORWARD_IP="47,48>192.168.0.10"
#
# NOTE 1: {~port} is optional. Use it to redirect a specific port to a
# different port on the internal client.
# NOTE 2: {SRCIPx} is optional. Use it to restrict access for specific source
# (inet) IP addresses.
# (IPv4 Only)
# -----------------------------------------------------------------------------
This does not seem to allow the syntax you were using. Notice the form
"{SRCIP1,SRCIP2,...~}PORT1,PORT2-PORT3,...>DESTIP1{~port}". This seems to
indicate to me that the ~ in your previous examples is what caused your breakage. Can you
confirm that the documentation is correct and that you can set
NAT_FORWARD_TCP=SRC_PORT>INT_IP~INT_PORT and it work correctly?
Thank you,
Zac Slade
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
