Newsgroup: it.comp.os.openbsd
Titolo: PF, NAT e filtering

Ciao a tutti,
sto configurando il NAT su OpenBSD 3.5 e incappo nel seguente problema:
nat pass on fxp1 from vlan11:network to any -> fxp1
Nonostante nell FAQ di PF alla sezione NAT dica che usando pass nel
comando nat si evita che i pacchetti nattati vengano filtrati la cosa non
funziona. Ad esempio tentando un traceroute da una macchina sulla rete
interna verso internet:
Dec 15 10:59:55.466612 rule 0/0(match): block in on vlan11:
172.16.1.50.39189 > 151.1.1.1.33435:  udp 10 [ttl 1]
o un ping:
Dec 15 11:02:16.230635 rule 0/0(match): block in on vlan11: 172.16.1.50 >
151.1.1.1
: icmp: echo request (DF)
vlan11 è l'interfaccia della rete uffici, fxp1 quella esterna.
Idee?
ciao
Luca



Me ne viene solo una (Thorin ha ragione, senza vedere il resto delle
regole e' un po' uno sparo nel buio!):
hai una regola di blocco "quick" prima della regola in questione; se fosse
dopo dovrebbe essere bypassata
Mi associo al pfctl -sr di Thorin.
Ciao
C.
-- 
Per contattarmi, toglimi il gesso!
Hi, I'm a .signature virus! Copy me to your .signature file and
help me propagate, thanks!

 pfctl -sr
Certo che c'e' un block all dopo il NAT, ma qual'e' allora il significato
di "nat pass"?
#pfctl -sr
scrub in all fragment reassemble
block drop log all
pass quick on lo0 all
pass in on vlan11 inet proto tcp from 
172.16.1.0/24
 to 172.16.1.171 port = ssh keep state
Devo accettare esplicitamente i pacchetti che devo nattare in ingresso
sull'interfaccia della LAN?
ciao
luca

 sull'interfaccia della LAN?
Guarda, io ho sempre interpretato le pf-faq nello stesso modo in cui le 
interpreti tu (ma non ho mai usato nat con OpenBSD, lo utilizzo come 
firewall/transparent bridge, quindi non ho esperienze dirette in 
merito). D'altra parte la sezione TRANSLATION di man pf.conf dice:
Since translation occurs before filtering the filter engine will see 
packets as they look after any addresses and ports have been translated.
Filter rules will therefore have to filter based on the translated 
address and port number.  Packets that match a translation rule are only 
automatically passed if the pass modifier is given, otherwise they are 
still subject to block and pass rules.
A meno che... aspetta un po' ma non hai scritto che vlan11 e' 
l'interfaccia interna e fxp1 quella esterna? Allora hai sbagliato la 
regola. Prova
nat pass on vlan11 from vlan11:network to any -> fxp1


 nat pass on vlan11 from vlan11:network to any -> fxp1
Non funziona nemmeno cosi'
Dec 15 16:02:02.798900 rule 0/0(match): block in on vlan11: 172.16.1.54 >
151.1.1.1
: icmp: echo request (DF)
La cosa che mi insospettisce pero' è che se il pacchetto venisse davvero
NATtato ma non passasse dal filtering io dovrei comunque vedere il nel log
come indirizzo sorgente quello di fxp1 (pubblico) mentre vedo quello del
client sulla LAN (172.16.1.54).
ciao
Luca

 nat pass on vlan11 from vlan11:network to any -> fxp1
Secondo me no, di solito si natta sull'interfaccia esterna (in questo
momento mi viene comodo pensare al POSTROUTING di netfilter su linux)
Secondo me il problema e` un'altro, non e` che ad esempio su fxp1 i
pacchetti passerebbero ma in realta` si schiantano su vlan11 in
ingresso?
-- 
Vuoi fare colpo su di lei con me?
Fai colpo su di lei con me! Fai colpo su di lei con me!
[Dr. Gonzo : Paura e delirio a Las Vegas]

 Dec 15 10:59:55.466612 rule 0/0(match): block in on vlan11:
                                                      ^^^^^^
Scusami, ho mandato il messaggio troppo presto :-)
L'errore dovrebbe proprio essere quello qui sopra, e infatti il
traffico si blocca su vlan11 e non sull'interfaccia interna.
Il filtraggio in pf avviene per interfaccia, e tu non devi avergli
detto che il traffico con sorgente la lan dietro a vlan11 puo` passare
da vlan11.


 nat pass on fxp1 from vlan11:network to any -> fxp1
