Pages:
Actions
  • #97 par stefauresi le 26 Nov 2015
  • Ok j'ai trouvé, la norme 802.1p définit une inversion de prio 1 et prio 0 pour taguer les packets.

    Voici la configuration actuelle permettant de faire tout dans les règles de l'art et qui fonctionne parfaitement de mon côté (eh oui PF c'est carrèment mieux que les trucs crado avec netfilter :D).
    C'est le PF le plus simple avec une bonne sécurité pour le routeur OpenBSD. Pour rappel PacketFilter est stateful, donc seul les entrées autorisées d'un côté pourront revenir d'un autre. Il faut encore que j'affine cela pour avoir un bon filtrage pour l'IPv6 mais les hosts IPv4 sont bien protégés et le routeur n'a que SSH et HTTP d'actifs.

    wan_iface="vlan832"
    table <lan_v4> { 192.168.1.0/24 172.16.9.0/23 }

    block log               # block stateless traffic
    pass keep state         # establish keep-state
    block in log quick on $wan_iface inet proto tcp to port { ssh http } # Block ssh and http from WAN
    block in log quick on $wan_iface inet proto udp to port { syslog domain } # Block DNS and syslog from WAN

    # Tag packets on wan interface with vlan priority 0 (1 in PF because of 802.1p)
    match out on $wan_iface inet proto tcp set prio 1
    # nat clients to wan interface
    pass out quick on $wan_iface inet from <lan_v4> nat-to ($wan_iface) keep state

    J'ai du découper le set prio, ca a permi de corriger le pb et ca ne s'applique que sur TCP ici, je pense qu'un 2e match out qui ignore le port bootpc devrait faire l'affaire pour ceux qui aiment UDP :)

    Voici le bench actuel, c'est très satisfaisant


    En ce qui concerne l'IP je note que j'ai la même depuis plus de 24 heures

    Je valide donc ma configuration avec OpenBSD, très simple avec juste le paquet isc-dhcp-client

    Je commence les tests IPv6 avec dibbler bientôt et s'il faut à terme je filerai une image OpenBSD de mon routeur (sans les ID bien sûr) pour ceux qui veulent se monter ca sur un routeur (j'ai une alix board 2d13 en l'occurence)

    Bon boulot  8)

    tu penses que c'est faisable sur pfSense ?
  • #98 par kgersen le 26 Nov 2015
  • J'ai du découper le set prio, ca a permi de corriger le pb et ca ne s'applique que sur TCP ici, je pense qu'un 2e match out qui ignore le port bootpc devrait faire l'affaire pour ceux qui aiment UDP :)

    Chrome utilisent UDP a la place de TCP pour tout les acces aux serveurs Google, notamment Youtube.

    et pourquoi se limiter a TCP (ou TCP et UDP), il serait plus 'futur proof' de tout marquer a 1 sauf DHCP & ICMP.

    Ca sera d'autant plus vrai qu'avec IPv6 on peut avoir autre chose que TCP ou UDP.
  • #99 par nerzhul le 27 Nov 2015
  • @stefauresi pour la partie VLAN/DHCP ca ne devrait pas poser de souci si tu utilises aussi isc-dhcp, au pire si l'interface le fait pas, passe en console SSH et installe le paquet.
    Concernant la partie priorité, essaye ma ligne match ... set prio dans /etc/pf.conf et lance pfctl -nf /etc/pf.conf pour vérifier la syntaxe (ou man pf.conf). Je ne sais plus si le PF freebsd sait gérer la priorité VLAN directement. (d'ailleurs je ne sais plus si pfsense utilise PF ou IPFW, même si le nom de la distribution indique PF :p)
    Pour la partie UDP je vais faire quelques benchs
  • #100 par nerzhul le 27 Nov 2015
  • Je viens de compiler dibbler 1.0.1 (en changeant qq paths dans les defines du portage pour être BSD compliant) cela fonctionne avec la double option, je continue mes investigation afin de faire fonctionner complètement cette partie
  • #101 par nerzhul le 27 Nov 2015
  • Ca fonctionne avec dibbler + rtadvd, je finalise le script pour faire tout le bootstrap au propre car mine rien ya bcp de dynamisme à incorporer à cette IPv6.

    J'ai même une légèrement meilleure perf en Ipv6
  • #102 par stefauresi le 27 Nov 2015
  • tu as quoi comme offre jet , play ?
    Gros impact sur les perfs ?
  • #103 par nerzhul le 27 Nov 2015
  • Je suis en offre 100mbps donc c'est tout à fait raisonnable sachant que j'ai qq applis qui tournaient à côté et phones :)
  • #104 par nerzhul le 27 Nov 2015
  • Doc quasi complète, à finaliser

    Voici la configuration PF à appliquer pour être optimal avec de la sécurité sur IPv4 et IPv6 en bénéficiant du stateful PF, donc protégeant un maximum les hôtes locaux en IPv6 visibles d'Internet. Pas besoin de marquage ou quoi que ce soit, que ce soit en TCP,UDP,ICMP, IPv4 ou IPv6 le débit est au top avec cette configuration PF
    wan_iface="vlan832"
    table <lan_v4> { 192.168.1.0/24 172.16.9.0/23 }
    # Persist table to change it with dibbler and don't flush it on firewall modification
    table <lan_v6> persist

    block log               # block stateless traffic
    pass keep state         # establish keep-state
    block in log quick on $wan_iface inet proto tcp to port { ssh http } # Block ssh and http from WAN
    block in log quick on $wan_iface inet proto udp to port { syslog domain } # Block DNS and syslog from WAN
    block in log quick on $wan_iface inet6 proto tcp to port { ssh http } # Block ssh and http from WAN
    block in log quick on $wan_iface inet6 proto udp to port { syslog domain } # Block DNS and syslog from WAN
    block in log quick on $wan_iface inet6 to <lan_v6> # Block incoming IPv6 trafic non sollicited by local LAN hosts

    # Tag every TCP packets on wan interface with vlan priority 0 (1 in PF because of 802.1p), in IPv4 & IPv6
    match out on $wan_iface proto { tcp udp } set prio 1
    # nat clients to wan interface in IPv6
    pass out quick on $wan_iface inet from <lan_v4> nat-to ($wan_iface) keep state
    pass out quick on $wan_iface inet6 from <lan_v6> keep state

    Configuration du dhclient natif OpenBSD
    interface "vlan832" {
            send dhcp-class-identifier "sagem";
            send user-class "+FSVDSL_livebox.Internet.softathome.Livebox3";
            send option-90 00:00:00:00:00:00:00:00:00:00:00:66:74:69:XX:XX:XX:XX:XX:XX:XX:XX;
    }

    Puis activation au boot:
    echo "dhclient vlan832&" >> /etc/rc.local

    Configuration de dibbler 1.0.1 compilé (/etc/dibbler/client.conf)
    downlink-prefix-ifaces "none"
    script "/etc/dibbler/rtadvd.sh"
    iface "vlan832" {
            pd
            option 16 hex 00:00:04:0e:00:05:73:61:67:65:6d
            option 15 hex 00:2b:46:53:56:44:53:4c:5f:6c:69:76:65:62:6f:78:2e:49:6e:74:65:72:6e:65:74:2e:73:6f:xxxx
    66:74:61:74:68:6f:6d:65:2e:6c:69:76:65:62:6f:78:33
            option 11 hex 00:00:00:00:00:00:00:00:00:00:00:66:74:xx:xx:xx:xx:xx:xx:xx:xx:xx
            option 11 hex 00:00:00:00:00:00:00:00:00:00:00:66:74:xx:xx:xx:xx:xx:xx:xx:xx:xx
    }
    Tout comme sous Linux, il est obligatoire d'avoir 2x l'option 11
    A revérifier mais pas besoin de mettre la route par défaut dibbler la met automatiquement sous OpenBSD (il faut le lancer en root)
    default                            fe80::ba0:bab%vlan832          UG         0    13235     -    56 vlan832

    Concernant le router advertisement OpenBSD fournit l'outil natif pour le faire. Voici le script (à améliorer pour ajouter les DNS locaux au routeur dedans). Remplacez vether0 par le nom de l'interface de votre LAN (dans mon cas vether0 est une interface loopback branchée sur un bridge contenant quelques interfaces de mon LAN)

    #! /bin/sh
    if [ $SRV_MESSAGE = "REPLY" ]; then
    cat >/etc/rtadvd.conf <<EOF
    vether0:\\
            :addr="${PREFIX1}":prefixlen#64:

    EOF

    # Set rtadvd starting flags, adding prefix to PF for setting the correct firewall outgoing rules
    rcctl set rtadvd flags " vether0"
    pfctl -t lan_v6 -T flush
    pfctl -t lan_v6 -T add "${PREFIX1}/64"

    # restart rtadvd
    for P in $(pgrep rtadvd); do
            kill ${P}
    done
    rcctl start rtadvd

    Voici les bench, c'est très satisfaisant (offre 100Mbps)



    Petite note subsidiaire, j'ai un second réseau pour mon wifi ajouté sur un second /64 statiquement dans le rtadvd et ca marche parfaitement avec Android :)
  • #105 par fouinix le 27 Nov 2015
  • Beau travail!
  • #106 par kgersen le 27 Nov 2015
  • block in log quick on $wan_iface inet6 to <lan_v6> # Block incoming IPv6 trafic non sollicited by local LAN hosts
    si je lit bien ca bloque tout meme ICMPv6 (y'a qu'un match sur des adresses et pas le contenu) ?

    Attention avec IPv6 il ne faut pas bloquer tout ICMPv6. on peut bloquer le ping (type 128/129), les RA/RD/NS/ND etc mais il faut au moins laisser entrer :

    Destination inaccessible (ICMPv6 entrant, type 1)
    Paquet trop important (ICMPv6 entrant,type 2)
    temps dépassé (ICMPv6 entrant , type 3)
    problème de paramètres (ICMPv6 entrant, type 4)

    soit les types 1 a 4 (voir les roles types ici: http://tools.ietf.org/html/rfc4443 )

    voir : https://www.ietf.org/rfc/rfc4890.txt (4.3.1) pour plus de détails.

    Par exemple ne pas laisser entrer le type 2 (Paquet trop important) peut perturber les connexions sortantes:

    En IPv6 il n'y a pas de fragmentation en cours d'acheminement. C'est donc a l'èmetteur de réduire le paquet si le path (mtu) est trop petit pour celui-ci. Pour ce faire quand un paquet trop grand est détecté quelque part sur le chemin, le routeur qui ne peut le gérer renvoi un ICMPv6 type 2 a l'èmetteur d'origine du paquet. La source est donc prévenu que le paquet n'a pas été acheminé jusqu'au bout et peut agir (réémission avec une taille plus petite ou signaler une erreur a la couche applicative).
    Si l'ICMPv6 type 2 est bloqué et n'arrive pas a l'èmetteur d'origine, ce dernier va attendre un timeout de connexion (si c'est du tcp par exemple) ce qui peut être long et il ne saura jamais comment établir une connexion avec cette destination.

    Il faut donc voir si le statefull firewall autorise une entrée ICMPv6 correspondant a une sortie IPv6 (j'en doute c'est pas le même protocole niv 4 et en plus c'est pas forcement la même source de retour). Sinon et c'est plus probable il faut autoriser ,au moins, les 4 premiers types pour un bon fonctionnement d'IPv6.
  • #107 par nerzhul le 27 Nov 2015
  • kgersen, OpenBSD gère tous ces cas hors de PF directement si mes souvenirs sont bons, j'avais mis en prod plusieurs routeurs OpenBSD IPv6 il y a de cela 2 ans et aucun souci pour des serveurs à 2K connexions concurrentes. Pf est stateful et un minimum intelligent, comparé à netfilter. L'équipe OpenBSD a fait un gros travail sur IPv6 ces 2 dernières années
  • #108 par nerzhul le 28 Nov 2015
  • Grâce à la team OpenBSD je me suis rendu compte que nous n'avons pas besoin d'isc-dhcp-client mais uniquement du dhclient natif ! merci à eux.
    Le post précédent détaillé a été mis à jour en conséquence
Pages:
Actions