Some networking questions
 

Hello there,

When searching to resolv the pb listed in this thread http://www.linuxquestions.org/questi...hreadid=128167

and I have some basics (?) questions :
1. is it a problem that local IP address are something like : 192.168.0.x ? Is the 0 possible in a IP address ?

2. what is the MTU parameter showed with ifconfig -a ?

3. ppp0 has MTU=1492 and eth0 has MTU=1500. Must those values be the same ?

4. How to change the MTU value for an IP interface and how to make this change persistant ?

Thank's for all.

About http://www.linuxquestions.org/quest...threadid=128167
Do you make ping from broken windows machine to broken sites ?

>1. is it a problem that local IP address are something like : 192.168.0.x ?
No problem. Only check what address give you ADSL provider.(must not from 192.168.0.x)
>Is the 0 possible in a IP address ?
No. IP address of host can`not be 0.
>2. what is the MTU parameter showed with ifconfig -a ?
Maximum Transfer Unit . Maximum size of packet. (for ethernet 1500)
>3. ppp0 has MTU=1492 and eth0 has MTU=1500. Must those values be the same ?
No. You router must fragmented IP packet if he is more then 1492.
>4. How to change the MTU value for an IP interface and how to make this change persistant ?
Why you need for ?

Thank's for your answers,

But you says in 1. that there is no problem to have an IP like 192.168.0.1 and in 2. that it's not possible to have 0 in IP address. This seem's contradictoir to me. My question is : is an IP address like 192.168.0.1 legal or do I have to replace the 0 with something else ?

4. It was in case that both MTU (ppp0 and eth0) must be the same.

Do you have an idea for the problem listed in the thread : http://www.linuxquestions.org/quest...threadid=128167

Thank's for all

an address like 192.168.0.1 is legal, you just dont want to start an IP address with a 0 or end it with a 0. You also cannot use 255 for the IP b/c it is reserved

255 = broadcast, meaning that packets are sent to every host on the subnet.

Gates is right, 0 can be used as long as it is not the end of the host portion. Often times a subnet is referred to by including the 0 (ie, 192.168.0.0 would refer to the subnet, and 192.168.0.1 would be a host on that subnet, and 192.168.0.255 would be the broadcast address for the subnet).

slight

In post http://www.linuxquestions.org/quest...threadid=128167 you write about
you have mask 255.255.255.0. In this case you may use legally ip from 192.168.0.1 to 192.168.0.254.
O in thrid octet belong to network part of address and with mask 255.255.255.0 is absolutly legally too.

This is not necessarily so. But if you want - just read man ifconfig.

Do you make ping test from windows machines to Inernet urls ?

Yes all seems to be all right

Ok.
Try to sniffing traffic on inbound interface and adsl connection
In one window
tcpdump -vvv -i eth0(your local_net) host ip(one of windows box)
and other window
tcpdump -vvv -i ppp0(your adsl)
and from windows box check access to yahoo url.

What you see ? Can you give small dump ? (and result of ifconfig)

I don't have tcpdump installed. Where can I find it ?

OK I got it.
Sorry we will have to wait on monday to have people working. I cannot access this from home.

2 ideas while waiting for users ....
 

While waiting for monday I have two ideas :
1. can it be a masquerading problem ?

My Linux box has an constant IP and I've read some articles saying that with constant IP with hav to use SNAT and not MASQUERADING ?

But I'm not shure the solution apply to me, they were talking about redirection also ...

What do you think about that ?

2. the port 113 (auth) was blocked is the OUTPUT rules with messages in /var/log/messages. I've read there that in this case http request could not work.
You could notice that by default all OUTPUT connections are DROPPED in my iptables config.
So perhaps do I need to open this port in OUTPUT ?
Does people have generally all OUTPUT ACCEPT and not DROP ?

I don`t think so.
You problem is not with all url. If you was have masquerading problem then windows machines can not
work at all.
I don`t know what is port 133 do.
HTTP -80 HTTPS -443 and thats all what need for web.
By the way, you forget https (hope, this solve the problem :) )
-A OUTPUT -p tcp -m tcp -o ppp0 --dport https -j ACCEPT

I've already add the https which was missing, and it does not correct my problem.
See you tomorrow with real users ...

Thank's in advance for your help.

Hello.
I read a little more about iptables :)
Try to check very simple and insecure configuration.
iptables -F
iptables -t nat -F
iptables -t mangle -F
iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE
( or iptables -t nat -A POSTROUTING -o ppp0 -j SNAT --to-source your_static_ip )
iptables -A FORWARD -j LOG --log-level info

In /var/log/messages (I don`t know where you syslog stored info, chekc /etc/syslog.conf ) you
will see requests and replys.

