Re: strange behaviour

Re: strange behaviour

[angico]

GREAT, GUYS! IT WORKED!!!!!! I THANK YOU VERY MUCH for the help!
angico.


----- Original Message ----
From: Cedric Blancher <blancher@cartel-securite.fr>
To: angico <angico@yahoo.com>
Cc: netfilter@lists.netfilter.org
Sent: Monday, February 26, 2007 1:07:55 PM
Subject: Re: strange behaviour

Le lundi 26 février 2007 à 07:35 -0800, angico a écrit :
> hi, buddys. thanks for your attention, but...
> nothing works, yet. and this option "--clamp-mss-to-pmtu" just send me an error: "iptables: Invalid argument". 
> angico.

My mistake.
As Pascal stated, you have to specify a "-p tcp --tcp-flags SYN,RST SYN"
as well, as TCPMSS clamping only works on TCP packets with SYN flag set:

        iptables -t mangle -A FORWARD -o ppp0 -p tcp \
           --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

It should work better.


-- 
http://sid.rstack.org/
PGP KeyID: 157E98EE FingerPrint: FA62226DA9E72FA8AECAA240008B480E157E98EE
>> Hi! I'm your friendly neighbourhood signature virus.
>> Copy me to your signature file and help me spread!





 
____________________________________________________________________________________
Have a burning question?  
Go to www.Answers.yahoo.com and get answers from real people who know.

Re: strange behaviour

[Martijn Lievaart]

angico wrote:
> GREAT, GUYS! IT WORKED!!!!!! I THANK YOU VERY MUCH for the help!
> angico.
>   

Well the problem is in your rules in the first place, I cannot beleive 
no one caught this.

Let's reiterate your rules:

1    ACCEPT     all  --  192.168.0.0/24       boitata.jlm         
2    ACCEPT     tcp  --  anywhere             anywhere            state RELATED,ESTABLISHED 
3    ACCEPT     udp  --  anywhere             anywhere            udp spt:domain 
4    ACCEPT     udp  --  anywhere             anywhere            udp spt:http state NEW,RELATED,ESTABLISHED 
5    ACCEPT     icmp --  anywhere             anywhere            icmp echo-reply 
6    ACCEPT     icmp --  anywhere             anywhere            icmp echo-request 

(by the way, next time post the output of iptables-save, much better readable)

In rule 2, you allow all packets that are tcp and belong to an established session or related session. This means you DON'T allow the ICMP fragmentation needed messages in (dunno if they are deemed related or established, I think the latter). This is where you shoot yourself in the foot. This is why you SEEM to need the clamp-mss option. You don't need that option, your rules are faulty.

Nothing to do with your problem, but let's have a quick look at your other rules:

1) I prefer to match by interface, but YMMV.
3) Only sensible if you run a local nameserver.
4) What does this do?
6) This rule would not be needed had you allowed all RELATED and ESTABLISHED packets in.

I won't go into your OUTPUT rules, they should work together with your input rules.

What you probably want is something like this:

# Default is to drop
-P INPUT DROP
# Let in anything established or related
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
# anything not new is dropped right away
-A INPUT -m state ! --state NEW -j DROP
# pings are allowed
-A INPUT -p icmp --type echo -j ACCEPT
# Input from the local network is allowed
-A INPUT -i $LOCALIF -j ACCEPT
# anything else is logged and dropped by the policy
-A INPUT -j LOG

# We allow anything from the box itseld to the outside
-P OUTPUT ACCEPT

(Add approptiate logging rules for safety and debugging)


I think you would do well to read some tutorials on writing IP tables rules.

HTH,
M4

Re: strange behaviour

[Cedric Blancher]

Le lundi 26 février 2007 à 18:43 +0100, Pascal Hambourg a écrit :
> Actually "clamp" means "decrease if bigger", the MSS is clamped only 
> when it is bigger than PMTU - 40. So it won't break anything. It will 
> just have no effect.

Right, I didn't read the code far enough to notice that:

if (tcpmssinfo->mss == IPT_TCPMSS_CLAMP_PMTU && oldmss <= newmss)
	return IPT_CONTINUE;

> What about :
> iptables -t mangle -A FORWARD -o eth1 -p tcp --tcp-flags SYN,RST SYN \
>    -m tcpmss --mss 1453: -j TCPMSS --set-mss 1452

Makes sense.


