Roman Serbski wrote:
Start over with a clean /usr/src and /usr/obj tree and read the file
``/usr/src/UPDATING'' for instructions about upgrading from source.
Dear Erik and Giorgos,
Thanks a lot for your assistance! I just cvsuped one hour ago,
build/install kernel/world and now everything is
Roman Serbski wrote:
1) Other udp services, are responces also blocked? you can for example
try ntp. If so, then it is likely a bug in ip-filter.
Yes. Same for other udp (I tested with ntp). The symptoms are the same
- there is a hit on a rule allowing outgoing ntp, but then reply is
blocked.
On 2006-03-10 09:44, Roman Serbski [EMAIL PROTECTED] wrote:
3) try to see if you can upgrade to a newer ipfilter, latest is v4.1.10
I will try that, although I have faced with the problem while
upgrading to v4.1.10. According to ipf docs (INSTALL.FreeBSD):
To build a kernel with the IP
On 3/10/06, Giorgos Keramidas [EMAIL PROTECTED] wrote:
Here's your problem then.
This is *NOT* the way to install IP Filter on a FreeBSD system.
You should only upgrade parts of the base system using the process
documented and recommended in ``/usr/src/UPDATING''.
Start over with a clean
Hello Erik. Thank you for your help.
Ok, here are some things to try:
1) Other udp services, are responces also blocked? you can for example
try ntp. If so, then it is likely a bug in ip-filter.
Yes. Same for other udp (I tested with ntp). The symptoms are the same
- there is a hit on a rule
Roman Serbski wrote:
My ruleset consists of only 6 rules:
pass out quick on lo0 from any to any
pass out quick on xl0 proto tcp from any to any port = domain flags
S/FSRPAU keep state
pass out quick on xl0 proto udp from any to any port = domain keep state
block out log quick on xl0 all
pass
On 2/26/06, Donald J. O'Neill [EMAIL PROTECTED] wrote:
I don't see anything in the OP's message that requires kernel debugging.
Just some advice that he should check to see what changes have been
made to ipf v4.1.8 as compared to v3.4.35 and how they affect rules.
Thank you Don. Exactly. I can
On 2/27/06, Erik Nørgaard [EMAIL PROTECTED] wrote:
Could you change your last rule to this:
block in log quick on xl0 all
and then tell what you see in the log. This would give some information
if any traffic is blocked in the first place. Actually, adding the log
keyword to all rules for
On 2006-02-27 18:48, Roman Serbski [EMAIL PROTECTED] wrote:
On 2/27/06, Erik N?rgaard [EMAIL PROTECTED] wrote:
Could you change your last rule to this:
block in log quick on xl0 all
and then tell what you see in the log. This would give some information
if any traffic is blocked in the first
On 2006-02-27 16:50, Giorgos Keramidas [EMAIL PROTECTED] wrote:
It looks like the stateful rule didn't succeed in creating a state for
the outgoing UDP packet:
pass out quick on lo0 from any to any
pass out quick on xl0 proto tcp from any to any port = domain flags
S/FSRPAU keep
On 2/27/06, Giorgos Keramidas [EMAIL PROTECTED] wrote:
One reason why this could fail is that the xl0 interface is not part of
the route to your ISP's DNS servers.
How many interfaces does the system have? Is xl0 in the path to your
ISP's router?
There are two interfaces - xl0 and xl1 with
Roman Serbski wrote:
Adding the 'log' keyword produced the following record:
xl0 @0:2 b XXX.XXX.XXX.XXX,53 - YYY.YYY.YYY.YYY,60808 PR udp len 20 298 IN bad
read this line: This tells you where the packet is blocked. IIRC @0:2
means group 0 (you don't use groups) and 2 should be the second
Roman Serbski wrote:
xl0 @0:2 b XXX.XXX.XXX.XXX,53 - YYY.YYY.YYY.YYY,60808 PR udp len 20 298 IN bad
Just looking again on this line, see at the end? bad could be that the
response is malformed and therefore discarded. could be that ipf is less
tolerant in the newer version. Try to use a
On 2/27/06, Erik Norgaard [EMAIL PROTECTED] wrote:
read this line: This tells you where the packet is blocked. IIRC @0:2
means group 0 (you don't use groups) and 2 should be the second rule.
If you list the ruleset with ipfstat -n that should give you rules with
the same labeling.
Also, add
Since you say the same ipf rules work on your 5.3 system and you
are trying to run them on 6.1-PRERELEASE, I would say the problem
is 6.1-PRERELEASE.
Prereleases versions and RC version are not intended for public use.
They are version for people who know how to debug kernel code and
help the
On Sunday 26 February 2006 11:19, fbsd_user wrote:
Since you say the same ipf rules work on your 5.3 system and you
are trying to run them on 6.1-PRERELEASE, I would say the problem
is 6.1-PRERELEASE.
Prereleases versions and RC version are not intended for public use.
They are version for
Roman Serbski wrote:
Hi all,
I am having a problem with ipf after recent upgrade to 6.1-PRERELEASE.
Any help would be greatly appreciated.
ipf: IP Filter: v4.1.8 (416)
Kernel: IP Filter: v4.1.8
Running: yes
Log Flags: 0 = none set
Default: pass all, Logging: available
Active list: 0
Feature
On 2006-02-26 20:15, Roman Serbski [EMAIL PROTECTED] wrote:
Hi all,
I am having a problem with ipf after recent upgrade to 6.1-PRERELEASE.
Any help would be greatly appreciated.
ipf: IP Filter: v4.1.8 (416)
Kernel: IP Filter: v4.1.8
Running: yes
Log Flags: 0 = none set
Default: pass all,
On 2006-02-26 12:19, fbsd_user [EMAIL PROTECTED] wrote:
Since you say the same ipf rules work on your 5.3 system and you
are trying to run them on 6.1-PRERELEASE, I would say the problem
is 6.1-PRERELEASE.
No, that's false.
Prereleases versions and RC version are not intended for public use.
19 matches
Mail list logo