Prova a mettere:
nat pass on fxp1 from vlan11:network to any -> (fxp1)
oppure
nat pass on fxp1 from vlan11:network to any -> $indirizzo_ip_di_fxp1
e vedi se e` la stessa cosa.
Hai abilitato esplicitamente il traffivo in ingresso dalla lan alla
tua macchina su vlan11 con una regola come quella sotto?
pass in on vlan11 from vlan11:network to any
HTH


 ingresso?
Esatto, ma non riesco a capire come mai, dato che gli ho dato al
comando nat l'opzione pass che dovrebbe fare esattamente quello:
<QUOTE1>
Packets that match a translation rule are only 
automatically passed if the pass modifier is given, otherwise they are 
still subject to block and pass rules.
</QUOTE1>
Come ho risposto a cecchino dai log risultano bloccati i pacchetti in
ingresso su vlan11 e hanno l'indirizzo sorgente non NATTATO, quindi il mio
dubbio è che il nat non venga fatto altrimenti dovrebbero passare, o
comunque dovrei vedere l'indirizzo su cui natto e non quello sorgente nei
log di pf:
<QUOTE2>
Since translation occurs before filtering the filter engine will see 
packets as they look after any addresses and ports have been translated.
Filter rules will therefore have to filter based on the translated 
address and port number.
</QUOTE2>
Per capirci:
client 172.16.1.54
firewall_lan 172.16.1.171
firewall_wan ip pubblico
Se faccio partire un ping dal client i log di PF dicono
Dec 15 16:02:02.798900 rule 0/0(match): block in on vlan11: 172.16.1.54 >
151.1.1.1
: icmp: echo request (DF)
Quello che mi sembra succeda è che il pacchetto viene loggato
durante il filtering perche' l'ip del client non è stato nattato in
uscita.
ciao
Luca

 da vlan11.
Ti prego di leggere il mio reply al tuo messaggio piu' giu nel thread,
perche' per come la vedo io non dovrebbe essere necessario accettare quel
traffico in ingresso.
ciao
Luca

 da vlan11.
Effettivamente aggiungendo questa regola:
pass in on vlan11 from vlan11:network to ! ip_lan_firewall keep
state
il tutto funziona, ma è in aperta contraddizione con quanto scritto nella
documentazione...
ciao
Luca

 
OK, premesso che piu' su avevo scritto una caxxata (evidentemente avevo 
gia' spento il cervello, se avessi letto meglio gli esempi mi sarei 
accorto di un simpatico "!" subito dopo "on" nella regola che avevo 
visto...) le righe del manuale (non delle faq) che ho riportato 
sembrerebbero dire che, in presenza di un nat con pass, le altre regole 
relative a quei pacchetti non vengono proprio valutate... bene, 
evidentemente non e' cosi'.


 evidentemente non e' cosi'.
OK, dopo altre 4 passate di RTFM la situazione e' piu' chiara, ed 
ovviamente hanno ragione ouz e Thorin: i pacchetti nattati con pass non 
subiscono piu' alcun filtro, ma se non si mette una regola per farli 
passare in ingresso all'interfaccia "interna" non arrivano neanche ad 
essere nattati. Diciamo che potevano scriverlo meglio? Oppure 
applichiamo al sottoscritto cio' che Cruyff disse di Van Basten: "invece 
di ingessargli la caviglia avrebbero fatto meglio ad ingessargli il 
cervello"?


 Scusa ma le regole sono tutto qua?
Per il momento si, essendo il mio primo firewall con PF.
Grazie a tutti per l'aiuto.
Luca

 Luca


 uscita.
No, non e` per quello, anche se non riesco cosi` al volo a trovare in
pf.conf(5) una spiegazione chiara e semplice (pero` io avro` dovuto
impararlo da qualche parte, quindi sono sicuro che leggendo bene ci
sia sicuramente :-P).
+++
Per la cronaca, io sulla mia lan (casalinga) apro tutto in ingresso
sull'interfaccia interna, e filtro e natto solo sull'interfaccia
esterna.
Cioe`, le regole di filtraggio sono circa cosi` (supponendo ci sia un
nat sull'interfaccia esterna):
pass in quick on $int_if from $int_if:network to any
pass out quick on $int_if from any to $int_if:network
pass out quick on $ext_if proto tcp from ($ext_if) to any modulate state
pass out quick on $ext_if proto udp from ($ext_if) to any keep state
Spero che il discorso sia un po' piu` chiaro :-)


 evidentemente non e' cosi'.
