Problems with a forward rule

Problems with a forward rule

[C. L. Martinez]

Hi all,

 I have setup the following rules in a centos6 gateway:

Chain INPUT (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source
destination
    6   300 TCPFLAGS   tcp  --  *      *       0.0.0.0/0
0.0.0.0/0
    6   300 ACCEPT     all  --  lo     *       0.0.0.0/0
0.0.0.0/0
    0     0 DROP       all  --  *      *       224.0.0.0/4
0.0.0.0/0
    0     0 DROP       all  --  *      *       0.0.0.0/0
224.0.0.0/4
    0     0 DROP       all  --  *      *       240.0.0.0/5
0.0.0.0/0
    0     0 DROP       all  --  *      *       0.0.0.0/0
10.196.129.255
    0     0 ACCEPT     all  --  *      *       0.0.0.0/0
0.0.0.0/0           state RELATED,ESTABLISHED
    0     0 ACCEPT     icmp --  *      *       0.0.0.0/0
0.0.0.0/0           state NEW icmp type 8 limit: avg 1/sec burst 1
    0     0 SSH        tcp  --  *      *       0.0.0.0/0
0.0.0.0/0           tcp dpt:22 state NEW
    0     0 LOG        all  --  *      *       0.0.0.0/0
0.0.0.0/0           LOG flags 0 level 4 prefix `IPT INPUT packet died:
'

Chain FORWARD (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source
destination
    0     0 ACCEPT     all  --  *      *       0.0.0.0/0
0.0.0.0/0           state RELATED,ESTABLISHED
    0     0 ACCEPT     all  --  *      *       172.24.50.3
0.0.0.0/0           state NEW
    0     0 LOG        all  --  *      *       0.0.0.0/0
0.0.0.0/0           LOG flags 0 level 4 prefix `IPT FORWARD packet
died: '

Chain OUTPUT (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source
destination
    6   300 TCPFLAGS   tcp  --  *      *       0.0.0.0/0
0.0.0.0/0
    6   300 ACCEPT     all  --  *      lo      0.0.0.0/0
0.0.0.0/0
    0     0 ACCEPT     all  --  *      *       0.0.0.0/0
0.0.0.0/0           state NEW,RELATED,ESTABLISHED
    0     0 LOG        all  --  *      *       0.0.0.0/0
0.0.0.0/0           LOG flags 0 level 4 prefix `IPT OUTPUT packet
died: '

Chain BADFLAGS (8 references)
 pkts bytes target     prot opt in     out     source
destination
    0     0 LOG        all  --  *      *       0.0.0.0/0
0.0.0.0/0           LOG flags 0 level 4 prefix `IPT TCPFLAGS: '
    0     0 DROP       all  --  *      *       0.0.0.0/0
0.0.0.0/0

Chain SSH (1 references)
 pkts bytes target     prot opt in     out     source
destination
    0     0 ACCEPT     all  --  *      *       0.0.0.0/0
0.0.0.0/0           limit: avg 3/min burst 1
    0     0 LOG        all  --  *      *       0.0.0.0/0
0.0.0.0/0           LOG flags 0 level 4 prefix `IPT SSH connection too
fast: '
    0     0 DROP       all  --  *      *       0.0.0.0/0
0.0.0.0/0

Chain TCPFLAGS (2 references)
 pkts bytes target     prot opt in     out     source
destination
    0     0 LOG        tcp  --  *      *       0.0.0.0/0
0.0.0.0/0           state INVALID LOG flags 0 level 4 prefix `IPT
INVALID: '
    0     0 DROP       tcp  --  *      *       0.0.0.0/0
0.0.0.0/0           state INVALID
    0     0 BADFLAGS   tcp  --  *      *       0.0.0.0/0
0.0.0.0/0           tcp flags:!0x17/0x02 state NEW
    0     0 REJECT     tcp  --  *      *       0.0.0.0/0
0.0.0.0/0           tcp flags:0x12/0x12 state NEW reject-with
tcp-reset
    0     0 BADFLAGS   tcp  --  *      *       0.0.0.0/0
0.0.0.0/0           tcp flags:0x11/0x01
    0     0 BADFLAGS   tcp  --  *      *       0.0.0.0/0
0.0.0.0/0           tcp flags:0x18/0x08
    0     0 BADFLAGS   tcp  --  *      *       0.0.0.0/0
0.0.0.0/0           tcp flags:0x30/0x20
    0     0 BADFLAGS   tcp  --  *      *       0.0.0.0/0
0.0.0.0/0           tcp flags:0x05/0x05
    0     0 BADFLAGS   tcp  --  *      *       0.0.0.0/0
0.0.0.0/0           tcp flags:0x03/0x03
    0     0 BADFLAGS   tcp  --  *      *       0.0.0.0/0
0.0.0.0/0           tcp flags:0x06/0x06
    0     0 BADFLAGS   tcp  --  *      *       0.0.0.0/0
0.0.0.0/0           tcp flags:0x3F/0x00

All works ok, except when I try to restrict one host to go out via
external interface. My problem is with the following rule:

   0     0 ACCEPT     all  --  *      *       172.24.50.3
0.0.0.0/0           state NEW

If I try to restrict destination, doesn't works. For example using this rule:

iptables -A FORWARD -s 172.24.50.3 -d 1.1.1.0/24 -m state --state NEW -j ACCEPT

only works if I do:

 iptables -A FORWARD -s 172.24.50.3 -m state --state NEW -j ACCEPT

then, what am I doing wrong??

Re: Problems with a forward rule

[Jan Engelhardt]

On Friday 2012-05-11 17:04, C. L. Martinez wrote:

>Hi all,
>
> I have setup the following rules in a centos6 gateway:
>[ugly iptables -L]

*Use* iptables-save and provide a *full* ruleset.

>All works ok, except when I try to restrict one host to go out via
>external interface. My problem is with the following rule:
>
>   0     0 ACCEPT     all  --  *      *       172.24.50.3
>0.0.0.0/0           state NEW
>
>If I try to restrict destination, doesn't works. For example using this rule:
>
>iptables -A FORWARD -s 172.24.50.3 -d 1.1.1.0/24 -m state --state NEW -j ACCEPT
>
>only works if I do:
>
> iptables -A FORWARD -s 172.24.50.3 -m state --state NEW -j ACCEPT
>
>then, what am I doing wrong??

Re: Problems with a forward rule

[Tom van Leeuwen]

Indeed do iptables-save for the complete ruleset and tell us what you 
want and expect.

On 12-5-2012 17:47, Jan Engelhardt wrote:
> On Friday 2012-05-11 17:04, C. L. Martinez wrote:
>
>> Hi all,
>>
>> I have setup the following rules in a centos6 gateway:
>> [ugly iptables -L]
> *Use* iptables-save and provide a *full* ruleset.
>
>> All works ok, except when I try to restrict one host to go out via
>> external interface. My problem is with the following rule:
>>
>>    0     0 ACCEPT     all  --  *      *       172.24.50.3
>> 0.0.0.0/0           state NEW
>>
>> If I try to restrict destination, doesn't works. For example using this rule:
>>
>> iptables -A FORWARD -s 172.24.50.3 -d 1.1.1.0/24 -m state --state NEW -j ACCEPT
>>
>> only works if I do:
>>
>> iptables -A FORWARD -s 172.24.50.3 -m state --state NEW -j ACCEPT
>>
>> then, what am I doing wrong??
> --
> To unsubscribe from this list: send the line "unsubscribe netfilter" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Problems with a forward rule

[C. L. Martinez]

[-- Attachment #1: Type: text/plain, Size: 544 bytes --]

On Sat, May 12, 2012 at 10:53 PM, Tom van Leeuwen
<tom.van.leeuwen@saasplaza.com> wrote:
> Indeed do iptables-save for the complete ruleset and tell us what you want
> and expect.
>
>
> On 12-5-2012 17:47, Jan Engelhardt wrote:
>>
>> On Friday 2012-05-11 17:04, C. L. Martinez wrote:
>>
>>> Hi all,
>>>
>>> I have setup the following rules in a centos6 gateway:
>>> [ugly iptables -L]
>>
>> *Use* iptables-save and provide a *full* ruleset.
>>

Ok, here they are. I want to allow connections from host 172.24.50.3
to one specific network only.

[-- Attachment #2: myiptables --]
[-- Type: application/octet-stream, Size: 2903 bytes --]

# Generated by iptables-save v1.4.7 on Mon May 14 07:37:11 2012
*nat
:PREROUTING ACCEPT [398:17466]
:POSTROUTING ACCEPT [52:3232]
:OUTPUT ACCEPT [52:3232]
-A PREROUTING -i prodif -p tcp -m tcp --dport 2222 -j DNAT --to-destination 172.24.50.2:22 
-A PREROUTING -i prodif -p tcp -m tcp --dport 8081 -j DNAT --to-destination 172.24.50.3:8081 
-A PREROUTING -i prodif -p tcp -m tcp --dport 8444 -j DNAT --to-destination 172.24.50.3:8444 
-A PREROUTING -i prodif -p tcp -m tcp --dport 5555 -j DNAT --to-destination 172.24.50.3:3389 
-A POSTROUTING -s 172.24.50.2/32 -o prodif -j MASQUERADE 
-A POSTROUTING -s 172.24.50.3/32 -o prodif -j MASQUERADE 
COMMIT
# Completed on Mon May 14 07:37:11 2012
# Generated by iptables-save v1.4.7 on Mon May 14 07:37:11 2012
*filter
:INPUT DROP [380:16172]
:FORWARD DROP [2:80]
:OUTPUT DROP [0:0]
:BADFLAGS - [0:0]
:SSH - [0:0]
:TCPFLAGS - [0:0]
-A INPUT -p tcp -j TCPFLAGS 
-A INPUT ! -s 172.24.50.0/28 -i siemif -j LOG --log-prefix "IPT SPOOFED packet: " 
-A INPUT ! -s 172.24.50.0/28 -i siemif -j DROP 
-A INPUT -i lo -j ACCEPT 
-A INPUT -s 224.0.0.0/4 -j DROP 
-A INPUT -d 224.0.0.0/4 -j DROP 
-A INPUT -s 240.0.0.0/5 -j DROP 
-A INPUT -d 10.196.129.255/32 -j DROP 
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT 
-A INPUT -p icmp -m state --state NEW -m icmp --icmp-type 8 -m limit --limit 1/sec --limit-burst 1 -j ACCEPT 
-A INPUT -p tcp -m tcp --dport 22 -m state --state NEW -j SSH 
-A INPUT -j LOG --log-prefix "IPT INPUT packet died: " 
-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: " 
-A OUTPUT -p tcp -j TCPFLAGS 
-A OUTPUT -o lo -j ACCEPT 
-A OUTPUT -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT 
-A OUTPUT -j LOG --log-prefix "IPT OUTPUT packet died: " 
-A BADFLAGS -j LOG --log-prefix "IPT TCPFLAGS: " 
-A BADFLAGS -j DROP 
-A SSH -m limit --limit 3/min --limit-burst 1 -j ACCEPT 
-A SSH -j LOG --log-prefix "IPT SSH connection too fast: " 
-A SSH -j DROP 
-A TCPFLAGS -p tcp -m state --state INVALID -j LOG --log-prefix "IPT INVALID: " 
-A TCPFLAGS -p tcp -m state --state INVALID -j DROP 
-A TCPFLAGS -p tcp -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -m state --state NEW -j BADFLAGS 
-A TCPFLAGS -p tcp -m tcp --tcp-flags SYN,ACK SYN,ACK -m state --state NEW -j REJECT --reject-with tcp-reset 
-A TCPFLAGS -p tcp -m tcp --tcp-flags FIN,ACK FIN -j BADFLAGS 
-A TCPFLAGS -p tcp -m tcp --tcp-flags PSH,ACK PSH -j BADFLAGS 
-A TCPFLAGS -p tcp -m tcp --tcp-flags ACK,URG URG -j BADFLAGS 
-A TCPFLAGS -p tcp -m tcp --tcp-flags FIN,RST FIN,RST -j BADFLAGS 
-A TCPFLAGS -p tcp -m tcp --tcp-flags FIN,SYN FIN,SYN -j BADFLAGS 
-A TCPFLAGS -p tcp -m tcp --tcp-flags SYN,RST SYN,RST -j BADFLAGS 
-A TCPFLAGS -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG NONE -j BADFLAGS 
COMMIT
# Completed on Mon May 14 07:37:11 2012

Re: Problems with a forward rule

[Tom van Leeuwen]

Alright,
Judging your ruleset the only relevant lines for your host 172.24.50.3 
would be:

:FORWARD DROP [2:80]
-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: "

And you said that restricting destination does not work. Your rule:
iptables -A FORWARD -s 172.24.50.3 -d 1.1.1.0/24 -m state --state NEW -j 
ACCEPT

You say it does not work. If that is the case, your packets are logged 
and dropped.
Could you paste the log entries for your host 172.24.50.3?

On 05/14/2012 07:45 AM, C. L. Martinez wrote:
> On Sat, May 12, 2012 at 10:53 PM, Tom van Leeuwen
> <tom.van.leeuwen@saasplaza.com>  wrote:
>> Indeed do iptables-save for the complete ruleset and tell us what you want
>> and expect.
>>
>>
>> On 12-5-2012 17:47, Jan Engelhardt wrote:
>>> On Friday 2012-05-11 17:04, C. L. Martinez wrote:
>>>
>>>> Hi all,
>>>>
>>>> I have setup the following rules in a centos6 gateway:
>>>> [ugly iptables -L]
>>> *Use* iptables-save and provide a *full* ruleset.
>>>
> Ok, here they are. I want to allow connections from host 172.24.50.3
> to one specific network only.

Re: Problems with a forward rule

[C. L. Martinez]

On Mon, May 14, 2012 at 8:33 AM, Tom van Leeuwen
<tom.van.leeuwen@saasplaza.com> wrote:
> Alright,
> Judging your ruleset the only relevant lines for your host 172.24.50.3 would
> be:
>
> :FORWARD DROP [2:80]
> -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: "
>
> And you said that restricting destination does not work. Your rule:
>
> iptables -A FORWARD -s 172.24.50.3 -d 1.1.1.0/24 -m state --state NEW -j
> ACCEPT
>
> You say it does not work. If that is the case, your packets are logged and
> dropped.
> Could you paste the log entries for your host 172.24.50.3?
>
>

Nothing, no drops ... But connections died by timeout ...

Re: Problems with a forward rule

[Tom van Leeuwen]

So, when you do a ping from your host 172.24.50.3 to 1.1.1.x you will 
probably see the counter increase for your rule (with restricted 
destination).
Do "iptables -vnL FORWARD" to check.

That rule is not the problem.

What traffic are you sending that times out?
source ip, source port, destination ip, dest port, protocol?

Your forward and postrouting rules look fine and should work

Regards,
Tom

On 05/14/2012 08:40 AM, C. L. Martinez wrote:
> On Mon, May 14, 2012 at 8:33 AM, Tom van Leeuwen
> <tom.van.leeuwen@saasplaza.com>  wrote:
>> Alright,
>> Judging your ruleset the only relevant lines for your host 172.24.50.3 would
>> be:
>>
>> :FORWARD DROP [2:80]
>> -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: "
>>
>> And you said that restricting destination does not work. Your rule:
>>
>> iptables -A FORWARD -s 172.24.50.3 -d 1.1.1.0/24 -m state --state NEW -j
>> ACCEPT
>>
>> You say it does not work. If that is the case, your packets are logged and
>> dropped.
>> Could you paste the log entries for your host 172.24.50.3?
>>
>>
> Nothing, no drops ... But connections died by timeout ...
> --
> To unsubscribe from this list: send the line "unsubscribe netfilter" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Problems with a forward rule

[C. L. Martinez]

On Mon, May 14, 2012 at 9:03 AM, Tom van Leeuwen
<tom.van.leeuwen@saasplaza.com> wrote:
> So, when you do a ping from your host 172.24.50.3 to 1.1.1.x you will
> probably see the counter increase for your rule (with restricted
> destination).
> Do "iptables -vnL FORWARD" to check.
>
> That rule is not the problem.
>
> What traffic are you sending that times out?
> source ip, source port, destination ip, dest port, protocol?
>
> Your forward and postrouting rules look fine and should work
>
> Regards,
> Tom

My principal problems are with http, https and ssh. For example with a
https connection:

Chain FORWARD (policy DROP 48 packets, 2432 bytes)
 pkts bytes target     prot opt in     out     source
destination
 4628 1901K ACCEPT     all  --  *      *       0.0.0.0/0
0.0.0.0/0           state RELATED,ESTABLISHED
   12   746 ACCEPT     all  --  *      *       172.24.50.3
10.196.0.0/16       state NEW
   42  2184 ACCEPT     tcp  --  *      *       172.24.50.3
195.76.69.66        tcp multiport dports 80,443 state NEW
    1    52 ACCEPT     tcp  --  *      *       172.24.50.3
195.76.69.69        tcp dpt:443 state NEW
   48  2432 LOG        all  --  *      *       0.0.0.0/0
0.0.0.0/0           LOG flags 0 level 4 prefix `IPT FORWARD packet
died: '

First packets goes well, but after few seconds all goes to "IPT
FORWARD .." chain ...

Re: Problems with a forward rule

[Tom van Leeuwen]

On 05/14/2012 09:06 AM, C. L. Martinez wrote:
> On Mon, May 14, 2012 at 9:03 AM, Tom van Leeuwen
> <tom.van.leeuwen@saasplaza.com>  wrote:
>> So, when you do a ping from your host 172.24.50.3 to 1.1.1.x you will
>> probably see the counter increase for your rule (with restricted
>> destination).
>> Do "iptables -vnL FORWARD" to check.
>>
>> That rule is not the problem.
>>
>> What traffic are you sending that times out?
>> source ip, source port, destination ip, dest port, protocol?
>>
>> Your forward and postrouting rules look fine and should work
>>
>> Regards,
>> Tom
> My principal problems are with http, https and ssh. For example with a
> https connection:
>
> Chain FORWARD (policy DROP 48 packets, 2432 bytes)
>   pkts bytes target     prot opt in     out     source
> destination
>   4628 1901K ACCEPT     all  --  *      *       0.0.0.0/0
> 0.0.0.0/0           state RELATED,ESTABLISHED
>     12   746 ACCEPT     all  --  *      *       172.24.50.3
> 10.196.0.0/16       state NEW
>     42  2184 ACCEPT     tcp  --  *      *       172.24.50.3
> 195.76.69.66        tcp multiport dports 80,443 state NEW
>      1    52 ACCEPT     tcp  --  *      *       172.24.50.3
> 195.76.69.69        tcp dpt:443 state NEW
>     48  2432 LOG        all  --  *      *       0.0.0.0/0
> 0.0.0.0/0           LOG flags 0 level 4 prefix `IPT FORWARD packet
> died: '
>
> First packets goes well, but after few seconds all goes to "IPT
> FORWARD .." chain ...
So stuff is logged! Please show what is logged, cause that is the key!

Re: Problems with a forward rule

[Neal Murphy]

On Monday 14 May 2012 01:45:21 you wrote:

> Ok, here they are. I want to allow connections from host 172.24.50.3
> to one specific network only.

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. This makes the first rule moot, because there
     will be no established conns from other hosts. NEW packets are dropped,
     thus there cannot be any established conns for a related connection to
     be created.
But I suspect you already know your rules don't work right. :)

I only looked at the rules in table 'filter'.

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
-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: "
-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
-A FORWARD -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT

Rule order is important. Thus,
  1. Packets from the host to that LAN that are for (1) a new or a
     new/related conn, and (2) all packets for established conns,
     are allowed.
  2. Packets to the host from that LAN for (1) a new/related conn
     or (2) for established conns are allowed.
  3. All other packets forwarded to or from that host are dropped.
  4. All other forwarded packets are allowed.
  5. The FORWARD chain's DROP policy is never executed. See #5 (above).
  6. The host is still allowed to access all other hosts on its LAN; the
     router has no control over that.
Since no protocols are specified, ICMP will also be allowed.

Remember that:
  - Without ICMP, your internetwork will not function.
  - A 'conn' is a relation between two socket endpoints, be it TCP, UDP
    or another protocol.
  - NEW refers to the *first* packet of a new conn.
  - RELATED refers to the *first* packet of a new, related conn.
  - ESTABLISHED refers to all other packets of established conns,
    whether they started as NEW or as RELATED.
  - the RELATED state is set by a conntrack helper (FTP, etc.) that
    snoops and detects when one end of an established conn is attempting
    to open a new conn (such as FTP's data channel).
  - You may want to allow DNS (UDP port 53) to pass (if needed), depending
    on where your DNS server or 'proxy' is.
  - You may want to add rules to INPUT and OUTPUT to prevent that host
    from accessing the router itself, if desired.

Re: Problems with a forward rule

[C. L. Martinez]

On Mon, May 14, 2012 at 9:26 AM, Neal Murphy <neal.p.murphy@alum.wpi.edu> wrote:
> On Monday 14 May 2012 01:45:21 you wrote:
>
>> Ok, here they are. I want to allow connections from host 172.24.50.3
>> to one specific network only.
>
> 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. This makes the first rule moot, because there
>     will be no established conns from other hosts. NEW packets are dropped,
>     thus there cannot be any established conns for a related connection to
>     be created.
> But I suspect you already know your rules don't work right. :)
>
> I only looked at the rules in table 'filter'.

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??:

> -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

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.


> Rule order is important. Thus,
>  1. Packets from the host to that LAN that are for (1) a new or a
>     new/related conn, and (2) all packets for established conns,
>     are allowed.
>  2. Packets to the host from that LAN for (1) a new/related conn
>     or (2) for established conns are allowed.
>  3. All other packets forwarded to or from that host are dropped.
>  4. All other forwarded packets are allowed.
>  5. The FORWARD chain's DROP policy is never executed. See #5 (above).
>  6. The host is still allowed to access all other hosts on its LAN; the
>     router has no control over that.
> Since no protocols are specified, ICMP will also be allowed.
>
> Remember that:
>  - Without ICMP, your internetwork will not function.

Sorry?? Why?? I administer a lot of chkps and bds fws and ALL had icmp
denied by default (with some exceptions), and it works ok ...

>  - A 'conn' is a relation between two socket endpoints, be it TCP, UDP
>    or another protocol.
>  - NEW refers to the *first* packet of a new conn.
>  - RELATED refers to the *first* packet of a new, related conn.
>  - ESTABLISHED refers to all other packets of established conns,
>    whether they started as NEW or as RELATED.
>  - the RELATED state is set by a conntrack helper (FTP, etc.) that
>    snoops and detects when one end of an established conn is attempting
>    to open a new conn (such as FTP's data channel).
>  - You may want to allow DNS (UDP port 53) to pass (if needed), depending
>    on where your DNS server or 'proxy' is.
>  - You may want to add rules to INPUT and OUTPUT to prevent that host
>    from accessing the router itself, if desired.

But according to my default policy, all that it is not allowed is
denied ... Your answers are redundant with my default policy ...

Re: Problems with a forward rule

[carlopmart]

On 05/14/2012 09:24 AM, Tom van Leeuwen wrote:
> On 05/14/2012 09:06 AM, C. L. Martinez wrote:
>> On Mon, May 14, 2012 at 9:03 AM, Tom van Leeuwen
>> <tom.van.leeuwen@saasplaza.com> wrote:
>>> So, when you do a ping from your host 172.24.50.3 to 1.1.1.x you will
>>> probably see the counter increase for your rule (with restricted
>>> destination).
>>> Do "iptables -vnL FORWARD" to check.
>>>
>>> That rule is not the problem.
>>>
>>> What traffic are you sending that times out?
>>> source ip, source port, destination ip, dest port, protocol?
>>>
>>> Your forward and postrouting rules look fine and should work
>>>
>>> Regards,
>>> Tom
>> My principal problems are with http, https and ssh. For example with a
>> https connection:
>>
>> Chain FORWARD (policy DROP 48 packets, 2432 bytes)
>> pkts bytes target prot opt in out source
>> destination
>> 4628 1901K ACCEPT all -- * * 0.0.0.0/0
>> 0.0.0.0/0 state RELATED,ESTABLISHED
>> 12 746 ACCEPT all -- * * 172.24.50.3
>> 10.196.0.0/16 state NEW
>> 42 2184 ACCEPT tcp -- * * 172.24.50.3
>> 195.76.69.66 tcp multiport dports 80,443 state NEW
>> 1 52 ACCEPT tcp -- * * 172.24.50.3
>> 195.76.69.69 tcp dpt:443 state NEW
>> 48 2432 LOG all -- * * 0.0.0.0/0
>> 0.0.0.0/0 LOG flags 0 level 4 prefix `IPT FORWARD packet
>> died: '
>>
>> First packets goes well, but after few seconds all goes to "IPT
>> FORWARD .." chain ...
> So stuff is logged! Please show what is logged, cause that is the key!

Ok, I have found the problem. Exists an intermediate fw blocking this 
type of traffic ...

Sorry for the noise.

  .. and many thanks for your help.

-- 
CL Martinez
carlopmart {at} gmail {d0t} com

Re: Problems with a forward rule

[Neal Murphy]

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.

Re: Problems with a forward rule

[carlopmart]

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

Re: Problems with a forward rule

[Neal Murphy]

On Monday 14 May 2012 15:35:16 carlopmart wrote:
> 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) ...

Allow me to restate the rules in a slightly different format.

At least four rules are required if you wish to absolutely restrict a host to 
communicating with some other LAN. And these four rules must be the first 
rules in the FORWARD chain in order to be guaranteed to work regardless of 
other rules you may later add after them in the chain.

Definitions:
'the host': the host you wish to restrict.
'the LAN': the only LAN 'the host' is allowed to access. It is specified
    symbolically as you did not specic an address for it.
'conn': an established TCP/IP 'relation' between two hosts, whether it is
    using a connection-oriented protocol like TCP or SCTP or a
    connectionless protocol.
'NEW': the first packet of a new, not-yet-established conn.
'RELATED': the first packet of a new, not-yet-established conn that a
    helper module has determined is related to an existing conn between
    those two hosts.
'ESTABLISHED': a packet belonging to a conn that has seen traffic in both
    directions. Once established, there is no way to determine if a conn
    started out as NEW or RELATED (well, without resorting to CONNMARKs).

The first two and last two rules below together guarantee that 'the host' may 
communicate ONLY with nodes on 'the LAN', regardless of any rules you may add 
after. Do note that rules you add *before* these six rules may affect 'the 
host' if they are not written with great care.

--------------
# The first two rules explicitly allow traffic between 'the host' and
#   'the LAN'. You must explicitly allow packets travelling in each
#   direction. Once a packet is ACCEPTed, no further rules are processed.

# Allow 'the host' to access 'the LAN' using NEW and RELATED initial
#   packets and packets in ESTABLISHED conns
iptables -A FORWARD -s 172.24.50.3/32 -d a.b.c.d/netmask \
  -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT

# Allow nodes on 'the LAN' to access 'the host' using RELATED initial
#   packets and packets in ESTABLISHED conns
iptables -A FORWARD -s a.b.c.d/netmask -d 172.24.50.3/32 \
  -m state --state RELATED,ESTABLISHED -j ACCEPT


# The next two rules log traffic from 'the host' to anywhere else
#   and from anywhere else to 'the host'. Rule processing continues
#   after the packet has been LOGged.

# Log packets from 'the host' to anywhere else
iptables -A FORWARD -s 172.24.50.3/32 -j LOG \
  --log-prefix "FORWARD found packet from 172.24.50.3 to somewhere else: "
iptables -A FORWARD -d 172.24.50.3/32 -j LOG \
  --log-prefix "FORWARD found packet to 172.24.50.3 from somewhere else: "


# These last two rules explicitly drop traffic between 'the host' and
#   anywhere else. They preclude unintended consequences of new rules
#   you may add to the end of the chain in the future.
iptables -A FORWARD -s 172.24.50.3/32 -j DROP
iptables -A FORWARD -d 172.24.50.3/32 -j DROP
--------------

The first two rules allow traffic between 'the host' and 'the LAN' as you 
require. 'The host' may access any node on 'the LAN' at any time using any IP 
protocol. Nodes on 'the LAN' may send all return traffic and may open RELATED 
conns as detected by a netfilter helper module (such as FTP's DATA channel) 
but may not otherwise initiate unsolicited conns to 'the host'.

The second two rules are optional if you don't want to track attempts by 'the 
host' to access other nodes.

The last two rules are optional if you will never add more rules to the end of 
the chain because the chain's policy, DROP, will drop those packets. If you 
plan to add more rules to the end of the chain, I strongly suggest you use 
these last two rules to ensure that your added rules don't interfere.


Again, the two ACCEPT rules and the two DROP rules together guarantee that 
'the host' may communicate only with nodes on 'the LAN' even if you add more 
rules to the end of the chain. But remember that carelessly written rules you 
insert *before* these four rules can change the restrictions you've placed on 
'the host' and negate that guarantee.