Bonjour,
je me trouve confronté à un problème avec natd et ipfw ; je me décide donc à
poster suite à plusieurs jours d'arrachage de cheveux...
Je tourne sous FreeBSD 4.8, avec deux interfaces ethernet : rl0 en DHCP
(connectée à un modem ADSL qui fait aussi serveur DHCP) et rl1 avec une IP
fixe 192.168.0.11 et qui sert de passerelle ADSL ou autre pour tout mon
réseau local. La translation d'adresse s'effectue bien, je n'ai aucun
problème de reconnexion à mon FAI, etc.
J'ai donc décidé de construire un pare-feu avec ipfw : handbook et diverses
docs de rigueur (onlamp, etc)... Ca marche bien, je suis content de mon
firewall, sauf... que je n'ai plus de connexion internet sur mon réseau
local ! plus de translation d'adresses ! plus de passerelle sur rl1 !
Quelqu'un peut m'aider ? regarder mes fichiers de configuration ci-dessous ?
Merci d'avance.
add 00050 divert natd all from any to any via rl0
add 00100 pass all from any to any via lo0
add 00200 deny all from any to 127.0.0.0/8
add 00300 deny ip from 127.0.0.0/8 to any
#from man 8 ipfw: allow only outbound TCP connections I've created
add 00301 check-state
add 00302 deny tcp from any to any in established
add 00303 allow tcp from any to any out setup keep-state
#allow DNS
add 00400 allow udp from 80.10.246.130 53 to any in recv rl0
add 00401 allow udp from any to any out
#allow DHCP
add 00501 allow udp from 81.249.237.84 67 to any 68 in via rl0
add 00502 allow udp from any 68 to 255.255.255.255 67 out via rl0
add 00503 allow udp from any 67 to 255.255.255.255 68 in via rl0
#allow some icmp types (codes not supported)
##########allow path-mtu in both directions
add 00600 allow icmp from any to any icmptypes 3
##########allow source quench in and out
add 00601 allow icmp from any to any icmptypes 4
##########allow me to ping out and receive response back
add 00602 allow icmp from any to any icmptypes 8 out
add 00603 allow icmp from any to any icmptypes 0 in
#########allow me to run traceroute
add 00604 allow icmp from any to any icmptypes 11 in
LES OPTIONS DU KERNEL :
options IPFIREWALL #firewall
options IPDIVERT #divert sockets
options IPFIREWALL_VERBOSE #print information about
#dropped packets
options IPFIREWALL_VERBOSE_LIMIT=10 #limit verbosity
options IPSTEALTH
65535 9642 484246 deny ip from any to any Ceux-là il faudrait les voir, il y en a beaucoup...
Tu peux ajouter une règle comme: ipfw add 65534 deny log ip from any to any
et regarder dans /var/log/security les paquets qui sont rejetés par la règle 65534
Merci pour la réponse
Je viens d'appliquer cette règle, il est logique que les paquets soient rejetés par rl0, mais je ne sais quoi faire pour avancer :-( les lignes 301, 302, 303 vous semblent indispensables pour un bon pare-feu ? on peut pas faire plus simple ?
Sylvain Tertois wrote:
ferdydurke a écrit:
65535 9642 484246 deny ip from any to any
Ceux-là il faudrait les voir, il y en a beaucoup...
Tu peux ajouter une règle comme:
ipfw add 65534 deny log ip from any to any
et regarder dans /var/log/security les paquets qui sont rejetés par la
règle 65534
Merci pour la réponse
Je viens d'appliquer cette règle, il est logique que les paquets soient
rejetés par rl0, mais je ne sais quoi faire pour avancer :-(
les lignes 301, 302, 303 vous semblent indispensables pour un bon pare-feu ?
on peut pas faire plus simple ?
65535 9642 484246 deny ip from any to any Ceux-là il faudrait les voir, il y en a beaucoup...
Tu peux ajouter une règle comme: ipfw add 65534 deny log ip from any to any
et regarder dans /var/log/security les paquets qui sont rejetés par la règle 65534
Merci pour la réponse
Je viens d'appliquer cette règle, il est logique que les paquets soient rejetés par rl0, mais je ne sais quoi faire pour avancer :-( les lignes 301, 302, 303 vous semblent indispensables pour un bon pare-feu ? on peut pas faire plus simple ?
Sylvain Tertois
ferdydurke a écrit:
Je viens d'appliquer cette règle, il est logique que les paquets soient rejetés par rl0, mais je ne sais quoi faire pour avancer :-( les lignes 301, 302, 303 vous semblent indispensables pour un bon pare-feu ? on peut pas faire plus simple ?
Personnellement je n'ai jamais utiliser check-state, je ne peux pas répondre l dessus. Ensuite pour l'autre elle ne me semble pas indispensable. Le NAT va effectivement empécher une machine de l'extérieur se connecter sur une machine de ton réseau local. Il reste la machine elle-même à protéger un peu.
-- Sylvain
ferdydurke a écrit:
Je viens d'appliquer cette règle, il est logique que les paquets soient
rejetés par rl0, mais je ne sais quoi faire pour avancer :-(
les lignes 301, 302, 303 vous semblent indispensables pour un bon pare-feu ?
on peut pas faire plus simple ?
Personnellement je n'ai jamais utiliser check-state, je ne peux pas répondre l
dessus.
Ensuite pour l'autre elle ne me semble pas indispensable. Le NAT va
effectivement empécher une machine de l'extérieur se connecter sur une
machine de ton réseau local. Il reste la machine elle-même à protéger un
peu.
Je viens d'appliquer cette règle, il est logique que les paquets soient rejetés par rl0, mais je ne sais quoi faire pour avancer :-( les lignes 301, 302, 303 vous semblent indispensables pour un bon pare-feu ? on peut pas faire plus simple ?
Personnellement je n'ai jamais utiliser check-state, je ne peux pas répondre l dessus. Ensuite pour l'autre elle ne me semble pas indispensable. Le NAT va effectivement empécher une machine de l'extérieur se connecter sur une machine de ton réseau local. Il reste la machine elle-même à protéger un peu.
