pf & clonable devices

[Eric Masson]

>>>>> "Max" == Max Laier <max at love2party.net> writes:

 Max> Okay, that hints that the NAT-rule is to blame.

Seems to.

 Max> Can you check the output of "$pfctl -vvsn" after a reconnect, but
 Max> before issuing a ruleset reload? This looks a bit like PR
 Max> kern/69954, in which case you might want to try to write your
 Max> nat-rule as:

 Max> nat on $ext_if from $int_if:network to any -> ($ext_if:0)

Ok, further refinement, on machine boot, pf refuses to load rules
because interface ppp0 doesn't exist (Thanks to dmesg -a, this box is
headless)

Once pppd has started pfctl -vvsn gives the following results :
No ALTQ support in kernel
ALTQ related functions disabled

Result expected as no nat rules reference ppp0 interface, sigh...

After pfctl -F all -f /etc/pf.conf, pfctl -vvsn gives the following
results :
No ALTQ support in kernel
ALTQ related functions disabled
@0 nat on ppp0 inet from 192.168.1.0/24 to any -> (ppp0:0)
  [ Evaluations: 209       Packets: 236       Bytes: 149822      States: 3     ]

After that, shutdown of pppd processes, removal of pppX interfaces and
startup of pppd processes, then traffic flows fine and is correctly
nat'ed.

So, your fix seems to be fine :)

The next question concerns PF support for clonable interfaces that do
not exist at pf startup. Is this a feature that could be added or do I
need to mess with anchors in ip-up/ip-down scripts ?

Éric

-- 
 Pourquoi les internautes français ce mobiliseraient pas pour se regrouper
 un société ou association pour pouvoir avoir des numéro vert  Il faudrait
 que louer les lignes téléphoniques à FT et on ne paierai qu'un abonnement
 -+- BT in : Guide du Neuneu Usenet - Neuneu se met au vert -+-