IPTables port forwarding issues - Firewalls

This is a discussion on IPTables port forwarding issues - Firewalls ; Hi all, Sorry i know this is covered on the net in various places, but i cannot seem to get what seems straight forward stuff working, by trying various different solutions. Below is a unfinished firewall script that is currently ...

+ Reply to Thread
Results 1 to 12 of 12

Thread: IPTables port forwarding issues

  1. IPTables port forwarding issues

    Hi all,

    Sorry i know this is covered on the net in various places, but i
    cannot seem to get what seems straight forward stuff working, by
    trying various different solutions. Below is a unfinished firewall
    script that is currently used in a test setup. I cannot however get
    port 9023 to port forward from the firewall to an internal boxes ip
    address. When I used nmap it returns filtered? Any suggestions on what
    im missing here? In the test setup this box is providing natted
    internet access.

    I have marked the latest attempted lines i have been attempting to use
    with !!! in the comment line. Please help this is driving me insane

    Thanks in advance

    (Trying to forward port 9023 from interface eth6, to an ip attached to
    interface eth5). Ethername conventions below MAIN and WAN.




    echo Flushing everything in the current setup
    iptables -F INPUT
    iptables -F OUTPUT
    iptables -F FORWARD

    echo Setup default policies to handle unmatched traffic to drop all
    traffic
    iptables -P INPUT DROP
    iptables -P OUTPUT ACCEPT
    iptables -P FORWARD ACCEPT

    echo Setup ethernet name conventions
    export MAIN=eth5
    export NET1=eth4
    export NET2=eth0
    export WAN=eth6
    export LOOPBACK=lo
    #export VPN=tap0
    #export VPNBR=br0

    export IPVPNMAIN=192.168.1.6
    export IPVPNBRIDGE=192.168.1.7
    export EXTERNALIP=xxx.yyy.zzz.ttt

    echo Allowing incomming links from all network adapters to SSHD -
    Seperate rules
    iptables -A INPUT --protocol tcp --dport 10589 -i ${MAIN} -j ACCEPT
    iptables -A INPUT --protocol tcp --dport 10589 -i ${NET1} -j ACCEPT
    iptables -A INPUT --protocol tcp --dport 10589 -i ${NET2} -j ACCEPT
    iptables -A INPUT --protocol tcp --dport 10589 -i ${WAN} -j ACCEPT

    echo Open external port to be forwarded next, for OpenVPN SSH Remote
    Access
    iptables -A INPUT --protocol tcp --dport 9023 -i ${WAN} -j ACCEPT

    echo Allowing incomming links porwarded to VPN Machine for SSH Links
    #iptables -t nat -A PREROUTUING --protocol tcp --dport 9023 -j DNAT --
    to ${IPVPNMAIN}:9023

    echo Setup Logging and destruction of Spoofed Internal packets, not
    created from external networks
    iptables -A INPUT -j LOG -i ${MAIN} \! -s 192.168.1.0/24
    iptables -A INPUT -j LOG -i ${NET1} \! -s 192.168.11.0/24
    iptables -A INPUT -j LOG -i ${NET2} \! -s 192.168.12.0/24
    iptables -A INPUT -j DROP -i ${MAIN} \! -s 192.168.1.0/24
    iptables -A INPUT -j DROP -i ${NET1} \! -s 192.168.11.0/24
    iptables -A INPUT -j DROP -i ${NET2} \! -s 192.168.12.0/24

    echo Block packets from network addresses outside of the source
    address range - IP Spoofing
    iptables -A INPUT -j LOG \! -i ${MAIN} -s 192.168.1.0/24
    iptables -A INPUT -j LOG \! -i ${NET1} -s 192.168.11.0/24
    iptables -A INPUT -j LOG \! -i ${NET2} -s 192.168.12.0/24
    iptables -A INPUT -j DROP \! -i ${MAIN} -s 192.168.1.0/24
    iptables -A INPUT -j DROP \! -i ${NET1} -s 192.168.11.0/24
    iptables -A INPUT -j DROP \! -i ${NET2} -s 192.168.12.0/24

    echo Protect loopback systems from IP Spoofing
    iptables -A INPUT -j DROP -i \! ${LOOPBACK} -s 127.0.0.0/255.0.0.0

    echo Allowing previously initiated and accepted exchanges bypass
    remaining rule checking
    iptables -A INPUT -m state --state ESTABLISHED,RELATED -i ${WAN} -p \!
    icmp -j ACCEPT

    echo Allow all connections from the localhost
    iptables -A INPUT -j ACCEPT -i ${LOOPBACK}

    echo Allowing connections to Squid Proxy Server from dialer networks
    iptables -A INPUT --protocol tcp --dport 3128 -i ${NET1} -j ACCEPT
    iptables -A INPUT --protocol tcp --dport 3128 -i ${NET2} -j ACCEPT

    echo Allowing DNS Forwarder and Caching hosted by this server to be
    accessed by everyone but not WAN
    iptables -A INPUT -p UDP --dport 53 -i ${MAIN} -j ACCEPT
    iptables -A INPUT -p UDP --dport 53 -i ${NET1} -j ACCEPT
    iptables -A INPUT -p UDP --dport 53 -i ${NET2} -j ACCEPT

    echo Allow all connections from the Network Servers
    iptables -A INPUT -s 192.168.1.5 -j ACCEPT
    iptables -A INPUT -s 192.168.11.5 -j ACCEPT
    iptables -A INPUT -s 192.168.12.5 -j ACCEPT


    ### NOTE NOT REQUIRED ALL OUTGOING ALLOWED ### -> To be corrected
    later
    # echo Allow DNS Resolution
    # iptables -A OUTPUT -o ${WAN} -p udp --destination-port 53 -m state --
    state NEW,ESTABLISHED -j ACCEPT
    # iptables -A OUTPUT -o ${WAN} -p tcp --destination-port 53 -m state --
    state NEW,ESTABLISHED -j ACCEPT

    echo Lock down system services to the main network only
    iptables -A INPUT -i lo -j ACCEPT
    iptables -A INPUT -i ${MAIN} -j ACCEPT
    iptables -A INPUT -p UDP --dport bootps -i ! ${MAIN} -j REJECT
    iptables -A INPUT -p UDP --dport domain -i ! ${MAIN} -j REJECT

    echo Dropping any other outside generated connections
    iptables -A INPUT -m state --state NEW -i ${WAN} -j DROP

    #echo Enabling IP Masq to enable NAT style internet IP Redirection
    Access
    iptables -t nat -A POSTROUTING -o ${WAN} -j MASQUERADE

    # !!! THESE ARE ATTEMPTED PORT FORWARDING RULES CURRENTLY NOT WORKING :
    (
    iptables -A FORWARD -i ${WAN} -o ${MAIN} -p tcp --dport 9023 -m state
    --state NEW,ESTABLISHED,RELATED -j ACCEPT
    iptables -A PREROUTING -t nat -p tcp -d ${EXTERNALIP} --dport 9023 -m
    state --state NEW,ESTABLISHED,RELATED -j DNAT --to ${IPVPNMAIN}:9023
    iptables -t nat -A POSTROUTING -d ${IPVPNMAIN} -s 192.168.1.0 -p tcp --
    dport 9023 -m state --state NEW,ESTABLISHED,RELATED -j SNAT --to $
    {IPVPNMAIN}


  2. Re: IPTables port forwarding issues

    fubar2007@googlemail.com wrote:
    > Sorry i know this is covered on the net in various places, but i
    > cannot seem to get what seems straight forward stuff working, by
    > trying various different solutions. Below is a unfinished firewall
    > script that is currently used in a test setup. I cannot however get
    > port 9023 to port forward from the firewall to an internal boxes ip
    > address. When I used nmap it returns filtered? Any suggestions on what
    > im missing here? In the test setup this box is providing natted
    > internet access.

    [...]
    > echo Flushing everything in the current setup
    > iptables -F INPUT
    > iptables -F OUTPUT
    > iptables -F FORWARD
    >
    > echo Setup default policies to handle unmatched traffic to drop all traffic
    > iptables -P INPUT DROP
    > iptables -P OUTPUT ACCEPT
    > iptables -P FORWARD ACCEPT


    As a side-note: you should set the default policies before flushing the
    chains. Also you should delete user-defined chains.

    [...]
    > echo Allowing incomming links porwarded to VPN Machine for SSH Links
    > #iptables -t nat -A PREROUTUING --protocol tcp --dport 9023 -j DNAT
    > --to ${IPVPNMAIN}:9023


    That line is supposed to do the trick, except that you could've omitted
    the port in the --to since you don't redirect to a different port.

    iptables -t nat -A PREROUTING -I ${WAN} -p tcp --dport 9023 -j DNAT \
    --to ${IPVPNMAIN}

    Does this fail? If so: what did the logs say about incoming packets on
    that port?

    [...]
    > #echo Enabling IP Masq to enable NAT style internet IP Redirection Access
    > iptables -t nat -A POSTROUTING -o ${WAN} -j MASQUERADE
    >
    > # !!! THESE ARE ATTEMPTED PORT FORWARDING RULES CURRENTLY NOT WORKING :
    > (
    > iptables -A FORWARD -i ${WAN} -o ${MAIN} -p tcp --dport 9023 -m state
    > --state NEW,ESTABLISHED,RELATED -j ACCEPT
    > iptables -A PREROUTING -t nat -p tcp -d ${EXTERNALIP} --dport 9023 -m
    > state --state NEW,ESTABLISHED,RELATED -j DNAT --to ${IPVPNMAIN}:9023


    You're thinking too complicated. DNAT merely rewrites the destination
    address before the packet enters the actual filtering chains (see the
    NAT-HOWTO [1]). Do the filtering in the filtering chains where it
    belongs:

    iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
    iptables -A INPUT -i ${WAN} -p tcp --dport 9023 -m state --state NEW \
    -j ACCEPT

    > iptables -t nat -A POSTROUTING -d ${IPVPNMAIN} -s 192.168.1.0 -p tcp --
    > dport 9023 -m state --state NEW,ESTABLISHED,RELATED -j SNAT --to $
    > {IPVPNMAIN}


    You don't need SNAT, because you're already doing Masquerading (which is
    a special form of SNAT).

    [1] http://www.netfilter.org/documentati...O-6.html#ss6.2

    cu
    59cobalt
    --
    "If a software developer ever believes a rootkit is a necessary part of
    their architecture they should go back and re-architect their solution."
    --Mark Russinovich

  3. Re: IPTables port forwarding issues


    Hi thanks for the response, unforunately not there yet . I changed
    the default policys to set before the chain flushes thanks.

    The line

    iptables -t nat -A PREROUTUING --protocol tcp --dport 9023 -j DNAT
    > --to ${IPVPNMAIN}:9023 does not give any errors when run.


    Regarding the logs do you know where i would find these on gentoo
    linux 2.6.19-release-r5? I looked in /var/log/messages but there was
    only system general logging, no iptables from what i could see.

    Is there a sepecial command in the firewall script i need to log
    tracking of how iptables parses its connections through the various
    chains?

    Thanks again for all the help.


  4. Re: IPTables port forwarding issues

    fubar2007@googlemail.com wrote:
    > The line
    >
    > iptables -t nat -A PREROUTUING --protocol tcp --dport 9023 -j DNAT
    > --to ${IPVPNMAIN}:9023 does not give any errors when run.


    It may be just a typo, but it's supposed to read PREROUTING, not
    PREROUTUING. And no, the line isn't supposed to raise an error, as the
    syntax is correct AFAICS (aside from said typo).

    > Regarding the logs do you know where i would find these on gentoo
    > linux 2.6.19-release-r5? I looked in /var/log/messages but there was
    > only system general logging, no iptables from what i could see.


    I'm not familiar with Gentoo, but I'd try /var/log/syslog. And of course
    you need advise netfilter to create log entries first by adding a
    logging rule at the end of each chain. Also I need to correct my
    previous suggestion: of course you need to allow the forwarded packets
    in the FORWARD chain, not in the INPUT chain. Sorry.

    iptables -A PREROUTING -i ${WAN} -p tcp --dport 9023 -j DNAT \
    --to ${IPVPNMAIN}

    # ... <- INPUT chain rules go here
    iptables -A INPUT -j LOG # log everything else

    iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
    iptables -A FORWARD -i ${WAN} -p tcp --dport 9023 -m state --state NEW \
    -j ACCEPT
    # ... <- more FORWARD chain rules go here
    iptables -A FORWARD -j LOG # log everything else

    iptables -A POSTROUTING -j SNAT -o ${WAN} --to ${EXTERNALIP}

    > Is there a sepecial command in the firewall script i need to log
    > tracking of how iptables parses its connections through the various
    > chains?


    You mean how the packets flow through the chains? That's well-defined,
    see e.g. [1].

    [1] http://ebtables.sourceforge.net/br_fw_ia/PacketFlow.png

    cu
    59cobalt
    --
    "If a software developer ever believes a rootkit is a necessary part of
    their architecture they should go back and re-architect their solution."
    --Mark Russinovich

  5. Re: IPTables port forwarding issues

    Ansgar -59cobalt- Wiechers wrote:


    >> Is there a sepecial command in the firewall script i need to log
    >> tracking of how iptables parses its connections through the various
    >> chains?

    >
    > You mean how the packets flow through the chains? That's well-defined,
    > see e.g. [1].
    >
    > [1] http://ebtables.sourceforge.net/br_fw_ia/PacketFlow.png


    I recommend looking at:

    http://www.netfilter.org/documentati...g-HOWTO-6.html

    and on that picture you see that the INPUT chain will filter no packets for
    targets not adressed to the filtering host. All filtering of NATTED packets
    is done in the FORWARD chain, never in INPUT.

    I'd simply recommend loading the rules and then
    iptables -nvL
    and
    iptables -nvL -t nat

    to see the loaded ruleset.

    To see where the packets go I'd add

    iptables -A FORWARD -j LOG --log-prefix "debug "

    as the first rule of FORWARD chain and some grep on the logfile afterwards.

    Assuming a pretty normal config of syslog or syslog-ng the logs from the
    packet filter should be found either in /var/log/messages
    or /var/log/firewall or so,

    Wolfgang

  6. Re: IPTables port forwarding issues

    Wolfgang Kueter wrote:
    > Ansgar -59cobalt- Wiechers wrote:
    >>> Is there a sepecial command in the firewall script i need to log
    >>> tracking of how iptables parses its connections through the various
    >>> chains?

    >>
    >> You mean how the packets flow through the chains? That's well-defined,
    >> see e.g. [1].
    >>
    >> [1] http://ebtables.sourceforge.net/br_fw_ia/PacketFlow.png

    >
    > I recommend looking at:
    >
    > http://www.netfilter.org/documentati...g-HOWTO-6.html
    >
    > and on that picture you see that the INPUT chain will filter no
    > packets for targets not adressed to the filtering host. All filtering
    > of NATTED packets is done in the FORWARD chain, never in INPUT.


    What exactly does that ASCII drawing show that's not present in the
    image I linked?

    [...]
    > To see where the packets go I'd add
    >
    > iptables -A FORWARD -j LOG --log-prefix "debug "
    >
    > as the first rule of FORWARD chain and some grep on the logfile
    > afterwards.


    Nonsense. You add the logging rule at the end of the chain, because you
    want to know about the dropped packets. Why would you care about
    accepted packets? For the given problem they just add unnecessary noise
    to the logs. Adding a prefix is a good suggestion, though, as it helps
    identifying the relevant log entries.

    > Assuming a pretty normal config of syslog or syslog-ng the logs from
    > the packet filter should be found either in /var/log/messages or
    > /var/log/firewall or so,


    One could use 'grep "PREFIX STRING" /var/log/*' to identify the log
    file.

    cu
    59cobalt
    --
    "If a software developer ever believes a rootkit is a necessary part of
    their architecture they should go back and re-architect their solution."
    --Mark Russinovich

  7. Re: IPTables port forwarding issues

    Ansgar -59cobalt- Wiechers wrote:


    >> iptables -A FORWARD -j LOG --log-prefix "debug "
    >>
    >> as the first rule of FORWARD chain and some grep on the logfile
    >> afterwards.

    >
    > Nonsense. You add the logging rule at the end of the chain, because you
    > want to know about the dropped packets.


    The packets the OP looks for are not dropped. They seem to vanish. And to
    check that, you need to see every packet that enters the filter and then
    follow it's tracks.

    > Why would you care about accepted packets?


    Of course you don't need that in normal operation. But here we are talking
    about 'debug mode'. Sometimes one needs that for debugging, to make that
    clear I wrote '--log-prefix "debug "'

    > For the given problem they just add unnecessary noise
    > to the logs.


    Nope, you want to hear everything in debug mode. ,)

    Wolfgang




  8. Re: IPTables port forwarding issues

    Wolfgang Kueter wrote:
    > Ansgar -59cobalt- Wiechers wrote:
    >>> iptables -A FORWARD -j LOG --log-prefix "debug "
    >>>
    >>> as the first rule of FORWARD chain and some grep on the logfile
    >>> afterwards.

    >>
    >> Nonsense. You add the logging rule at the end of the chain, because
    >> you want to know about the dropped packets.

    >
    > The packets the OP looks for are not dropped. They seem to vanish.


    Packets do not "vanish". Unless there are rules doing some funky stuff
    (which isn't the case here, except for two REJECT rules that don't apply
    to the packets in question) packets are either ACCEPTed or DROPed.
    Period. And how would you know that the packets are not dropped? The
    logging rules the OP has in place (according to what he posted) won't
    match the NATed packets, so they simply won't show up in the logs.

    [...]
    >> Why would you care about accepted packets?

    >
    > Of course you don't need that in normal operation. But here we are
    > talking about 'debug mode'. Sometimes one needs that for debugging, to
    > make that clear I wrote '--log-prefix "debug "'
    >
    >> For the given problem they just add unnecessary noise to the logs.

    >
    > Nope, you want to hear everything in debug mode. ,)


    I most certainly do not want to drown in log entries when trouble-
    shooting something. I'd start with a basic ruleset (only ACCEPT rules)
    and the LOG rule at the end of the chain. Either the packet is logged
    when it hits the LOG rule (and is subsequently dropped), or it hits an
    ACCEPT rule before and is delivered, in which case I'd suggest to start
    inspecting the traffic with a sniffer, because the problem probably lies
    elsewhere.

    cu
    59cobalt
    --
    "If a software developer ever believes a rootkit is a necessary part of
    their architecture they should go back and re-architect their solution."
    --Mark Russinovich

  9. Re: IPTables port forwarding issues

    Ansgar -59cobalt- Wiechers wrote:


    >> Nope, you want to hear everything in debug mode. ,)

    >
    > I most certainly do not want to drown in log entries when trouble-
    > shooting something.


    I've trouble-shooted Linux filters more than once and sonething like

    tail -f /path/to/logfile | grep debug | grep ...

    has saved me from drowning most of the time.

    > I'd start with a basic ruleset (only ACCEPT rules)
    > and the LOG rule at the end of the chain. Either the packet is logged
    > when it hits the LOG rule (and is subsequently dropped), or it hits an
    > ACCEPT rule before and is delivered, in which case I'd suggest to start
    > inspecting the traffic with a sniffer, because the problem probably lies
    > elsewhere.


    The 'log-all' rule at the beginnig of a chain (or even all chains) makes
    quite a good sniffer and installing such a rule takes far less time than
    firing up etherreal and getting monitor port on the switch ready.

    Wolfgang

  10. Re: IPTables port forwarding issues

    Wolfgang Kueter wrote:

    Well, Ansgar, because it is you, I'll give an example to make things clear:



    > The 'log-all' rule at the beginnig of a chain (or even all chains) makes
    > quite a good sniffer and installing such a rule takes far less time than
    > firing up etherreal and getting monitor port on the switch ready.


    Think about the following sample:

    ---8<---
    iptables -N rule_01
    iptables -N rule_02
    iptables -N rule_03
    iptables -N stop

    iptables -A FORWARD -j LOG --log-prefix "packet entered forward chain "
    # traffic to/from MACHINE_01 is handled in rule_01
    iptables -A FORWARD -s $MACHINE_01 -j rule_01
    iptables -A FORWARD -d $MACHINE_01 -j rule_01
    iptables -A rule_01 -j LOG --log-prefix "packet entered rule_01 "
    iptables -A rule_01
    iptables -A rule_01
    iptables -A rule_01 -j LOG --log-prefix "packet not permitted in rule_01"
    iptables -A rule_01 -j stop

    # traffic to/from MACHINE_02 is handled in rule_02
    iptables -A FORWARD -s $MACHINE_02 -j rule_02
    iptables -A FORWARD -d $MACHINE_02 -j rule_02
    iptables -A rule_02 -j LOG --log-prefix "packet entered rule_02 "
    iptables -A rule_02
    iptables -A rule_02
    iptables -A rule_02 -j LOG --log-prefix "packet not permitted in rule_02"
    iptables -A rule_02 -j stop

    [..]

    iptables -A FORWARD -j LOG --log-prefix "packet not permitted in forward "
    iptables -A FORWARD -j stop
    iptables -A stop -j REJECT --reject-with icmp-host-prohibited

    ---8<---

    If you build your ruleset according to that example you can easily follow
    each packet through the filter for debugging even in a complicated setup
    completely and you don't need a sniffer at all, because the sniffer is
    built in ...

    Wolfgang

  11. Re: IPTables port forwarding issues

    Wolfgang Kueter wrote:
    > Well, Ansgar, because it is you, I'll give an example to make things
    > clear:


    Don't get smart with me, bub. I know pretty well how to use logging and
    log-prefixes. I just don't agree that it would be easier than what I
    suggested:

    ----8<----
    iptables -P INPUT DROP
    iptables -P OUTPUT DROP
    iptables -P FORWARD DROP

    iptables -A PREROUTING -i ${WAN} -p tcp --dport 9023 -j DNAT \
    --to ${IPVPNMAIN}

    iptables -A INPUT -I lo -j ACCEPT
    iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
    iptables -A INPUT -j LOG --log-prefix "dbg_nf_in drop: "

    iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
    iptables -A OUTPUT -j LOG --log-prefix "dbg_nf_out drop: "

    iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
    iptables -A FORWARD -i ${WAN} -p tcp --dport 9023 -m state --state NEW \
    -j ACCEPT
    iptables -A FORWARD -j LOG --log-prefix "dbg_nf_fwd drop: "

    iptables -A POSTROUTING -j SNAT -o ${WAN} --to ${EXTERNALIP}
    ---->8----

    Either a packet is logged (in case it didn't match any ACCEPT rule), or
    it is ACCEPTed and thus delivered by netfilter. In the latter case I'd
    run 'tcpdump -nvvi $INTERFACE "tcp port 9023"' to see where the traffic
    is going after it leaves the filter.

    Maybe we can agree on something like this:

    ----8<----
    iptables -P INPUT DROP
    iptables -P OUTPUT DROP
    iptables -P FORWARD DROP

    iptables -A PREROUTING -i ${WAN} -p tcp --dport 9023 -j DNAT \
    --to ${IPVPNMAIN}

    iptables -A INPUT -j LOG --log-prefix "dbg_nf_in enter: "
    iptables -A INPUT -I lo -j ACCEPT
    iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
    iptables -A INPUT -j LOG --log-prefix "dbg_nf_in drop: "

    iptables -A OUTPUT -j LOG --log-prefix "dbg_nf_out enter: "
    iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
    iptables -A OUTPUT -j LOG --log-prefix "dbg_nf_out drop: "

    iptables -A FORWARD -j LOG --log-prefix "dbg_nf_fwd enter: "
    iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
    iptables -A FORWARD -i ${WAN} -p tcp --dport 9023 -m state --state NEW \
    -j ACCEPT
    iptables -A FORWARD -j LOG --log-prefix "dbg_nf_fwd drop: "

    iptables -A POSTROUTING -j SNAT -o ${WAN} --to ${EXTERNALIP}
    ---->8----

    However, you'd still have to inspect the traffic that is not dropped.

    cu
    59cobalt
    --
    "If a software developer ever believes a rootkit is a necessary part of
    their architecture they should go back and re-architect their solution."
    --Mark Russinovich

  12. Re: IPTables port forwarding issues

    Ansgar -59cobalt- Wiechers wrote:

    > Wolfgang Kueter wrote:
    >> Well, Ansgar, because it is you, I'll give an example to make things
    >> clear:

    >
    > Don't get smart with me, bub. I know pretty well how to use logging and
    > log-prefixes.


    I know.

    > I just don't agree that it would be easier than what I
    > suggested:




    > Maybe we can agree on something like this:
    >
    > [...]


    Yes, I regard that as an acceptable compromise.

    best wishes
    Wolfgang

+ Reply to Thread