Date: Sat, 27 Nov 2004 03:43:26 +0100 From: Jonathan Weiss <tomonage2@gmx.de> To: Max Laier <max@love2party.net> Cc: freebsd-pf@freebsd.org Subject: Re:Strange behaviour with PF on FreeBSD 5.3-STABLE Message-ID: <BDCDA85E.1195E%tomonage2@gmx.de> In-Reply-To: <200411262032.04809.max@love2party.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Max, I just found out what the problem was, somehow, ppp created tun1 and tun0 and used tun1 for the ppp-connection. tun1 was not in the pass-rules, so it got blocked. I never had a tun1 before, so it did not came to my mind to include it in the rule-set and when looking at ifconfig I overlooked the one-liner tun0 and just saw that tun1 got an ip. Thank you for your help, Jonathan > On Friday 26 November 2004 19:05, Jonathan Weiss wrote: >> Hi Max, >> >>> You are supposed to have a NAT rule somewhere. Please let us know the >>> complete ruleset (including translation rules) and include match counters >>> so that people can figure if a certain rule is matched at all (pfctl -vv >>> -sn -sr). >> >> This was my complete ruleset, as I switched from my default ruleset in >> order to debug the problem. >> >> ext_if="ed0" >> int_if="vr0" >> tun_if="tun0" >> internal_net="192.168.0.0/24" >> >> set loginterface $tun_if >> >> #nat on $tun_if from $internal_net to any -> ($tun_if) >> >> #default block >> block return log-all >> >> pass on $tun_if >> pass on $ext_if >> pass on $int_if >> >> -------------------------------------- >> pfctl -vv -sn -sr >> @0 block return log-all all >> [ Evaluations: 2171 Packets: 1130 Bytes: 69021 States: 0 >> @1 pass on tun0 all >> [ Evaluations: 2171 Packets: 0 Bytes: 0 States: 0 > > Hmmm ... tun0 is never matched against. Can I have a look at $ifconfig and > $pfctl -vvsI ? Also try to watch pflog ($ifconfig pflog0 up && tcpdump > -vvvnei pflog0) What does it say? > >> @2 pass on ed0 all >> [ Evaluations: 2171 Packets: 0 Bytes: 0 States: 0 >> @3 pass on vr0 all >> [ Evaluations: 2171 Packets: 1041 Bytes: 65738 States: 0 >> >>> Make sure that the NAT rule has dynamic address tracking (as I think you >>> get a dynamic IP from you ISP). The rule should look something like: >>> nat on tun0 from $internalnet to any -> (tun0) >> >> I use the NAT from ppp, but I think that this is not related, as the >> problem occur at (or better: also at) the firewall (i386 FreeBSD 5.3-STABLE >> of yesterday). The firewall itself (and everything behind it) cannot >> connect over ppp to external servers when the default block rule is >> activated. > > Hmmm - strange. Might be realted to the pf_if.c changes. What version are you > running? RELENG_5? RELENG_5_3? HEAD? Did you (src-)update your kernel before > the symptoms occurred? > > pf_if.c: 1.5.2.2 (RELENG_5) or 1.7 (HEAD)? > >> When I deactivate the rule, everything runs smoothly. >> >>> Also note, that we have a pf related mailinglist on FreeBSD, called >>> freebsd-pf@freebsd.org. You might want to subscribe and take the >>> discussion there: http://lists.freebsd.org/mailman/listinfo/freebsd-pf >> >> Thanks, I will suscribe. Should we change with this discussion the >> freebsd-centrinc mailinglist? > > I just did.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?BDCDA85E.1195E%tomonage2>