-- 
http://sid.rstack.org/
PGP KeyID: 157E98EE FingerPrint: FA62226DA9E72FA8AECAA240008B480E157E98EE
>> Hi! I'm your friendly neighbourhood signature virus.
>> Copy me to your signature file and help me spread!

Re: strange behaviour

[Pascal Hambourg]

Cedric Blancher a écrit :
> Le lundi 26 février 2007 à 16:34 +0100, Pascal Hambourg a écrit :
> 
>>Also, wouldn't it be useful to do it in both directions to avoid 
>>fragmentation if host (b) does not use path MTU discovery ?
> 
> No, because you don't want to clamp inbound traffic to your MTU, but to
> your peer MTU.

I want to clamp both, so TCP segments length does not exceed 1452 in 
either direction.

> It's your peer job to advertise correctly its own MSS.

Yes, but the MSS advertised by the peer may not be the best one : if it 
exceeds the PPP link MTU - 40 (typically 1492 - 40 = 1452) and host 
(b)'s MTU (typically 1500) exceeds the PPP link MTU and host (b) does 
not use path MTU discovery, then host (b) may send TCP datagrams bigger 
than the PPP link MTU that the server/router would need to fragment. So 
IMO it would be better that host (b) always see peers' MSS not bigger 
than the PPP link MTU - 40.

> Now, if you look more closely, you'll see you clamp MSS against
> destination PMTU. As PMTU from your firewall to your server  is most
> probably ethernet MTU, you will clamp it to 1500.

You mean "from the server/router to host (b)" ?
Yes, you have a point. It's useless.

> So, if your peer
> advertise 1452 as MSS, you will overwrite it to a higher value of 1460
> and break everything.

Actually "clamp" means "decrease if bigger", the MSS is clamped only 
when it is bigger than PMTU - 40. So it won't break anything. It will 
just have no effect.

What about :
iptables -t mangle -A FORWARD -o eth1 -p tcp --tcp-flags SYN,RST SYN \
   -m tcpmss --mss 1453: -j TCPMSS --set-mss 1452

Re: strange behaviour

[Cedric Blancher]

Le lundi 26 février 2007 à 16:34 +0100, Pascal Hambourg a écrit :
> TCPMSS works only on TCP packets with the SYN flag set, so the options 
> "-p tcp --tcp-flags SYN,RST SYN" are required.

Indeed.

> Also, wouldn't it be useful to do it in both directions to avoid 
> fragmentation if host (b) does not use path MTU discovery ?

No, because you don't want to clamp inbound traffic to your MTU, but to
your peer MTU. It's your peer job to advertise correctly its own MSS.

Now, if you look more closely, you'll see you clamp MSS against
destination PMTU. As PMTU from your firewall to your server is most
probably ethernet MTU, you will clamp it to 1500. So, if your peer
advertise 1452 as MSS, you will overwrite it to a higher value of 1460
and break everything.


-- 
http://sid.rstack.org/
PGP KeyID: 157E98EE FingerPrint: FA62226DA9E72FA8AECAA240008B480E157E98EE
>> Hi! I'm your friendly neighbourhood signature virus.
>> Copy me to your signature file and help me spread!

Re: strange behaviour

[Cedric Blancher]

Le lundi 26 février 2007 à 07:35 -0800, angico a écrit :
> hi, buddys. thanks for your attention, but...
> nothing works, yet. and this option "--clamp-mss-to-pmtu" just send me an error: "iptables: Invalid argument". 
> angico.

My mistake.
As Pascal stated, you have to specify a "-p tcp --tcp-flags SYN,RST SYN"
as well, as TCPMSS clamping only works on TCP packets with SYN flag set:

        iptables -t mangle -A FORWARD -o ppp0 -p tcp \
           --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

It should work better.


-- 
http://sid.rstack.org/
PGP KeyID: 157E98EE FingerPrint: FA62226DA9E72FA8AECAA240008B480E157E98EE
>> Hi! I'm your friendly neighbourhood signature virus.
>> Copy me to your signature file and help me spread!

Re: strange behaviour

[angico]

hi, buddys. thanks for your attention, but...
nothing works, yet. and this option "--clamp-mss-to-pmtu" just send me an error: "iptables: Invalid argument". 
angico.

