* Problems with a forward rule
@ 2012-05-11 15:04 C. L. Martinez
2012-05-12 15:47 ` Jan Engelhardt
0 siblings, 1 reply; 15+ messages in thread
From: C. L. Martinez @ 2012-05-11 15:04 UTC (permalink / raw)
To: netfilter
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??
^ permalink raw reply [flat|nested] 15+ messages in thread* Re: Problems with a forward rule 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 0 siblings, 1 reply; 15+ messages in thread From: Jan Engelhardt @ 2012-05-12 15:47 UTC (permalink / raw) To: C. L. Martinez; +Cc: netfilter 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?? ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Problems with a forward rule 2012-05-12 15:47 ` Jan Engelhardt @ 2012-05-12 20:53 ` Tom van Leeuwen 2012-05-14 5:45 ` C. L. Martinez 0 siblings, 1 reply; 15+ messages in thread From: Tom van Leeuwen @ 2012-05-12 20:53 UTC (permalink / raw) To: Jan Engelhardt; +Cc: C. L. Martinez, netfilter 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Problems with a forward rule 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 7:26 ` Neal Murphy 0 siblings, 2 replies; 15+ messages in thread From: C. L. Martinez @ 2012-05-14 5:45 UTC (permalink / raw) To: netfilter [-- 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Problems with a forward rule 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:26 ` Neal Murphy 1 sibling, 1 reply; 15+ messages in thread From: Tom van Leeuwen @ 2012-05-14 6:33 UTC (permalink / raw) To: C. L. Martinez; +Cc: netfilter 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. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Problems with a forward rule 2012-05-14 6:33 ` Tom van Leeuwen @ 2012-05-14 6:40 ` C. L. Martinez 2012-05-14 7:03 ` Tom van Leeuwen 0 siblings, 1 reply; 15+ messages in thread From: C. L. Martinez @ 2012-05-14 6:40 UTC (permalink / raw) To: netfilter 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 ... ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Problems with a forward rule 2012-05-14 6:40 ` C. L. Martinez @ 2012-05-14 7:03 ` Tom van Leeuwen 2012-05-14 7:06 ` C. L. Martinez 0 siblings, 1 reply; 15+ messages in thread From: Tom van Leeuwen @ 2012-05-14 7:03 UTC (permalink / raw) To: C. L. Martinez; +Cc: netfilter 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Problems with a forward rule 2012-05-14 7:03 ` Tom van Leeuwen @ 2012-05-14 7:06 ` C. L. Martinez 2012-05-14 7:24 ` Tom van Leeuwen 0 siblings, 1 reply; 15+ messages in thread From: C. L. Martinez @ 2012-05-14 7:06 UTC (permalink / raw) To: Tom van Leeuwen; +Cc: netfilter 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 ... ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Problems with a forward rule 2012-05-14 7:06 ` C. L. Martinez @ 2012-05-14 7:24 ` Tom van Leeuwen 2012-05-14 16:47 ` carlopmart 0 siblings, 1 reply; 15+ messages in thread From: Tom van Leeuwen @ 2012-05-14 7:24 UTC (permalink / raw) To: C. L. Martinez; +Cc: netfilter 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! ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Problems with a forward rule 2012-05-14 7:24 ` Tom van Leeuwen @ 2012-05-14 16:47 ` carlopmart 0 siblings, 0 replies; 15+ messages in thread From: carlopmart @ 2012-05-14 16:47 UTC (permalink / raw) To: netfilter 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Problems with a forward rule 2012-05-14 5:45 ` C. L. Martinez 2012-05-14 6:33 ` Tom van Leeuwen @ 2012-05-14 7:26 ` Neal Murphy 2012-05-14 8:18 ` C. L. Martinez 1 sibling, 1 reply; 15+ messages in thread From: Neal Murphy @ 2012-05-14 7:26 UTC (permalink / raw) To: netfilter 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. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Problems with a forward rule 2012-05-14 7:26 ` Neal Murphy @ 2012-05-14 8:18 ` C. L. Martinez 2012-05-14 17:55 ` Neal Murphy 0 siblings, 1 reply; 15+ messages in thread From: C. L. Martinez @ 2012-05-14 8:18 UTC (permalink / raw) To: netfilter 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 ... ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Problems with a forward rule 2012-05-14 8:18 ` C. L. Martinez @ 2012-05-14 17:55 ` Neal Murphy 2012-05-14 19:35 ` carlopmart 0 siblings, 1 reply; 15+ messages in thread From: Neal Murphy @ 2012-05-14 17:55 UTC (permalink / raw) To: netfilter 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. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Problems with a forward rule 2012-05-14 17:55 ` Neal Murphy @ 2012-05-14 19:35 ` carlopmart 2012-05-14 21:12 ` Neal Murphy 0 siblings, 1 reply; 15+ messages in thread From: carlopmart @ 2012-05-14 19:35 UTC (permalink / raw) To: netfilter 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Problems with a forward rule 2012-05-14 19:35 ` carlopmart @ 2012-05-14 21:12 ` Neal Murphy 0 siblings, 0 replies; 15+ messages in thread From: Neal Murphy @ 2012-05-14 21:12 UTC (permalink / raw) To: netfilter 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. ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2012-05-14 21:12 UTC | newest] Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 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 2012-05-14 21:12 ` Neal Murphy
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.