Salut,
 
nous avons 2 firewall (packet filter sur openbsd) qui servent à faire du routage entre plusieurs VRF sur notre réseau.
Ca marche tres bien.
 
Cependant, malgré la lecture de ce que je peux trouver sur internet, je n'arrive pas à autoriser, entre un serveur de la VRF1 et les switchs de la VRF2, le tftp (utilisé afin de sauvegarder la conf de ces switchs)
Au niveau du firewall, VRF = VLAN
 
A priori il faut utiliser tftp-proxy mais apres je seche. Je n'ai pas de NAT, et tout les exemples que je trouve en ont.
Si quelqu'un a deja mis ca en place, et peut m'aider, je lui en serai grandement reconnaissant.
 
(tout ce qui est routage est ok, le serveur accède sans probleme aux switchs de la vrf2, en snmp et ssh)
 
Merci de votre aide

Si je ne me trompe pas pas, il me semble que le tftp-proxy est utilisé dans les cas de LAN derriere un nat.  
 
Avec une regle simple autorisant le tftp a sortir du serveur vers le switch ca passe pas ?  
Quelque chose comme ca :
pass out quick on $if from $me to $switch proto udp port = 69
 
 
Sinon si tu log tes regles bloquantes, ca devrait te permettre de voir quelle regle bloque le tftp.

Alors
 
Le serveur tftp est sur le serveur X
On a un script, qui par snmp modifie un oid sur le switch, ce qui lui dit d'initialiser la connexion vers ce serveur TFTP pour sauvegarder sa conf.
Entre ces 2 "objets", y'a le PF
 
Si je regarde dans les logs j'ai :
- l'initialisation de la connexion en snmp depuis le serveur vers le switch (pass)
- une reponse du switch vers le serveur, en tftp (pass)
- et ensuite pleins de block, du serveur vers le switch, port 54257 udp, puis au bout d'un moment il réessaye de faire du tftp (pass), et les ports derriere sont plus les memes, 63086 puis 54257, en udp tjs
 
Si les ports changent tout le temps, je vois pas trop comment faire
 

le tftp ecoute sur le port 69. Faut voir si t'as pas une option qui permet de figer ce port.  
 
Ton serveur tftp il est bien sur le switch ? Ou dit autrement, c'est le switch qui si connecte sur un serveur tftp pour y deposer le fichier ? Ou dans l'autre sens, c'est un client qui vient se connecter sur le serveur tftp du switch pour y recuperer le fichier ?

Non le TFTP est sur le serveur, c'est le switch qui vient s'y connecter (sur le port 69)
Seulement apres, on dirait que le serveur lui répond, sur un port totalement different. Pour faire quoi va savoir
Ce truc tourne sur une vieille Debian, avec tftpd, j'ai cherché mais j'ai l'impression qu'y a aucune option

A dans ce cas la , ca change la donne. Donc la premiere regle est celle ci
pass in quick on $if from $switch to $me port = 69
Mais je pense que tu l'as deja
 
Tu l'auras remarqué aussi tftp utilise un port aleatoire par la suite. Si le serveur tftp n'a pas d'option pour figer la plage de ports ,ca va etre difficile voir impossible de definir les ports utilisés.  
Tu peux par contre utilisé une regle un peux plus generaliste et moins sécuritaire c'est vrai mais c'est un switch a l'autre bout.  
pass out quick on $if from $me to $switch
 
Ca devrait autoriser tout le traffic du serveur vers le switch quelque soit le port.  
 
Y'a peut etre moyen de faire plus sécuriser avec tftp-proxy. Mais test deja avec ca pour voir. Ca devrait faire l'affaire je pense.

Ouais c'est ce que j'ai fait.
J'ai ouvert entre les switchs et ce serveur la sur la plage 45000:65000 (grosso merdo les ports qu'il utilise ensuite ce con)
C'est pas propre, mais vu que c'est limité vers des switchs ca risque pas gd chose.

On a tjs le projet d'upgrader le serveur sur lequel les sauvegardes se font, on verra a ce moment la pour changer la methode ou prendre un tftp plus configurable.

PS : j'ai remarqué que tu utilise tjs le quick. Je ne l'utilise jamais. C'est juste une préference que tu as ou c'est conseillé ?
PS2 : me semble que dans mon cas j'utilise pas les pass in/pass out, vu que c'est pas sur ce serveur que le tftp tourne