----- Original Message ----
From: Cedric Blancher <blancher@cartel-securite.fr>
To: Pascal Hambourg <pascal.mail@plouf.fr.eu.org>
Cc: netfilter@lists.netfilter.org
Sent: Monday, February 26, 2007 12:09:25 PM
Subject: Re: strange behaviour

Le lundi 26 février 2007 à 15:53 +0100, Pascal Hambourg a écrit :
> I doubt this is a firewall issue. It may be an MTU issue.

However, Netfilter can help:

   iptables -t mangle -A FORWARD -o ppp0 -j TCPMSS --clamp-mss-to-pmtu


-- 
http://sid.rstack.org/
PGP KeyID: 157E98EE FingerPrint: FA62226DA9E72FA8AECAA240008B480E157E98EE
>> Hi! I'm your friendly neighbourhood signature virus.
>> Copy me to your signature file and help me spread!






 
____________________________________________________________________________________
Be a PS3 game guru.
Get your game face on with the latest PS3 news and previews at Yahoo! Games.
http://videogames.yahoo.com/platform?platform=120121

Re: strange behaviour

[Pascal Hambourg]

Cedric Blancher a écrit :
> 
>    iptables -t mangle -A FORWARD -o ppp0 -j TCPMSS --clamp-mss-to-pmtu

TCPMSS works only on TCP packets with the SYN flag set, so the options 
"-p tcp --tcp-flags SYN,RST SYN" are required.
Also, wouldn't it be useful to do it in both directions to avoid 
fragmentation if host (b) does not use path MTU discovery ?

Re: strange behaviour

[Cedric Blancher]

Le lundi 26 février 2007 à 15:53 +0100, Pascal Hambourg a écrit :
> I doubt this is a firewall issue. It may be an MTU issue.

However, Netfilter can help:

   iptables -t mangle -A FORWARD -o ppp0 -j TCPMSS --clamp-mss-to-pmtu


-- 
http://sid.rstack.org/
PGP KeyID: 157E98EE FingerPrint: FA62226DA9E72FA8AECAA240008B480E157E98EE
>> Hi! I'm your friendly neighbourhood signature virus.
>> Copy me to your signature file and help me spread!

Re: strange behaviour

[Pascal Hambourg]

Hello,

angico a écrit :
> i have a server (a) connected to the internet via eth0/ppp0 (adsl).

PPPoE ?

> another computer (b) is connected to this server thru eth1, and it 
> should reach the internet via the server which is its gateway. and so it 
> did!... up to a month ago.
> i think nothing's changed. all i did was a re-installing of my gentoo 
> based system on the server, due to problems on the hard-disk. but 
> firewall rules (iptables) remain the same. and the netted computer can't 
> reach the internet anymore! 
> things got exquisite because:
> - i ping any site on the internet from (b) and i can see their pongs.

Then it can reach the internet.

> - irc (msn) also works fine!

Then it can reach the internet.

> - google's pages load correctly!

Then it can reach the internet.

> and for my despair i can access <facilcotacao.com>, but can't access 
> <facilcotacao.com/autopecas>!!!!
> please, help me! what the hell is wrong with my firewall?

I doubt this is a firewall issue. It may be an MTU issue.
If pppd uses pppoe from rp-pppoe, does it have an option "-m 1452" or 
less for pppoe in the pty option ?
What happens if you decrease the MTU of computer (b) to 1492 or less ?

Re: strange behaviour

[Silvio Fonseca]

Hello Askar,

I believe he already has this rule:
"Chain POSTROUTING (policy ACCEPT)
num  target     prot opt source               destination
1    MASQUERADE  all  --  anywhere             anywhere"

Actually, he is able to access Internet (??)...

Angico,

Your problem doesn't seem to be related to IPTables since you can access the 
Internet just fine. If you can access "http://facilcotacao.com/" but can't 
access "http://facilcotacao.com/autopecas/", unless you are using layer7 
filtering, you problem is somewhere else. I tried to access the site and saw 
it redirects to "http://www.facilcotacao.com.br/autopecas/", I believe you 
should check for DNS resolution, etc.

Best Regards,

Silvio Fonseca

> angico, on 02/26/2007 05:45 PM [GMT+500], wrote :
> > hi, everybody!
> > i have a problem that you may help to solve, surely.
> > i have a server (a) connected to the internet via eth0/ppp0 (adsl).
> > another computer (b) is connected to this server thru eth1, and it should
> > reach the internet via the server which is its gateway. and so it did!...
> > up to a month ago. i think nothing's changed. all i did was a
> > re-installing of my gentoo based system on the server, due to problems on
> > the hard-disk. but firewall rules (iptables) remain the same. and the
> > netted computer can't reach the internet anymore! things got exquisite
> > because:
>
> Try this rule on  your gateway..
>
>
> iptables -A POSTROUTING -t nat -o ppp0 -j MASQUERADE
>
> Thanks

