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