le TFTP c'est comme FTP tu as une connexion control (21 : ftp, 69 : tftp) et une connexion data sur un port aléatoire.
 
Si ton FW ne comprend pas le protocole TFTP ça fonctionnera pas, à moins d'autoriser tout UDP entre les deux machines.

PS1: C'est le principe des First Rule Match (avec quick) et Last Rule Match (sans quick).  
C'est deux facons différentes d'écrire les règles mais sur des routeurs et/ou firewalls avec beaucoup de charges et beaucoup de regles, ca peu avoir une incidence sur les performances.  
J'ai commencer a écrire mes premieres regles pour ipf avec quick et du coup j'ai gardé mes petites habitudes pour pf
 
PS2: j'avais compris que le serveur tftp etait sur le serveur, dans ce cas la c'est pas obligatoire de mettre de in ou out, c'est de la traversée de routeur que tu fais. Rajouté le in/out et le "on $interface" peut aider a clarifier les regles quand tu travaille sur une interface précise

PS1 : ok c'est bien ce qu'il me semblait. Je continue sans j'ai plus l'habitude j'ai commencé sous PF
 
PS2 :  C'est pas grave. C'etait juste pour etre sur.
Ouais c'est ca. Il route et laisse passé ce que je lui demande (toutes mes regles sont de la forme from $xxx to $yyyy

Si tu as une methode pour qu'il le comprenne je veux bien

J'ai du me perdre quelque part.  
Ton serveur de sauvegarde et ton routeur, c'est la meme machine ?

non  
Mon routeur est au milieu

Alors pour tester, tu peux faire ca
 
ajouter a la fin du fichier /etc/inetd.conf
6969 dgram udp wait root /usr/libexec/tftp-proxy tftp-proxy
 
et ensuite redemarrer inetd
/etc/rc.d/inetd restart
 
Dans ton fichier de conf de pf, rajoute ceci avant tes regles de filtrage
 
rdr-anchor "tftp-proxy/*"
rdr on $if proto udp from $switch to port tftp -> \
    127.0.0.1 port 6969
 
et remplace tes regle concernant le tftp par ceci
 
anchor "tftp-proxy/*"
pass proto udp from $switch to $serveur_tftp port = 69
 

Je teste de ce pas

Par contre dans la regle
rdr on $if proto udp from $switch to port tftp -> \
    127.0.0.1 port 6969

Le $if je mets quoi ? l'interface vlan sur lequel arrive la demande du switch ?

EDIT: je n'ai pas de /etc/rc.d
ok il etait pas lancé (inetd) et sous openbsd pour le relancer c'est un kill -HUP

Le tcpdump me donne ca maintenant :

rule 0/(match) [uid 0, pid 16811] block in on vlan191: switch1.domain.local.51093 > localhost.my.domain.6969: udp 23 (ttl 253, id 0, len 51)

Merci bcp de ton aide
On avance

Ah oui pardon, c'est vrai que t'es sur une open et moi sur free
 
pour le rdr c'est bien ca, l'interface sur laquelle arrivent les paquets du switch
 
on va essayer d'avancer a petit pas
 
si tu modifie la  
pass proto udp from $switch to $serveur_tftp port = 69
 
en  
pass proto udp from $switch to $serveur_tftp port = 6969
 
ca donne quoi ?

Pareil  
 
rule 0/(match) [uid 0, pid 27399] block in on vlan191: switch1.domain.local.56950 > localhost.my.domain.6969: udp 23 (ttl 253, id 0, len 51)

Je debute, mais on lui dit dans la regle, pass to $serveur_tftp, hors lui essaye de faire un pass to $localhost pour l'instant

c'est pas la que ca gene ?

Juste pour voir si le probleme ne vient pas de la position de la regle, est ce que tu peux rajouter quick a la regle ?  
 
pass quick proto udp from $switch to $serveur_tftp port = 6969

Non ca fait pareil

je viens de relire ma conf et il se peut que t'ai raison
 
pass proto udp from $switch to localhost port = 6969
 
ca donne quoi ?

Ca marche avec localhost !
Merci
 
Par contre question.
Est ce le fait que tout est autorisé en sortie depuis les FW qui fait que je n'ai pas a rajouté quelque chose entre le localhost (tftp_proxy dans ce cas) et le serveur tftp ?
 
Pour l'instant ca me gene pas, mais si je voulais bloquer des choses en sortie, faudrait que je rajoute quelle regle ensuite ?

