j'ai quelques soucis de fragmentation sur ma passerelle.
J'ai mis en place une passerelle (que l'on appellera 192.168.1.254)
sous OpenBSD 3.1. Cette passerelle realise une translation d'adresses
(NAT).
Elle accede à internet grace a une autre passerelle (redhat) dont
l'adresse serais 192.168.2.254.
J'ai donc le schema suivant :
reseau interne(192.168.1.0/24) <--> OpenBSD-31(192.168.1.254)
OpenBSD-31(192.168.2.1)<--->RedHat(192.168.2.254).
Donc sur le reseau local la passerelle est openbsd.
Sur Openbsd la passerelle est RedHat.
sur RedHat je ping google.fr sans aucuns soucis.
Sur celle ci aussi je ping google avec des 1600 octets
de donnees sans aucuns problemes. (ping -s 1600 google.fr)
Sur OpenBSD je ping google sans aucuns soucis aussi :)
En revanche les paquets supperieurs a 1500 ne passent pas.
Sur le reseau local idems bien evidemment.
Dans le pf.conf je n'ai pas de regles particuliere, d'ailleurs
en faisant un "pfctl -d" cela ne marche pas mieux.
Depuis le reseau local les pings inferieurs a 1500 passent aussi.
Un traceroute marche a merveille. Je ne comprend vraiment pas d'ou
cela peut venir.
Un traceroute marche a merveille. Je ne comprend vraiment pas d'ou cela peut venir.
Ben pourtant tu l'as dit: tu ne laisses pas passer les fragments. Le MTU sur ton réseau est à 1500, tout ce qui est au dessus est fragmenté, et donc bloqué.
Avec IPFilter, il suffirait de rajouter des "keep frags" sur tes regles pass. D'après ce que j'ai ecrit dans le cahier de l'admin BSD (Aux editions Eyrolles, 29 euros seulement, joli, pas cher), ca marcherait pareil avec PacketFilter, mais il semblerait en fait que j'ai ecrit une betise: une rapide recherche sur le web indique que "keep frags" n'est pas implémenté dans OpenBSD. Par défaut il les passerait. Ca te fait une belle jambe, hein?
Bon, ca me fait une entrée pour l'errata, à moins que ca ait été implémenté entre temps. Dis moi ce que tu auras trouvé comme explication, ca m'interesse.
-- Emmanuel Dreyfus Publicité subliminale: achetez ce livre! http://www.eyrolles.com/Informatique/Livre/9782212114638/livre-bsd.php
Sebastien Vincent <svincent@idems.fr> wrote:
Un traceroute marche a merveille. Je ne comprend vraiment pas d'ou
cela peut venir.
Ben pourtant tu l'as dit: tu ne laisses pas passer les fragments. Le MTU
sur ton réseau est à 1500, tout ce qui est au dessus est fragmenté, et
donc bloqué.
Avec IPFilter, il suffirait de rajouter des "keep frags" sur tes regles
pass. D'après ce que j'ai ecrit dans le cahier de l'admin BSD (Aux
editions Eyrolles, 29 euros seulement, joli, pas cher), ca marcherait
pareil avec PacketFilter, mais il semblerait en fait que j'ai ecrit une
betise: une rapide recherche sur le web indique que "keep frags" n'est
pas implémenté dans OpenBSD. Par défaut il les passerait. Ca te fait une
belle jambe, hein?
Bon, ca me fait une entrée pour l'errata, à moins que ca ait été
implémenté entre temps. Dis moi ce que tu auras trouvé comme
explication, ca m'interesse.
--
Emmanuel Dreyfus
Publicité subliminale: achetez ce livre!
http://www.eyrolles.com/Informatique/Livre/9782212114638/livre-bsd.php
manu@netbsd.org
Un traceroute marche a merveille. Je ne comprend vraiment pas d'ou cela peut venir.
Ben pourtant tu l'as dit: tu ne laisses pas passer les fragments. Le MTU sur ton réseau est à 1500, tout ce qui est au dessus est fragmenté, et donc bloqué.
Avec IPFilter, il suffirait de rajouter des "keep frags" sur tes regles pass. D'après ce que j'ai ecrit dans le cahier de l'admin BSD (Aux editions Eyrolles, 29 euros seulement, joli, pas cher), ca marcherait pareil avec PacketFilter, mais il semblerait en fait que j'ai ecrit une betise: une rapide recherche sur le web indique que "keep frags" n'est pas implémenté dans OpenBSD. Par défaut il les passerait. Ca te fait une belle jambe, hein?
Bon, ca me fait une entrée pour l'errata, à moins que ca ait été implémenté entre temps. Dis moi ce que tu auras trouvé comme explication, ca m'interesse.
-- Emmanuel Dreyfus Publicité subliminale: achetez ce livre! http://www.eyrolles.com/Informatique/Livre/9782212114638/livre-bsd.php
Pascal Cabaud
Emmanuel Dreyfus wrote:
Avec IPFilter, il suffirait de rajouter des "keep frags" sur tes regles pass. D'après ce que j'ai ecrit dans le cahier de l'admin BSD (Aux editions Eyrolles, 29 euros seulement, joli, pas cher), ca marcherait pareil avec PacketFilter, mais il semblerait en fait que j'ai ecrit une betise: une rapide recherche sur le web indique que "keep frags" n'est pas implémenté dans OpenBSD. Par défaut il les passerait.
C'est gere par les lignes 'scrub', cf. le manuel de pf.conf.
Emmanuel Dreyfus wrote:
Avec IPFilter, il suffirait de rajouter des "keep frags" sur tes regles
pass. D'après ce que j'ai ecrit dans le cahier de l'admin BSD (Aux
editions Eyrolles, 29 euros seulement, joli, pas cher), ca marcherait
pareil avec PacketFilter, mais il semblerait en fait que j'ai ecrit une
betise: une rapide recherche sur le web indique que "keep frags" n'est
pas implémenté dans OpenBSD. Par défaut il les passerait.
C'est gere par les lignes 'scrub', cf. le manuel de pf.conf.
Avec IPFilter, il suffirait de rajouter des "keep frags" sur tes regles pass. D'après ce que j'ai ecrit dans le cahier de l'admin BSD (Aux editions Eyrolles, 29 euros seulement, joli, pas cher), ca marcherait pareil avec PacketFilter, mais il semblerait en fait que j'ai ecrit une betise: une rapide recherche sur le web indique que "keep frags" n'est pas implémenté dans OpenBSD. Par défaut il les passerait.
C'est gere par les lignes 'scrub', cf. le manuel de pf.conf.
manu
Pascal Cabaud wrote:
Avec IPFilter, il suffirait de rajouter des "keep frags" sur tes regles pass. D'après ce que j'ai ecrit dans le cahier de l'admin BSD (Aux editions Eyrolles, 29 euros seulement, joli, pas cher), ca marcherait pareil avec PacketFilter, mais il semblerait en fait que j'ai ecrit une betise: une rapide recherche sur le web indique que "keep frags" n'est pas implémenté dans OpenBSD. Par défaut il les passerait.
C'est gere par les lignes 'scrub', cf. le manuel de pf.conf.
Ben justement, d'après la doc, scrub ne decide pas si les fragments passent ou pas, il est là pour faire des hacks plus ou moins fumeux de reassemblage au vol des fragments.
Y'a un truc subtil pas dans la doc?
-- Emmanuel Dreyfus Un bouquin en français sur BSD: http://www.eyrolles.com/Informatique/Livre/9782212114638/livre-bsd.php
Pascal Cabaud <pcNO@SPAMeila.jussieu.fr> wrote:
Avec IPFilter, il suffirait de rajouter des "keep frags" sur tes regles
pass. D'après ce que j'ai ecrit dans le cahier de l'admin BSD (Aux
editions Eyrolles, 29 euros seulement, joli, pas cher), ca marcherait
pareil avec PacketFilter, mais il semblerait en fait que j'ai ecrit une
betise: une rapide recherche sur le web indique que "keep frags" n'est
pas implémenté dans OpenBSD. Par défaut il les passerait.
C'est gere par les lignes 'scrub', cf. le manuel de pf.conf.
Ben justement, d'après la doc, scrub ne decide pas si les fragments
passent ou pas, il est là pour faire des hacks plus ou moins fumeux de
reassemblage au vol des fragments.
Y'a un truc subtil pas dans la doc?
--
Emmanuel Dreyfus
Un bouquin en français sur BSD:
http://www.eyrolles.com/Informatique/Livre/9782212114638/livre-bsd.php
manu@netbsd.org
Avec IPFilter, il suffirait de rajouter des "keep frags" sur tes regles pass. D'après ce que j'ai ecrit dans le cahier de l'admin BSD (Aux editions Eyrolles, 29 euros seulement, joli, pas cher), ca marcherait pareil avec PacketFilter, mais il semblerait en fait que j'ai ecrit une betise: une rapide recherche sur le web indique que "keep frags" n'est pas implémenté dans OpenBSD. Par défaut il les passerait.
C'est gere par les lignes 'scrub', cf. le manuel de pf.conf.
Ben justement, d'après la doc, scrub ne decide pas si les fragments passent ou pas, il est là pour faire des hacks plus ou moins fumeux de reassemblage au vol des fragments.
Y'a un truc subtil pas dans la doc?
-- Emmanuel Dreyfus Un bouquin en français sur BSD: http://www.eyrolles.com/Informatique/Livre/9782212114638/livre-bsd.php
Sebastien Vincent
Emmanuel Dreyfus wrote:
Pascal Cabaud wrote:
Avec IPFilter, il suffirait de rajouter des "keep frags" sur tes regles pass. D'après ce que j'ai ecrit dans le cahier de l'admin BSD (Aux editions Eyrolles, 29 euros seulement, joli, pas cher), ca marcherait pareil avec PacketFilter, mais il semblerait en fait que j'ai ecrit une betise: une rapide recherche sur le web indique que "keep frags" n'est pas implémenté dans OpenBSD. Par défaut il les passerait.
Lol j'ai déja les cahiers de l'admin :) J'ai bien tenté un "scrub in/out all no-df"
C'est gere par les lignes 'scrub', cf. le manuel de pf.conf.
Je l'ai parcourru en travers hier avant d'ecrire, cela m'a ammene au scrub :)
Ben justement, d'après la doc, scrub ne decide pas si les fragments passent ou pas, il est là pour faire des hacks plus ou moins fumeux de reassemblage au vol des fragments.
Theoriquement (en couplant la faq pf et les cahiers de l'admin) il protege de l'attaque "TearDrop"). J'ai appris l'existance de cette attaque dans le livre (merci manu). Promis, des que j'ai un temps je fait un google pour voir en quoi ca consiste :)
Y'a un truc subtil pas dans la doc?
Je ne sais pas, je reste un peu bloque, mais comme je suis debutant j'ai passe une tite journee a faire divers tests varies et a regarder des petits bouts de docs par ci, par la avant de poster quand meme :)
Amicalement,
Seb :)
Emmanuel Dreyfus wrote:
Pascal Cabaud <pcNO@SPAMeila.jussieu.fr> wrote:
Avec IPFilter, il suffirait de rajouter des "keep frags" sur tes regles
pass. D'après ce que j'ai ecrit dans le cahier de l'admin BSD (Aux
editions Eyrolles, 29 euros seulement, joli, pas cher), ca marcherait
pareil avec PacketFilter, mais il semblerait en fait que j'ai ecrit une
betise: une rapide recherche sur le web indique que "keep frags" n'est
pas implémenté dans OpenBSD. Par défaut il les passerait.
Lol j'ai déja les cahiers de l'admin :)
J'ai bien tenté un "scrub in/out all no-df"
C'est gere par les lignes 'scrub', cf. le manuel de pf.conf.
Je l'ai parcourru en travers hier avant d'ecrire, cela m'a
ammene au scrub :)
Ben justement, d'après la doc, scrub ne decide pas si les fragments
passent ou pas, il est là pour faire des hacks plus ou moins fumeux de
reassemblage au vol des fragments.
Theoriquement (en couplant la faq pf et les cahiers de l'admin) il
protege de l'attaque "TearDrop"). J'ai appris l'existance de cette
attaque dans le livre (merci manu). Promis, des que j'ai un temps je
fait un google pour voir en quoi ca consiste :)
Y'a un truc subtil pas dans la doc?
Je ne sais pas, je reste un peu bloque, mais comme je suis debutant
j'ai passe une tite journee a faire divers tests varies et a regarder
des petits bouts de docs par ci, par la avant de poster quand meme :)
Avec IPFilter, il suffirait de rajouter des "keep frags" sur tes regles pass. D'après ce que j'ai ecrit dans le cahier de l'admin BSD (Aux editions Eyrolles, 29 euros seulement, joli, pas cher), ca marcherait pareil avec PacketFilter, mais il semblerait en fait que j'ai ecrit une betise: une rapide recherche sur le web indique que "keep frags" n'est pas implémenté dans OpenBSD. Par défaut il les passerait.
Lol j'ai déja les cahiers de l'admin :) J'ai bien tenté un "scrub in/out all no-df"
C'est gere par les lignes 'scrub', cf. le manuel de pf.conf.
Je l'ai parcourru en travers hier avant d'ecrire, cela m'a ammene au scrub :)
Ben justement, d'après la doc, scrub ne decide pas si les fragments passent ou pas, il est là pour faire des hacks plus ou moins fumeux de reassemblage au vol des fragments.
Theoriquement (en couplant la faq pf et les cahiers de l'admin) il protege de l'attaque "TearDrop"). J'ai appris l'existance de cette attaque dans le livre (merci manu). Promis, des que j'ai un temps je fait un google pour voir en quoi ca consiste :)
Y'a un truc subtil pas dans la doc?
Je ne sais pas, je reste un peu bloque, mais comme je suis debutant j'ai passe une tite journee a faire divers tests varies et a regarder des petits bouts de docs par ci, par la avant de poster quand meme :)
Amicalement,
Seb :)
Fabrice
Alors voilà en pratique ce qui se passe.
Tout est très difficile... Voila un illustration :
shinmei $ wget http://www.openbsd.org/images/puffy35.gif --11:14:24-- http://www.openbsd.org/images/puffy35.gif => `puffy35.gif' Résolution de www.openbsd.org... 129.128.5.191 Connexion vers www.openbsd.org[129.128.5.191]:80...connecté. requête HTTP transmise, en attente de la réponse...200 OK Longueur: 81,395 [image/gif]
6% [=> ] 5,287 6.36K/s
Là il bloque et n'ira pas plus loin :(
Question idiote : ton accès ne serait pas un accès ADSL genre PPPoE par hasard ? Si oui as-tu bien set mtu max 1492 et set mru max 1492 dans l'équivalent de ppp.conf (je ne connais pas Open) ?
FAbrice
Alors voilà en pratique ce qui se passe.
Tout est très difficile... Voila un illustration :
shinmei@seb_linux shinmei $ wget http://www.openbsd.org/images/puffy35.gif
--11:14:24-- http://www.openbsd.org/images/puffy35.gif
=> `puffy35.gif'
Résolution de www.openbsd.org... 129.128.5.191
Connexion vers www.openbsd.org[129.128.5.191]:80...connecté.
requête HTTP transmise, en attente de la réponse...200 OK
Longueur: 81,395 [image/gif]
6% [=> ] 5,287 6.36K/s
Là il bloque et n'ira pas plus loin :(
Question idiote : ton accès ne serait pas un accès ADSL genre PPPoE par
hasard ? Si oui as-tu bien set mtu max 1492 et set mru max 1492 dans
l'équivalent de ppp.conf (je ne connais pas Open) ?
Tout est très difficile... Voila un illustration :
shinmei $ wget http://www.openbsd.org/images/puffy35.gif --11:14:24-- http://www.openbsd.org/images/puffy35.gif => `puffy35.gif' Résolution de www.openbsd.org... 129.128.5.191 Connexion vers www.openbsd.org[129.128.5.191]:80...connecté. requête HTTP transmise, en attente de la réponse...200 OK Longueur: 81,395 [image/gif]
6% [=> ] 5,287 6.36K/s
Là il bloque et n'ira pas plus loin :(
Question idiote : ton accès ne serait pas un accès ADSL genre PPPoE par hasard ? Si oui as-tu bien set mtu max 1492 et set mru max 1492 dans l'équivalent de ppp.conf (je ne connais pas Open) ?
FAbrice
Sebastien Vincent
Alors voilà en pratique ce qui se passe.
Tout est très difficile... Voila un illustration :
shinmei $ wget http://www.openbsd.org/images/puffy35.gif --11:14:24-- http://www.openbsd.org/images/puffy35.gif => `puffy35.gif' Résolution de www.openbsd.org... 129.128.5.191 Connexion vers www.openbsd.org[129.128.5.191]:80...connecté. requête HTTP transmise, en attente de la réponse...200 OK Longueur: 81,395 [image/gif]
6% [=> ] 5,287 6.36K/s
Là il bloque et n'ira pas plus loin :(
tcpdump durant la session : 11:14:24.529146 IP 192.168.1.36.32798 > ns3.wanadoo.fr.domain: 53419+[|domain] 11:14:24.792749 IP ns3.wanadoo.fr.domain > 192.168.1.36.32798: 53419[|domain] 11:14:24.793187 IP 192.168.1.36.42452 > openbsd.sunsite.ualberta.ca.www: S 3925792984:3925792984(0) win 5840 <mss 1460,sackOK,timestamp 311385394[|tcp]> 11:14:25.190485 IP openbsd.sunsite.ualberta.ca.www > 192.168.1.36.42452: S 2978228154:2978228154(0) ack 3925792985 win 1412 <nop,nop,timestamp 2023460947 311385394,nop,[|tcp]> 11:14:25.190552 IP 192.168.1.36.42452 > openbsd.sunsite.ualberta.ca.www: . ack 1 win 46 <nop,nop,timestamp 311385791 2023460947> 11:14:25.190890 IP 192.168.1.36.42452 > openbsd.sunsite.ualberta.ca.www: P 1:119(118) ack 1 win 46 <nop,nop,timestamp 311385792 2023460947> 11:14:25.594350 IP openbsd.sunsite.ualberta.ca.www > 192.168.1.36.42452: . ack 119 win 9800 <nop,nop,timestamp 2023460988 311385792> 11:14:25.609288 IP openbsd.sunsite.ualberta.ca.www > 192.168.1.36.42452: P 1:1401(1400) ack 119 win 9800 <nop,nop,timestamp 2023460988 311385792> 11:14:25.609369 IP 192.168.1.36.42452 > openbsd.sunsite.ualberta.ca.www: . ack 1401 win 69 <nop,nop,timestamp 311386210 2023460988> 11:14:26.019211 IP openbsd.sunsite.ualberta.ca.www > 192.168.1.36.42452: . 1401:2801(1400) ack 119 win 9800 <nop,nop,timestamp 2023461029 311386210> 11:14:26.019291 IP 192.168.1.36.42452 > openbsd.sunsite.ualberta.ca.www: . ack 2801 win 91 <nop,nop,timestamp 311386620 2023461029> 11:14:26.030412 IP openbsd.sunsite.ualberta.ca.www > 192.168.1.36.42452: P 2801:4201(1400) ack 119 win 9800 <nop,nop,timestamp 2023461029 311386210> 11:14:26.030478 IP 192.168.1.36.42452 > openbsd.sunsite.ualberta.ca.www: . ack 4201 win 114 <nop,nop,timestamp 311386631 2023461029> 11:14:26.427048 IP openbsd.sunsite.ualberta.ca.www > 192.168.1.36.42452: . 4201:5601(1400) ack 119 win 9800 <nop,nop,timestamp 2023461070 311386620> 11:14:26.427105 IP 192.168.1.36.42452 > openbsd.sunsite.ualberta.ca.www: . ack 5601 win 137 <nop,nop,timestamp 311387028 2023461070>
Je ne m'y connais pas trop trop en reseaux, mais bon : Requete dns a ns3.wanadoo.fr Requete http et réponse.
Donc normalement rien de bien special.
Enfin bon cela s'arrete sans que j'en maitrise la raison :(
D'avance merci de vos avis :)
Amicalement,
Seb :)
Alors voilà en pratique ce qui se passe.
Tout est très difficile... Voila un illustration :
shinmei@seb_linux shinmei $ wget http://www.openbsd.org/images/puffy35.gif
--11:14:24-- http://www.openbsd.org/images/puffy35.gif
=> `puffy35.gif'
Résolution de www.openbsd.org... 129.128.5.191
Connexion vers www.openbsd.org[129.128.5.191]:80...connecté.
requête HTTP transmise, en attente de la réponse...200 OK
Longueur: 81,395 [image/gif]
6% [=> ] 5,287 6.36K/s
Là il bloque et n'ira pas plus loin :(
tcpdump durant la session :
11:14:24.529146 IP 192.168.1.36.32798 > ns3.wanadoo.fr.domain:
53419+[|domain]
11:14:24.792749 IP ns3.wanadoo.fr.domain > 192.168.1.36.32798:
53419[|domain]
11:14:24.793187 IP 192.168.1.36.42452 > openbsd.sunsite.ualberta.ca.www:
S 3925792984:3925792984(0) win 5840 <mss 1460,sackOK,timestamp
311385394[|tcp]>
11:14:25.190485 IP openbsd.sunsite.ualberta.ca.www > 192.168.1.36.42452:
S 2978228154:2978228154(0) ack 3925792985 win 1412 <nop,nop,timestamp
2023460947 311385394,nop,[|tcp]>
11:14:25.190552 IP 192.168.1.36.42452 > openbsd.sunsite.ualberta.ca.www:
. ack 1 win 46 <nop,nop,timestamp 311385791 2023460947>
11:14:25.190890 IP 192.168.1.36.42452 > openbsd.sunsite.ualberta.ca.www:
P 1:119(118) ack 1 win 46 <nop,nop,timestamp 311385792 2023460947>
11:14:25.594350 IP openbsd.sunsite.ualberta.ca.www > 192.168.1.36.42452:
. ack 119 win 9800 <nop,nop,timestamp 2023460988 311385792>
11:14:25.609288 IP openbsd.sunsite.ualberta.ca.www > 192.168.1.36.42452:
P 1:1401(1400) ack 119 win 9800 <nop,nop,timestamp 2023460988 311385792>
11:14:25.609369 IP 192.168.1.36.42452 > openbsd.sunsite.ualberta.ca.www:
. ack 1401 win 69 <nop,nop,timestamp 311386210 2023460988>
11:14:26.019211 IP openbsd.sunsite.ualberta.ca.www > 192.168.1.36.42452:
. 1401:2801(1400) ack 119 win 9800 <nop,nop,timestamp 2023461029 311386210>
11:14:26.019291 IP 192.168.1.36.42452 > openbsd.sunsite.ualberta.ca.www:
. ack 2801 win 91 <nop,nop,timestamp 311386620 2023461029>
11:14:26.030412 IP openbsd.sunsite.ualberta.ca.www > 192.168.1.36.42452:
P 2801:4201(1400) ack 119 win 9800 <nop,nop,timestamp 2023461029 311386210>
11:14:26.030478 IP 192.168.1.36.42452 > openbsd.sunsite.ualberta.ca.www:
. ack 4201 win 114 <nop,nop,timestamp 311386631 2023461029>
11:14:26.427048 IP openbsd.sunsite.ualberta.ca.www > 192.168.1.36.42452:
. 4201:5601(1400) ack 119 win 9800 <nop,nop,timestamp 2023461070 311386620>
11:14:26.427105 IP 192.168.1.36.42452 > openbsd.sunsite.ualberta.ca.www:
. ack 5601 win 137 <nop,nop,timestamp 311387028 2023461070>
Je ne m'y connais pas trop trop en reseaux, mais bon :
Requete dns a ns3.wanadoo.fr
Requete http et réponse.
Donc normalement rien de bien special.
Enfin bon cela s'arrete sans que j'en maitrise la raison :(
Tout est très difficile... Voila un illustration :
shinmei $ wget http://www.openbsd.org/images/puffy35.gif --11:14:24-- http://www.openbsd.org/images/puffy35.gif => `puffy35.gif' Résolution de www.openbsd.org... 129.128.5.191 Connexion vers www.openbsd.org[129.128.5.191]:80...connecté. requête HTTP transmise, en attente de la réponse...200 OK Longueur: 81,395 [image/gif]
6% [=> ] 5,287 6.36K/s
Là il bloque et n'ira pas plus loin :(
tcpdump durant la session : 11:14:24.529146 IP 192.168.1.36.32798 > ns3.wanadoo.fr.domain: 53419+[|domain] 11:14:24.792749 IP ns3.wanadoo.fr.domain > 192.168.1.36.32798: 53419[|domain] 11:14:24.793187 IP 192.168.1.36.42452 > openbsd.sunsite.ualberta.ca.www: S 3925792984:3925792984(0) win 5840 <mss 1460,sackOK,timestamp 311385394[|tcp]> 11:14:25.190485 IP openbsd.sunsite.ualberta.ca.www > 192.168.1.36.42452: S 2978228154:2978228154(0) ack 3925792985 win 1412 <nop,nop,timestamp 2023460947 311385394,nop,[|tcp]> 11:14:25.190552 IP 192.168.1.36.42452 > openbsd.sunsite.ualberta.ca.www: . ack 1 win 46 <nop,nop,timestamp 311385791 2023460947> 11:14:25.190890 IP 192.168.1.36.42452 > openbsd.sunsite.ualberta.ca.www: P 1:119(118) ack 1 win 46 <nop,nop,timestamp 311385792 2023460947> 11:14:25.594350 IP openbsd.sunsite.ualberta.ca.www > 192.168.1.36.42452: . ack 119 win 9800 <nop,nop,timestamp 2023460988 311385792> 11:14:25.609288 IP openbsd.sunsite.ualberta.ca.www > 192.168.1.36.42452: P 1:1401(1400) ack 119 win 9800 <nop,nop,timestamp 2023460988 311385792> 11:14:25.609369 IP 192.168.1.36.42452 > openbsd.sunsite.ualberta.ca.www: . ack 1401 win 69 <nop,nop,timestamp 311386210 2023460988> 11:14:26.019211 IP openbsd.sunsite.ualberta.ca.www > 192.168.1.36.42452: . 1401:2801(1400) ack 119 win 9800 <nop,nop,timestamp 2023461029 311386210> 11:14:26.019291 IP 192.168.1.36.42452 > openbsd.sunsite.ualberta.ca.www: . ack 2801 win 91 <nop,nop,timestamp 311386620 2023461029> 11:14:26.030412 IP openbsd.sunsite.ualberta.ca.www > 192.168.1.36.42452: P 2801:4201(1400) ack 119 win 9800 <nop,nop,timestamp 2023461029 311386210> 11:14:26.030478 IP 192.168.1.36.42452 > openbsd.sunsite.ualberta.ca.www: . ack 4201 win 114 <nop,nop,timestamp 311386631 2023461029> 11:14:26.427048 IP openbsd.sunsite.ualberta.ca.www > 192.168.1.36.42452: . 4201:5601(1400) ack 119 win 9800 <nop,nop,timestamp 2023461070 311386620> 11:14:26.427105 IP 192.168.1.36.42452 > openbsd.sunsite.ualberta.ca.www: . ack 5601 win 137 <nop,nop,timestamp 311387028 2023461070>
Je ne m'y connais pas trop trop en reseaux, mais bon : Requete dns a ns3.wanadoo.fr Requete http et réponse.
Donc normalement rien de bien special.
Enfin bon cela s'arrete sans que j'en maitrise la raison :(
D'avance merci de vos avis :)
Amicalement,
Seb :)
manu
Sebastien Vincent wrote:
donc le schema localnet<->openbsd<->redhat<->model adsl ppoe<->internet redhat se connecte en pppoe en effet.
Bon, ben l'affaire est entendue: un problème de MTU.
-- Emmanuel Dreyfus Un bouquin en français sur BSD: http://www.eyrolles.com/Informatique/Livre/9782212114638/livre-bsd.php
Sebastien Vincent <svincent@idems.fr> wrote:
donc le schema localnet<->openbsd<->redhat<->model adsl ppoe<->internet
redhat se connecte en pppoe en effet.
Bon, ben l'affaire est entendue: un problème de MTU.
--
Emmanuel Dreyfus
Un bouquin en français sur BSD:
http://www.eyrolles.com/Informatique/Livre/9782212114638/livre-bsd.php
manu@netbsd.org
donc le schema localnet<->openbsd<->redhat<->model adsl ppoe<->internet redhat se connecte en pppoe en effet.
Bon, ben l'affaire est entendue: un problème de MTU.
-- Emmanuel Dreyfus Un bouquin en français sur BSD: http://www.eyrolles.com/Informatique/Livre/9782212114638/livre-bsd.php
Patrice Auffret
On Tue, 24 Aug 2004 13:56:20 +0400 Sebastien Vincent wrote: [..]
Le thread reste ouvert haha :)
Il faut surement autoriser les ICMP type 3 (destination unreachable) avec code 4 (fragmentation needed and DF set) sur ton firewall, pour que le client réémette les paquets par fragments.
On Tue, 24 Aug 2004 13:56:20 +0400
Sebastien Vincent <svincent@idems.fr> wrote:
[..]
Le thread reste ouvert haha :)
Il faut surement autoriser les ICMP type 3 (destination
unreachable) avec code 4 (fragmentation needed and DF set)
sur ton firewall, pour que le client réémette les paquets par
fragments.
On Tue, 24 Aug 2004 13:56:20 +0400 Sebastien Vincent wrote: [..]
Le thread reste ouvert haha :)
Il faut surement autoriser les ICMP type 3 (destination unreachable) avec code 4 (fragmentation needed and DF set) sur ton firewall, pour que le client réémette les paquets par fragments.
Tout est très difficile... Voila un illustration :
shinmei $ wget http://www.openbsd.org/images/puffy35.gif --11:14:24-- http://www.openbsd.org/images/puffy35.gif => `puffy35.gif' Résolution de www.openbsd.org... 129.128.5.191 Connexion vers www.openbsd.org[129.128.5.191]:80...connecté. requête HTTP transmise, en attente de la réponse...200 OK Longueur: 81,395 [image/gif]
6% [=> ] 5,287 6.36K/s
Là il bloque et n'ira pas plus loin :(
Question idiote : ton accès ne serait pas un accès ADSL genre PPPoE par hasard ? Si oui as-tu bien set mtu max 1492 et set mru max 1492 dans l'équivalent de ppp.conf (je ne connais pas Open) ?
donc le schema localnet<->openbsd<->redhat<->model adsl ppoe<->internet redhat se connecte en pppoe en effet.
redhat n'a pas de problemes lorsque je fait la meme opération (le wget). openbsd non plus en revanche depuis le réseau local (windows ou linux) cela ne fonctionne pas et reste bloqué :/
Une session ssh sur openbsd finit toujours par bloquer avec un timeout.
Merci de ta réponse :)
Amicalement,
Seb :)
FAbrice
Fabrice wrote:
Alors voilà en pratique ce qui se passe.
Tout est très difficile... Voila un illustration :
shinmei@seb_linux shinmei $ wget
http://www.openbsd.org/images/puffy35.gif
--11:14:24-- http://www.openbsd.org/images/puffy35.gif
=> `puffy35.gif'
Résolution de www.openbsd.org... 129.128.5.191
Connexion vers www.openbsd.org[129.128.5.191]:80...connecté.
requête HTTP transmise, en attente de la réponse...200 OK
Longueur: 81,395 [image/gif]
6% [=> ] 5,287 6.36K/s
Là il bloque et n'ira pas plus loin :(
Question idiote : ton accès ne serait pas un accès ADSL genre PPPoE par
hasard ? Si oui as-tu bien set mtu max 1492 et set mru max 1492 dans
l'équivalent de ppp.conf (je ne connais pas Open) ?
donc le schema localnet<->openbsd<->redhat<->model adsl ppoe<->internet
redhat se connecte en pppoe en effet.
redhat n'a pas de problemes lorsque je fait la meme opération (le wget).
openbsd non plus
en revanche depuis le réseau local (windows ou linux) cela ne fonctionne
pas et reste bloqué :/
Une session ssh sur openbsd finit toujours par bloquer avec un timeout.
Tout est très difficile... Voila un illustration :
shinmei $ wget http://www.openbsd.org/images/puffy35.gif --11:14:24-- http://www.openbsd.org/images/puffy35.gif => `puffy35.gif' Résolution de www.openbsd.org... 129.128.5.191 Connexion vers www.openbsd.org[129.128.5.191]:80...connecté. requête HTTP transmise, en attente de la réponse...200 OK Longueur: 81,395 [image/gif]
6% [=> ] 5,287 6.36K/s
Là il bloque et n'ira pas plus loin :(
Question idiote : ton accès ne serait pas un accès ADSL genre PPPoE par hasard ? Si oui as-tu bien set mtu max 1492 et set mru max 1492 dans l'équivalent de ppp.conf (je ne connais pas Open) ?
donc le schema localnet<->openbsd<->redhat<->model adsl ppoe<->internet redhat se connecte en pppoe en effet.
redhat n'a pas de problemes lorsque je fait la meme opération (le wget). openbsd non plus en revanche depuis le réseau local (windows ou linux) cela ne fonctionne pas et reste bloqué :/
Une session ssh sur openbsd finit toujours par bloquer avec un timeout.
Merci de ta réponse :)
Amicalement,
Seb :)
FAbrice
Sebastien Vincent
Emmanuel Dreyfus wrote:
Sebastien Vincent wrote:
donc le schema localnet<->openbsd<->redhat<->model adsl ppoe<->internet redhat se connecte en pppoe en effet.
Bon, ben l'affaire est entendue: un problème de MTU.
J'ai mis mtu 200 sur les deux interfaces d'openbsd pour tester.
Donc la tous les paquets sont coupes pour faire 200.
dans pf.conf (sur openbsd) : scrub in all fragment reassemble scrub out all fragment reassemble
A ce moment la, je crois avoir compris que j'ai demande a openbsd de prendre tous les paquets et de les reassembler puis refragmenter pour qu'il fassent 200 octets. (ce qui devrais passer des deux cotes)
donc le schema localnet<->openbsd<->redhat<->model adsl ppoe<->internet
redhat se connecte en pppoe en effet.
Bon, ben l'affaire est entendue: un problème de MTU.
J'ai mis mtu 200 sur les deux interfaces d'openbsd pour tester.
Donc la tous les paquets sont coupes pour faire 200.
dans pf.conf (sur openbsd) :
scrub in all fragment reassemble
scrub out all fragment reassemble
A ce moment la, je crois avoir compris que j'ai demande a openbsd
de prendre tous les paquets et de les reassembler puis refragmenter
pour qu'il fassent 200 octets. (ce qui devrais passer des deux cotes)
donc le schema localnet<->openbsd<->redhat<->model adsl ppoe<->internet redhat se connecte en pppoe en effet.
Bon, ben l'affaire est entendue: un problème de MTU.
J'ai mis mtu 200 sur les deux interfaces d'openbsd pour tester.
Donc la tous les paquets sont coupes pour faire 200.
dans pf.conf (sur openbsd) : scrub in all fragment reassemble scrub out all fragment reassemble
A ce moment la, je crois avoir compris que j'ai demande a openbsd de prendre tous les paquets et de les reassembler puis refragmenter pour qu'il fassent 200 octets. (ce qui devrais passer des deux cotes)