Here are the traces requested :

On eth0 with the command tcpdump -vvv -i eth0 (only ticeropo1 was working) :
on ppp0 (with the command tcpdump -vvv -i ppp0 port not ssh
because I get this trace connected by ssh) :
[CODE]
15:23:46.987738 217.128.230.16.3197 > 194.51.109.131.http: S [tcp sum ok] 1484651153:1484651153(0) win 65535 <mss 1460,nop,nop,sackOK> (DF) (ttl 127, id 49463, len 48)
15:23:46.988172 217.128.230.16.32850 > 198.6.1.83.domain: 49373 [1au] PTR? 131.109.51.194.in-addr.arpa. ar: . (56) (DF) (ttl 64, id 0, len 84)
15:23:47.122217 194.51.109.131.http > 217.128.230.16.3197: S [tcp sum ok] 3663766469:3663766469(0) ack 1484651154 win 65535 <mss 1460,nop,nop,sackOK> (DF) (ttl 118, id 13569, len 48)
15:23:47.122464 217.128.230.16.3197 > 194.51.109.131.http: . [tcp sum ok] 1:1(0) ack 1 win 65535 (DF) (ttl 127, id 49465, len 40)
15:23:47.124311 217.128.230.16.3197 > 194.51.109.131.http: P 1:367(366) ack 1 win 65535 (DF) (ttl 127, id 49466, len 406)
15:23:47.186227 198.6.1.83.domain > 217.128.230.16.32850: 49373-% q: PTR? 131.109.51.194.in-addr.arpa. 0/5/3 ns: 51.194.in-addr.arpa.[|domain] (DF) (ttl 235, id 11963, len 247)
15:23:47.186568 217.128.230.16.32850 > 192.134.0.49.domain: 30993 [1au] PTR? 131.109.51.194.in-addr.arpa. ar: . (56) (DF) (ttl 64, id 0, len 84)
15:23:47.410162 194.51.109.131.http > 217.128.230.16.3197: . [tcp sum ok] 1:1(0) ack 367 win 65169 (DF) (ttl 118, id 13602, len 40)
15:23:49.190707 217.128.230.16.32850 > 193.0.0.193.domain: 31478 [1au] PTR? 131.109.51.194.in-addr.arpa. ar: . (56) (DF) (ttl 64, id 0, len 84)
15:23:49.480592 217.128.230.16.43695 > 217.167.52.114.auth: S [tcp sum ok] 2113102382:2113102382(0) win 5808 <mss 1452,sackOK,timestamp 136782637 0,nop,wscale 0> (DF) (ttl 64, id 16432, len 60)
15:23:51.200703 217.128.230.16.32850 > 194.51.3.49.domain: 57011 [1au] PTR? 131.109.51.194.in-addr.arpa. ar: . (56) (DF) (ttl 64, id 0, len 84)
15:23:51.265468 194.51.3.49.domain > 217.128.230.16.32850: 57011*- q: PTR? 131.109.51.194.in-addr.arpa. 1/2/3 131.109.51.194.in-addr.arpa.[|domain] (ttl 58, id 1869, len 199)
15:23:51.265784 217.128.230.16.32850 > 194.52.1.10.domain: 41731 [1au][|domain] (DF) (ttl 64, id 0, len 92)
15:23:51.361448 194.52.1.10.domain > 217.128.230.16.32850: 41731 q:[|domain] (DF) (ttl 243, id 23322, len 169)
15:23:51.361669 217.128.230.16.32850 > 194.51.3.49.domain: 48061 [1au][|domain] (DF) (ttl 64, id 0, len 92)
15:23:51.425435 194.51.3.49.domain > 217.128.230.16.32850: 48061- q:[|domain] (ttl 58, id 2009, len 181)
15:23:51.425694 217.128.230.16.32850 > 194.51.3.65.domain: 37938 [1au][|domain] (DF) (ttl 64, id 0, len 92)
15:23:51.425785 217.128.230.16.32850 > 193.176.144.6.domain: [udp sum ok] 51737 [1au] A? ceprox01.cerius.fr. ar: . OPT UDPsize=2048 (47) (DF) (ttl 64, id 0, len 75)
15:23:51.489425 194.51.3.65.domain > 217.128.230.16.32850: 37938 NXDomain*- q:[|domain] (DF) (ttl 248, id 13937, len 155)
15:23:51.505436 193.176.144.6.domain > 217.128.230.16.32850: 51737-% q: A? ceprox01.cerius.fr. 1/2/3 ceprox01.cerius.fr. A 194.51.109.157[|domain] (ttl 49, id 23295, len 162)
15:23:55.480591 217.128.230.16.43695 > 217.167.52.114.auth: S [tcp sum ok] 2113102382:2113102382(0) win 5808 <mss 1452,sackOK,timestamp 136783237 0,nop,wscale 0> (DF) (ttl 64, id 16433, len 60)
…
424 packets received by filter
87 packets dropped by kernel
[/CODE

in /var/log/messages :
First question :
the tcpdump command says xxx paquets dropped and normally I should see this paquet on /var/log/messages. I'm shure this is working in my firewall configuration :
Thank's for all

>First question :
>the tcpdump command says xxx paquets dropped and normally I should see this paquet on >/var/log/messages. I'm shure this is working in my firewall configuration :
Check syslog.conf. Are you sure what --log-level 3 will be send to /var/log/messages ? (3 what is it ? debug, info or ?)
If syslog.conf is ok
- make all rules -j LOG first rules in tables
- shorter their.
Example
-A OUTPUT -j LOG --log-prefix "IPTABLES-OUTPUT : " --log-level 3

I am not understand www.nordparis.banquepopulaire.fr is "bad url" ?
It is work now ? How about fr.google.com ?

The begining my syslog.conf is the following :
Do you think it's ok ?

Ok I will do that. My goal was to have only the dropped packet. So I have to put the LOG rule at the end, just before the DROP. Am I wrong ?

Ok I should give more explanations (sorry for that). www.nordparis.banquepopulaire.fr is a bad URL too. This URL is more easier to test because, all the site is not answering and not only one button in the site as with fr.yahoo.com (google is working without problem).

Can you give me the good configuration (firewall and syslog.conf) to have a log for each dropped packet ?

Thank you.

I've try with your commands and there were no more traffic in and out of the Linux box.....
So I've try with these rules :
and the problem is still the same.
The tcpdump trace says : !!
How is it possible to have packets dropped with the rules showns before ?
How to see what packets are dropped (nothing in /var/log/messages) ?
Is there any incorrect packets wich are not traced ?

Answering those questions is certainly the beginning of the solution.

You write --log-level 3 ---->
In syslog.h 3 define as LOG_ERROR (error) ----> you logs send to /var/log/syslog
Replace 3 - info and you must get logs into /var/log/messages
Oopss. Sorry, my fault, you right!
My dump with (localhost linux)
-1 14:39:01.869264 admin414.33706 > 194.51.109.131.http: S [tcp sum ok] 1312746232:1312746232(0) win 5840 <mss 1460,sackOK,timestamp 2199983 0,nop,wscale 0> (DF) (ttl 64, id 31575, len 60)
-2 14:39:01.966707 194.51.109.131.http > admin414.33706: S [tcp sum ok] 2324403888:2324403888(0) ack 1312746233 win 65535 <mss 1460,nop,wscale 0,nop,nop,timestamp 0 0,nop,nop,sackOK> (DF) (ttl 104, id 21187, len 64)
-3 14:39:01.966741 admin414.33706 > 194.51.109.131.http: . [tcp sum ok] 1:1(0) ack 1 win 5840 <nop,nop,timestamp 2199993 0> (DF) (ttl 64, id 31576, len 52)
-4 14:39:01.966863 admin414.33706 > 194.51.109.131.http: P [tcp sum ok] 1:504(503) ack 1 win 5840 <nop,nop,timestamp 2199993 0> (DF) (ttl 64, id 31577, len 555)
-5 14:39:02.081956 194.51.109.131.http > admin414.33706: . [tcp sum ok] 1:1449(1448) ack 504 win 65032 <nop,nop,timestamp 220827 2199993> (DF) (ttl 104, id 21188, len 1500)

If compare with your dump will see what len of my packet number 5 is 1448 and your only 40! I don`t understand why so small ?
15:23:47.410162 194.51.109.131.http > 217.128.230.16.3197: . [tcp sum ok] 1:1(0) ack 367 win 65169 (DF) (ttl 118, id 13602, len 40)

Sorry, we have not linux firewall :)

I dont see what you want log :
Post iptables result -- not iptables-save

I just want to show you that with all rules at ACCEPT, the problem still occurs. So it's not a firewall problem.

The traces shows that there were Dropped packets whereas the firewall was accepting all packets. It's the problem we have to focus on, (I think).

How is it possible ? What are those packets ?
Can it be a hardware pb in the NIC ?

Best regards and thank's for all ......

It's not a pb because Error is > than Info and so messages are in both files.
It's a response packet no ?. Is it possible to see what is in the packet ? Perhaps there is an error or something like in this packet.

Here is another dialog with this site :
(from eth0) :
It's seems to be 3 packets for one call id=22026, 22027 and 22029.
1. Is it a framented packet ?
2. Is it possible that this site refuse fragmented packet ?
3. We have 22026, 22027 and 22029 where is 22028 ?
4. what means the 'P' after http: ?

The same dialog viewed from ppp0 :
3. Why is there so much DNS request ? I understand the first one but why the others ?

Here is a dialog which is OK directly from the server. This was obtained with :
The dialog from ppp0 :
In bold you've some differences with a nok dialog.


Can this help ?

Save traffic to file
tcpdump -s 0 -w /file_name -i ppp0

Next step, gui ethereal.

If I not wrong (DF) -disable fragmentation
P -push flag -- sent urgent data
It is tcpdump make resolving for output. Add flag -n

Ok, I've got the file. What should I do with that ?

Try to send
GET / HTTP/1.1

You need the program ethereal
This is GUI for showing file contents.

Is this a X window application or command line ?. Because I cannot export display on other X server.
If it is an X application, is there another way to inspect the packets ?

OK I've got it installed on a distant windows box.
I load a file generated on the Linux box and here is an extract of the interesting dialog (only packet at the begining and interesting packet are shown here. I can send the complete file to you if you want ...) :
I've put in bold where there is something interesting (I think ...).
This is trace from ppp0 interface only. I don't have the traces from eth0 interface.

Sorry for the long, long listing....
I can send the tcpdump file to you if you want .

Many many thank's for your help.

X application. Copy file on another linux box.

SOLUTION
 

It was an MTU/MRU or Clamp MSS problem.
The solution is to type this command :
iptables -t mangle -A FORWARD -p tcp --syn -j TCPMSS --clamp-mss-to-pmtu
or this command :
iptables -t mangle -A FORWARD -p tcp --syn -j TCPMSS --set-mss 1452

More informations are available on this link :
here

Sorry to be off topic, but man and I supprised to see a pro-MS comment like that in this forum :)