Oui ca vient de la. Des que tu filtrera aussi l'interface de sortie il faudra rajouter les regles pour le tftp-proxy entre le routeur et le tftpd.
 
J'ai pas encore eu a le faire, mais je pense ne pas me tromper si je te dis que la premiere sera celle ci
 
pass proto udp from localhost to $srv_tftp port = 69
 
Mais la deuxieme, je ne sais pas. Je vais voir si je ne trouve pas quelque chose d'interessant

D'un autre coté je compte pas vraiment filtrer en sortie du fw en fait.
Ca me semble quand meme suffisament sécure pour ne pas avoir a le faire.
 
Par contre de quel deuxieme regle tu parles ?

C'est toujours l'histoire des deux connections, l'une pour les commmandes et l'autre pour les datas, la premiere sur le port 69 et la seconde sur un port aléatoire.  
 
En regardant rapidement, j'ai trouver quelque chose qui pourrait faire avancer le schmilimililiblick. C'est pas directement pour le tftp-proxy mais pour le ftp-proxy. Mais les deux sont assez proches.  
Tu peux jeter un coup d'oeil a cet article ci http://blog.garnett.fr/?p=17. Ca m'a l'air assez interessant.  
 
En tous cas, je suis ravi d'avoir pu t'aider, ca m'a permis de me remettre un peu dans le pf.conf, chose que j'avais pas fait depuis quelques mois .

Je suis egalement ravi que tu ais pu m'aider
Merci bcp
 

Tiens tant que je te tiens
 
Au niveau outil, a coté de PF, pour monitoré l'activité par exemple, y'a quoi de bien ?

Je sais pas trop, je me pas encore pencher sur ce point la.
Faudrait queje prenne le temps d'étudier un peu tout ca bientot.

Ok
 
Si t'as l'occas revient ici donner  ce que t'as trouvé

Je remonte mon sujet
 
J'ai mis en place la meme chose pour le ftp
Ca fonctionne tres bien sur un serveur linux hebergeant un serveur ftp
Par contre j'ai des éléments SAN, qui doivent se mettre à jour via FTP, et impossible de se connecter dessus a travers le fw.
Apres recherche il semble que lors de la connexion, le serveur ftp fait une requete auth (113) vers le client, mais avec le ftp-proxy ca ne marche pas (est ce qu'il répond au fw ce qui du coup ne peut fonctionner, ou autre, j'en sais rien)
 
Si quelqu'un a une idée je suis preneur

salut,
 
Moi j'aurais fait, si tes SAN le proposent du SFTP via SSH. Bien souvent les SAN tournent sous Nux, et il y a souvent moyen de rajouter des services via une petite compilation maison.
Mais je ne m'avance pas, ne connaissant pas la marque/le modèle de ton matos.
Bon courage !

Sur un SAN a 200 000€ piece (et on en a 2) je m'amuse pas à compiler un truc
EN plus c'est du netapp, l'os est proprio je pense.

J'ai resolu le probleme de maniere degueux en autorisant la requete auth vers le ftp proxy, ca marche

Un nouveau remontage du topic
 
Dans packet filter, est ce qu'il est possible de spécifier un range d'adresse ip sans utiliser de masque ?
Ex : autorisé quelque chose vers les adresses ip de 192.168.1.10 > 192.168.1.65 ?
J'ai beau cherché je trouve que des exemples avec un masque

Intrigué par tes dires, j'ai regarder un peu de mon coté, et j'ai pas trouvé grand chose non plus.  
 
En alternative, tu peux déclarer une table avec la plage d'adresse dedans, ça peut etre long à faire manuellement (mais ça se script )
Ca te donne de la souplesse par la suite, parce que tu peux retirer une adresse de la table (même une qui est en plein milieu de ta plage) et inversement, rajouter une adresse même si elle est pas dans ta plage.
 
J'étais presque sûr qu'on pouvais utiliser des plages dans pf. Je sais que ca marche pour les ports.

oui pour les ports j'ai trouvé aussi mais rien pour les ip
C'est bizarre quand meme

pour la table oui c'est une solution, mais y'a 199 adresses donc outre le temps pour le saisir, ca va me faire un fichier bien degueux (meme si je dois pouvoir faire un /24 + ! des adresses qui restent ca en fera un peu moins)

Pour la saisie, une ligne comme celle la :  
 

 
a rediriger au bon endroit ca te donne la plage qui va bien, reste à la déclarer dans pf ensuite.