Nono, dai, non esageriamo.  Se la FAQ dice qualcosa e voi vi accorgete
che in realta` non succede cosi` come fate a dire che la FAQ dice
qualcosa di sbagliato :-) Siete *sicuramente* voi a malinterpretare
qualcosa :-P    (volutamente ironica ma non del tutto falsa)
La FAQ dice " Packets that match a translation rule are only
automatically passed if the pass modifier is given", e quei pacchetti
non matchano la regola di nat, visto che la regola di nat e` "on
$ext_if" e quei pacchetti, evidentemente, sono su $int_if prima di
poter arrivare a $ext_if.
C'e` una regole di "pass in" che permette quel traffico su $int_if ?
No e quindi l'unica regola che matcha quel pacchetto e` il default
block all'inizio (rule 0/0).
Curiosita`: per caso provenite da iptables/netfilter?  Se la risposta
e` si secondo me e` quello a confondere: in pf non esiste il concetto
equivalente alla chain FORWARD (anche io sono stato confuso dalla
stessa cosa, inizialmente, quindi vi capisco bene :-))
Ciao,
Vale.


 ingessargli il cervello"?
ROTFL  :-)


 stessa cosa, inizialmente, quindi vi capisco bene :-))
No, provengo... da IPF :-) !!!
Uso OpenBSD dalla release 2.8, ma come ho scritto altrove mi e' sempre
servita per firewall di tipo transparent bridge (magari con qualche
opzione piu' avanzata come queueing, tagging etc.) e quindi sul nat con
pf  non avevo riscontri sperimentali... comunque grazie, mi hai
chiarito una cosa sulla quale in futuro avrei potuto scornarmi!


 rdr on fxp0 inet proto tcp from any to any port = ftp -> 127.0.0.1 port 8021
Cosi' vedo le regole di NAT/RDR che dovrebbero essere applicate pero', non
quello che realmente succede...
ciao
Luca

 [1] Quando carichi il firewall non si lamenta?
No.
ciao
Luca

 Spero che il discorso sia un po' piu` chiaro :-)
Ok, adesso mi è tutto più chiaro, ti ringrazio.
ciao
Luca

 etc.)
Bene, anche di questo parleremo: a me e` rimasto piu` di un dubbio su
altq...
Ciao :-)
Vale.
[1] Cosa che non sono affatto, e` giusto per entrare nello spirito di
OpenBSD :-D


 
Ciao


 Diciamo che potevano scriverlo meglio?
<firestarter>
Eh...e poi dicono che iptables è incasinato...:-)
</firestarter>
/me scappa.

 
http://www.openbsd.org/faq/pf/index.html
Sono le mie compagne di viaggio.
ciao
Luca

 risponde al tuo quesito.
Gia' visto, grazie. Ancora meglio da pflog0.
ciao
Luca

 No.
Strano, non so che dirti, appena posso faccio un paio di prove.
Ciao


 <firestarter>
Si vabbe`, anche a me piacciono i prodigy, pero` forse non e` il caso
di parlarne su un gruppo dedicato a OpenBSD.
BTW preferisco smack my bitch up :-)


 un po' "anarchici" fa comodo!!!)
Vero :)
Ciao


 
Il problema e' che l'interfaccia di bridge e' simmetrica, percio' su di
essa non si puo' definire chi e' "in" e chi e' "out", cosa che si puo'
invece fare sulle sue costituenti. Se tu fai una regola del tipo 
block in on bridge0 proto tcp from any to any port ssh
bloccherebbe l'accesso ssh da Internet verso la LAN o viceversa?
Ora di andare a dormire, per me! Domani mi tocchera' trovare una nuova
signature (gesso -quello vero- tolto, era ora!!!).
Ciao
C.
-- 
Per contattarmi, toglimi il gesso!
Hi, I'm a .signature virus! Copy me to your .signature file and
help me propagate, thanks!

 pfctl -ss
Sono due cose differenti. Avendo messo come policy block log all posso
fare il debug quando qualcosa non va ascoltando con tcpdump sulla pflog0 e
vedendo dove i miei pacchetti vengono bloccati. Tutto qui.
ciao
Luca

 una parte e Darren dall'altra sono state eccezionali.
E il bello e` che il buon Darren e` ancora li` a prenderle :-)
(BTW: vista l'ultima contro Van Helsing?)


 signature (gesso -quello vero- tolto, era ora!!!).
Bene, mi fa piacere per te, finalmente!
:)


 esterna.
con due  iface in  effetti non vedo  problemi in questo  approccio... ma
cosa succede in un firewall con 3,4,5 schede di rete?
-- 
lg, You love GNUS: you'll be assimilated.

 cosa succede in un firewall con 3,4,5 schede di rete?
Stavo pensando esattamente la stessa cosa.
ciao
Luca

 cose..
Parole sante...
-- 
Per contattarmi, toglimi il gesso... virtuale!
