Mark Rolen <[EMAIL PROTECTED]> wrote:

>I had the same symptom, where I'd have to manually reload my pf 
rules
>after a reboot to get OpenVPN traffic to flow.  Using tcpdump 
showed
>that pf was blocking all the traffic on my tun interfaces although 
I had
>a "set skip" rule for them.

Here are my pf rules:

ext_if="fxp0"
int_if="ath0"

set skip on { lo, tun0 }
set block-policy return

scrub in

nat-anchor "ftp-proxy/*"
rdr-anchor "ftp-proxy/*"
nat on $ext_if from !($ext_if) -> ($ext_if:0)
rdr pass on $int_if proto tcp to port ftp -> 127.0.0.1 port 8021

anchor "ftp-proxy/*"
block in

antispoof quick for { lo, $int_if, tun0 }

pass in on $int_if proto tcp from 10.1.1.2 to 10.1.1.1 port ssh
pass in proto icmp
pass in on $int_if from 10.8.0.0/24 to any
pass in on $int_if proto udp from 10.1.1.2 to 10.1.1.1 port 1194
pass out

Note, this problem is occurring even though I too have "set skip on 
{ lo, tun0 }".  I stated before that I had another question I would 
post.  Since you brought this up, I'll post it.  About a two or 
three months ago, I posted a question about how come my openvpn 
wireless connection was not working with the above pf rules with 
one exception.  I did not have the this line in there:

pass in on $int_if from 10.8.0.0/24 to any

I still had to run pfctl -f /etc/pf.conf after bootup.  Even after 
running pfctl -f /etc/pf.conf, it would not work.  By adding this 
line it worked just fine.  So now I'm confused.  I thought the way 
this worked was that when I connect to openvpn, pf allows it on 
port 1194 which it then sends to tun0.  Since tun0 is not blocked 
from the "set skip on { lo, tun0 }" it should pass through tun0.  
By adding the line above, proves that this is not so.  So is there 
a bug, especially with the tun device, or am I not understanding 
something?  If I'm not understanding something, please enlighten me 
(it will be appreciated).

>Anyhow, I don't have the issue any longer because I just added 
this >rule:

>pass quick on { tun0 tun1 }

>That seems to be effective regardless of whether or not the 
interfaces
>exist when pf loads, so my OpenVPN tunnels work after reboots 
without
>intervention.

Does this point to a problem with "set skip on { lo, tun0 }"?  I 
will try your suggestion to see if it works (pass quick on { tun0 
tun1 }), but I dislike using "quick" in my rules.

I added "up" to my /etc/hostname.tun0 to see if that worked based 
on one of the suggestions but the startup problem still exist?  I 
have since removed "up" since in the past I have never needed to 
use it and I read somewhere that "touch /etc/hostname.tun0" was all 
that I needed.

Reply via email to