From: carlopmart <carlopmart@gmail.com>
To: netfilter@vger.kernel.org
Subject: Re: Problems with a forward rule
Date: Mon, 14 May 2012 21:35:16 +0200 [thread overview]
Message-ID: <4FB15E74.5070102@gmail.com> (raw)
In-Reply-To: <201205141355.03803.neal.p.murphy@alum.wpi.edu>
On 05/14/2012 07:55 PM, Neal Murphy wrote:
> On Monday 14 May 2012 04:18:23 C. L. Martinez wrote:
>
> As written and presented, your rules:
>>> As written, your rules
>>> 1. Allow all packets for established conns and the first packet for
>>> related conns to pass.
>>> 2. Allow all packets for new conns from the host to pass
>>> 3. Drop all other packets.
>
> Unless I grossly misread, this is what your rules do.
>
> Either these are the rules you are using and you've found they don't work they
> way you expect, or you have provided the list with an incomplete set of rules
> and an incomplete problem statement.
>
>>
>> Sorry Neal, but exists some things in your answer that I don't understand
>> ...
>>
>> In line:
>>> To restrict that host to a particular LAN and allow other hosts through,
>>> these rules in table 'filter':
>>> -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
>>> -A FORWARD -s 172.24.50.3/32 -m state --state NEW -j ACCEPT
>>> -A FORWARD -j LOG --log-prefix "IPT FORWARD packet died: "
>>>
>>> should be:
>>> -A FORWARD -s 172.24.50.3/32 -d a.b.c.d/netmask \
>>> -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
>>
>> Why this rule??:
>
> TCP/IP traffic is bi-directional. You must control the traffic in both
> directions.
>
> You said you wanted to allow traffic from that host to a particular, but
> unspecified, LAN; you did not say you wanted to allow hosts on that LAN to
> initiate conns to that host. The only correct and definitive way to reach your
> stated goal is to
> - allow new and related packets and packets for established conns to
> flow from that host to that LAN
> - allow only related packets and packets for established conns to flow
> from that LAN to that host
> - explicitly block all other traffic between that host to all other LANs
> - explicitly allow all other traffic
> You didn't provide a complete problem statement, only that a particular host
> is to be allowed to communicate (initiate conns) only with a particular LAN.
> Therefore I made the assumption (based on your incomplete rules) that you
> wanted to allow all other traffic.
>
>>> -A FORWARD -s a.b.c.d/netmask -d 172.24.50.3/32 \
>>> -m state --state RELATED,ESTABLISHED -j ACCEPT
>>> -A FORWARD -s 172.24.50.3/32 \
>>> -j LOG --log-prefix "FORWARD dropped packet from 172.24.50.3: "
>>
>> Why this rule??: by default all is denied if it is not exists an
>> established and related connection.
>>
>>> -A FORWARD -s 172.24.50.3/32 -j DROP
>>> -A FORWARD -d 172.24.50.3/32 \
>>> -j LOG --log-prefix "FORWARD dropped packet to 172.24.50.3: "
>>> -A FORWARD -d 172.24.50.3/32 -j DROP
>
> Simple logic. Filtering 101. You must handle more specific conditions before
> you can handle more general conditions, and you must handle the traffic in
> both directions. You could eliminate a couple rules by using negative logic.
> But you'll be sorry next year when you can't recall your convoluted logic to
> make sense of the negative logic. The rules I presented make it very clear
> that (1) conns from that host to that LAN and related conns from that LAN to
> that host are allowed, (2) traffic between that host to anywhere else is
> prohibited.
>
> There is no such thing as an 'established and related' conn. There can be a
> NEW packet (the first packet of a new conn). There can be a RELATED new packet
> (the first packet of a new conn that a helper has determined to be related to
> an existing conn). And there are ESTABLISHED conns. Once a conn is
> established, it is not possible to determine if it started with a NEW packet
> or a RELATED packet. I recently spent a week puzzling through this to finish
> making a new UI for my firewall work correctly. Netfilter has limitations that
> must be understood before you can work with or around them.
>
>>
>> Why this rule??:
>>> -A FORWARD -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
>>
>> I only want to allow related and established connections ... not new
>> if it is not explicit allowed.
>
> So delete that rule. Now the only traffic that will be forwarded will be NEW,
> RELATED and ESTABLISHED packets from that host to that LAN, and RELATED and
> ESTABLISHED packets from that LAN to that host; no other traffic shall be
> forwarded across the router until you add rules that explicitly allow it.
>
> It might be helpful if you provided a complete problem statement.
> --
Neal, I have sended my rules previously:
http://marc.info/?l=netfilter&m=133697448913035&w=2
Sorry If you have misunderstood me, but I only want to allow that host
to access to a specific LAN, not this LAN access to this host
(http://marc.info/?l=netfilter&m=133697780513851&w=2) ...
--
CL Martinez
carlopmart {at} gmail {d0t} com
next prev parent reply other threads:[~2012-05-14 19:35 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-11 15:04 Problems with a forward rule C. L. Martinez
2012-05-12 15:47 ` Jan Engelhardt
2012-05-12 20:53 ` Tom van Leeuwen
2012-05-14 5:45 ` C. L. Martinez
2012-05-14 6:33 ` Tom van Leeuwen
2012-05-14 6:40 ` C. L. Martinez
2012-05-14 7:03 ` Tom van Leeuwen
2012-05-14 7:06 ` C. L. Martinez
2012-05-14 7:24 ` Tom van Leeuwen
2012-05-14 16:47 ` carlopmart
2012-05-14 7:26 ` Neal Murphy
2012-05-14 8:18 ` C. L. Martinez
2012-05-14 17:55 ` Neal Murphy
2012-05-14 19:35 ` carlopmart [this message]
2012-05-14 21:12 ` Neal Murphy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4FB15E74.5070102@gmail.com \
--to=carlopmart@gmail.com \
--cc=netfilter@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.