Hi:
I have the following setup:
XP -- FBSD -- Ineternet --- Work
I need to setup a VPN connection from my work station to work but the
connection failes, presumably blocked by my firewall. The FBSD gateway
use ip filter to filter traffic with a default block. Listening on the
pflog
Hi all,
i want to have these two rules in the ipf.rules file
pass in quick on $oif proto tcp from 217.83.122.17/8 to $myip port = 22 flags S
keep state
pass in quick on $oif proto tcp from 217.83.89.61/8 to $myip port = 22 flags S
keep state
where $iof is my interface. Executing the config
Hi all,
i want to have these two rules in the ipf.rules file
pass in quick on $oif proto tcp from 217.83.122.17/8 to $myip port = 22 flags S
keep state
pass in quick on $oif proto tcp from 217.83.89.61/8 to $myip port = 22 flags S
keep state
where $iof is my interface. Executing the config
Hi all,
i want to have these two rules in the ipf.rules file
pass in quick on $oif proto tcp from 217.83.122.17/8 to $myip port = 22 flags S
keep state
pass in quick on $oif proto tcp from 217.83.89.61/8 to $myip port = 22 flags S
keep state
where $iof is my interface. Executing the config
Tun Eler wrote:
Hi all,
i want to have these two rules in the ipf.rules file
pass in quick on $oif proto tcp from 217.83.122.17/8 to $myip port = 22 flags
S keep state
pass in quick on $oif proto tcp from 217.83.89.61/8 to $myip port = 22 flags
S keep state
where $iof is my interface.
Appending your IP with /8 ends you up with two rules that essentially
look like this (AFAIK):
pass in quick on $oif proto tcp from 217.0.0.0/8 to $myip port = 22
flags S keep state
Oh, off course. I was applying the rule in the wrong direction, from the right
to the left. Silly :-)
Tun Eler wrote:
Appending your IP with /8 ends you up with two rules that essentially
look like this (AFAIK):
pass in quick on $oif proto tcp from 217.0.0.0/8 to $myip port = 22
flags S keep state
Oh, off course. I was applying the rule in the wrong direction, from the
right to the
Hello lists,
I have a 6.1-RELEASE-p10 system running IP Filter which comes with 6.1
acting as a firewall for my small home network. This system freezes when
handling a lot of data, ie. With an upload of a 60Meg file to the
firewall through SFTP from OpenSSH or when accessing large webpages
.
I then proceeded to configure /etc/ipf.rules as follows:
# IP Filter Rules File
# Block Garbage
block in log quick from any to any with ipopts
block in log quick proto tcp from any to any with short
# System Loopback Interface
pass in quick on lo0 all
pass out quick on lo0 all
of a webserver.
However, upon entering the section regarding IP Filter, I have come
across a couple differences and had some trouble. The differences lie
with how IP Filter was implemented. Where Lucas discussed compiling IP
Filter directly into the kernel, the handbook mentioned the pre-compiled
Erik Norgaard wrote:
B H wrote:
You have nat?
Yes, and it's working.
are you routing traffic?
Yes.
from where to where are you trying to connect,
From the outside and in.
From outside and in means from somewhere on the internet to the
external interface on our fw? or to a natted
Hello!
I've upgrade a machine about a week ago from 4.10-p19 i belive it was.
Now IPFilter does not work or is VERY slow, ssh, web and mail timesout.
NAT is working like it should.
# dmesg | grep 'IP Filter'
IP Filter: v3.4.35 initialized. Default = pass all, Logging = enabled
ipf.rules
B H wrote:
Now IPFilter does not work or is VERY slow, ssh, web and mail timesout.
NAT is working like it should.
# dmesg | grep 'IP Filter'
IP Filter: v3.4.35 initialized. Default = pass all, Logging = enabled
ipf.rules looks like this:
# Let clients behind the firewall send out
Erik Norgaard skrev:
B H wrote:
Now IPFilter does not work or is VERY slow, ssh, web and mail timesout.
NAT is working like it should.
# dmesg | grep 'IP Filter'
IP Filter: v3.4.35 initialized. Default = pass all, Logging = enabled
ipf.rules looks like this:
# Let clients behind
B H wrote:
You have nat?
Yes, and it's working.
are you routing traffic?
Yes.
from where to where are you trying to connect,
From the outside and in.
From outside and in means from somewhere on the internet to the external
interface on our fw? or to a natted server inside?
The
if you want
a meaningful firewall.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of B H
Sent: Wednesday, March 29, 2006 4:06 AM
To: [EMAIL PROTECTED] ORG
Subject: IP Filter problems on 4.11-STABLE
Hello!
I've upgrade a machine about a week ago from 4.10-p19 i
Erik Norgaard skrev:
B H wrote:
From outside and in means from somewhere on the internet to the
external interface on our fw?
Yes.
or to a natted server inside?
No.
The outside ip is not in the range 82.182.0.0/16? you have blocked
everything from that address space,, first in-rule.
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
filter, follow these steps:
make freebsd5 - went successfully
make install-bsd - went successfully
FreeBSD/kinstall - generated patch error about conf.c file not being found...
Here's your problem then.
This is *NOT* the way to install IP Filter on a FreeBSD system.
You should only upgrade parts
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
ntp. If so, then it is likely a bug in ip-filter.
else,
2) Try using snort or tcpdump to capture the blocked packet and analyse
if it is malformed. Possibly include such a packet with your next post.
else
3) try to see if you can upgrade to a newer ipfilter, latest is v4.1.10
Cheers, Erik
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
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 mask: 0xa
I am trying
PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Roman Serbski
Sent: Sunday, February 26, 2006 10:16 AM
To: freebsd-questions@freebsd.org
Subject: Help with IP Filter 4.1.8
Hi all,
I am having a problem with ipf after recent upgrade to 6.1-PRERELEASE.
Any help would be greatly appreciated.
ipf: IP
then repost your question.
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
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.
Dear List,
I just upgraded a couple of my machines from 4.9 release to 4.11 release,
and now I am finding some issues with IP Filters.
this is the output of ipf -V:
ipf: IP Filter: v3.4.35 (336)
Kernel: IP Filter: v3.4.35
Some of the issues I am having are:
Before this set of rules worked fine
On Mon, Feb 07, 2005 at 02:46:50PM -0500, Jim Arnold wrote:
On Mon, Feb 07, 2005 at 11:08:54AM -0500, Jim Arnold wrote:
If you don't have it in your kernel, the module will be loaded at boot
time if it's available. If you don't have the module either, you
can't use ipfilter.
I must
On Mon, Feb 07, 2005 at 12:24:09AM -0500, Jim Arnold wrote:
I updated my firewall that is using IPF. I went from FreeBSD 4.7
stable to 4.11 stable. When using 4.7 stable I only had this is my
rc.conf file:
ipfilter_enable=YES
ipfilter_program=/sbin/ipf
ipfilter_rules=/etc/ipf.conf
On Mon, Feb 07, 2005 at 11:08:54AM -0500, Jim Arnold wrote:
If you don't have it in your kernel, the module will be loaded at boot
time if it's available. If you don't have the module either, you
can't use ipfilter.
I must have been using the module with 4.7 stable since I did not
have
On Mon, Feb 07, 2005 at 11:08:54AM -0500, Jim Arnold wrote:
If you don't have it in your kernel, the module will be loaded at boot
time if it's available. If you don't have the module either, you
can't use ipfilter.
I must have been using the module with 4.7 stable since I did not
have that
I updated my firewall that is using IPF. I went from FreeBSD 4.7
stable to 4.11 stable. When using 4.7 stable I only had this is my
rc.conf file:
ipfilter_enable=YES
ipfilter_program=/sbin/ipf
ipfilter_rules=/etc/ipf.conf
ipfilter_flags=
When I went to 4.11 stable I had to uncomment these
On Mon, Feb 07, 2005 at 12:24:09AM -0500, Jim Arnold wrote:
I updated my firewall that is using IPF. I went from FreeBSD 4.7
stable to 4.11 stable. When using 4.7 stable I only had this is my
rc.conf file:
ipfilter_enable=YES
ipfilter_program=/sbin/ipf
ipfilter_rules=/etc/ipf.conf
On Tue, Sep 07, 2004 at 05:50:59PM -0400, Paul Mather wrote:
20030925:
Configuring a system to use IPFILTER now requires that PFIL_HOOKS
also be explicitly configured. Previously this dependency was
magically handled through some cruft in net/pfil.h; but that has
been
On Wed, 2004-09-08 at 02:12, Wayne Pascoe wrote:
On Tue, Sep 07, 2004 at 05:50:59PM -0400, Paul Mather wrote:
20030925:
Configuring a system to use IPFILTER now requires that PFIL_HOOKS
also be explicitly configured. Previously this dependency was
magically handled through
Hi all,
I'm trying to get ipfilter working with FreeBSD 5.2.1. I did a cvsup
using the tag RELENG_5_2 night before last.
Today I did make world (which succeeded) and then tried to build my
kernel.
Before doing the make kernel, I edited my kernel configuration file and
added the following
Hi Wayne,
Wayne Pascoe wrote:
After a while, that dies with the error at the bottom of this message.
Can anyone advise me what is going wrong and how I can fix this ?
Thanks in advance,
ERROR MESSAGE - LINES LONGER THAN 72 CHARS FOLLOW
cc -c -O -pipe -march=pentiumpro -Wall
On Tue, Sep 07, 2004 at 08:07:34PM +0200, Remko Lodder wrote:
I think you missed this option:
options PFIL_HOOKS # pfil(9) framework
in your kernel config file..
Try it and see it's magic ;)
Thanks a bunch - that did the trick. I've checked the doc I used to do
On Tuesday 07 September 2004 02:12 pm, Wayne Pascoe wrote:
On Tue, Sep 07, 2004 at 08:07:34PM +0200, Remko Lodder wrote:
I think you missed this option:
options PFIL_HOOKS # pfil(9) framework
in your kernel config file..
Try it and see it's magic ;)
Thanks a
On Tue, 7 Sep 2004 22:12:23 +0100, Wayne Pascoe
[EMAIL PROTECTED] wrote:
On Tue, Sep 07, 2004 at 08:07:34PM +0200, Remko Lodder wrote:
I think you missed this option:
options PFIL_HOOKS # pfil(9) framework
in your kernel config file..
Try it and see it's
hi all
i'm trying to get ipfilter set up on my new 5.1-RELEASE box. i think i
have everything configured properly
my kernel config looks like
options IPFILTER
options IPFILTER_LOG
options IPFILTER_DEFAULT_BLOCK
my /etc/rc.conf looks like
ipfilter_enable=YES
ipfilter_flags=
52 matches
Mail list logo