Re: strange behaviour

[Askar Ali]

angico, on 02/26/2007 05:45 PM [GMT+500], wrote :
> hi, everybody!
> i have a problem that you may help to solve, surely.
> i have a server (a) connected to the internet via eth0/ppp0 (adsl).
> another computer (b) is connected to this server thru eth1, and it should reach the internet via the server which is its gateway. and so it did!... up to a month ago.
> i think nothing's changed. all i did was a re-installing of my gentoo based system on the server, due to problems on the hard-disk. but firewall rules (iptables) remain the same. and the netted computer can't reach the internet anymore! 
> things got exquisite because:
>   
Try this rule on  your gateway..


iptables -A POSTROUTING -t nat -o ppp0 -j MASQUERADE

Thanks

strange behaviour

[angico]

hi, everybody!
i have a problem that you may help to solve, surely.
i have a server (a) connected to the internet via eth0/ppp0 (adsl).
another computer (b) is connected to this server thru eth1, and it should reach the internet via the server which is its gateway. and so it did!... up to a month ago.
i think nothing's changed. all i did was a re-installing of my gentoo based system on the server, due to problems on the hard-disk. but firewall rules (iptables) remain the same. and the netted computer can't reach the internet anymore! 
things got exquisite because:
- i ping any site on the internet from (b) and i can see their pongs.
- irc (msn) also works fine!
- google's pages load correctly!
and for my despair i can access <facilcotacao.com>, but can't access <facilcotacao.com/autopecas>!!!!
please, help me! what the hell is wrong with my firewall?
many thanks in advance,
angico.

table filter is:

Chain INPUT (policy DROP)
num  target     prot opt source               destination         
1    ACCEPT     all  --  192.168.0.0/24       boitata.jlm         
2    ACCEPT     tcp  --  anywhere             anywhere            state RELATED,ESTABLISHED 
3    ACCEPT     udp  --  anywhere             anywhere            udp spt:domain 
4    ACCEPT     udp  --  anywhere             anywhere            udp spt:http state NEW,RELATED,ESTABLISHED 
5    ACCEPT     icmp --  anywhere             anywhere            icmp echo-reply 
6    ACCEPT     icmp --  anywhere             anywhere            icmp echo-request 


Chain FORWARD (policy ACCEPT)
num  target     prot opt source               destination         
1    LOG        all  --  anywhere             anywhere            LOG level warning prefix `IPT-FWD: ' 
2    ACCEPT     all  --  anywhere             anywhere            

Chain OUTPUT (policy ACCEPT)
num  target     prot opt source               destination         
1    LOG        all  --  anywhere             anywhere            LOG level warning prefix `IPT-OUT: ' 
2    ACCEPT     all  --  boitata.jlm          192.168.0.0/24      



and table nat is:

Chain PREROUTING (policy ACCEPT)
num  target     prot opt source               destination         

Chain POSTROUTING (policy ACCEPT)
num  target     prot opt source               destination         
1    MASQUERADE  all  --  anywhere             anywhere            
2    MASQUERADE  all  --  anywhere             anywhere            

Chain OUTPUT (policy ACCEPT)
num  target     prot opt source               destination         





 
____________________________________________________________________________________
Get your own web address.  
Have a HUGE year through Yahoo! Small Business.
http://smallbusiness.yahoo.com/domains/?p=BESTDEAL

Strange behaviour

[Arindam Haldar]

hi all,

i noticed a peculiar behaviour as in the /var/log/syslog

Dec 10 09:24:58 ICG kernel: vs-500: unknown uniqueness 1073741824
Dec 10 09:24:58 ICG last message repeated 3 times

this happens when i start squid & then give iptables command for 
transparent proxy...

our is slackware 8.1, kernel 2.4.19 squid 2-5s1 & iptables 1-2s7a.
im not sure but is it a kernel related problem ?.. the number, shown in 
syslog (1073741824) is _ALWAYS_ the same...

any ideas or do you forsea any majour problem ?

thanking in advance ...
A.H