Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

freebsd-pf Digest, Vol 269, Issue 1

3 views
Skip to first unread message

freebsd-p...@freebsd.org

unread,
Nov 16, 2009, 7:00:17 AM11/16/09
to freeb...@freebsd.org
Send freebsd-pf mailing list submissions to
freeb...@freebsd.org

To subscribe or unsubscribe via the World Wide Web, visit
http://lists.freebsd.org/mailman/listinfo/freebsd-pf
or, via email, send a message with subject or body 'help' to
freebsd-p...@freebsd.org

You can reach the person managing the list at
freebsd-...@freebsd.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of freebsd-pf digest..."


Today's Topics:

1. PF NAT problems. (Bal?zs M?t?ffy)
2. Avoid keeping state of ntp requests (Ask Bj?rn Hansen)
3. Re: Avoid keeping state of ntp requests (Ask Bj?rn Hansen)
4. Re: Avoid keeping state of ntp requests (Denny Lin)
5. Current problem reports assigned to freeb...@FreeBSD.org
(FreeBSD bugmaster)


----------------------------------------------------------------------

Message: 1
Date: Sun, 15 Nov 2009 22:23:13 +0100
From: Bal?zs M?t?ffy <repc...@gmail.com>
Subject: PF NAT problems.
To: freebsd-pf <freeb...@freebsd.org>
Message-ID:
<c4b701070911151323n1e7...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

Hello,

I'm struggling with pf nat to work when connecting to ipsec vpns, when I
have a pf and pfnat gateway on my LAN side. Sometimes it's ok to some
networks, but most of the time it's not. Usually I'm using Cisco vpn client,
and connecting to cisco ASA devices and sometimes pptp and l2tp vpn with the
client from Windows XP.
I tried passing ipsec relevant packets through the pf fw but if I use ipnat
it works perfectly without any added rules.
Somewhere I found that I have to statically map port 500 for pf to map that
to the external interface as well(and don't change port number), but I
couldn't make that work.

Relevant part of my pf.conf:
I just pasted the macros, because I think the problem lies somewhere else.
prv_ads = 192.168.0.0/24

nat on $ext_if proto $nat_p from $prv_ads to any -> ($ext_if:0) #we need
this to work with dyn ip and pppoe tun0
##Some port forwarding rules deleted from here...
rdr-anchor miniupnpd

ipnat.conf:

map tun0 192.168.0.0/24 -> 0/32 proxy port ftp ftp/tcp
map tun0 192.168.0.0/24 -> 0/32 portmap tcp/udp 40000:65000
map tun0 192.168.0.0/24 -> 0/32
#some port redirection deleted from here.


Thanks for any help,

B.


------------------------------

Message: 2
Date: Mon, 16 Nov 2009 02:11:02 -0800
From: Ask Bj?rn Hansen <a...@develooper.com>
Subject: Avoid keeping state of ntp requests
To: freeb...@freebsd.org
Message-ID: <B4BDA459-66C1-4FC5...@develooper.com>
Content-Type: text/plain; charset=us-ascii

Hi,

I'm trying to avoid keeping state of ntp requests to our ntp servers. They are on UDP and numerous, so it's just wasting a lot of space in the state table.

I've tried various variations of 'pass quick', but some rule keeps adding state for the port 123 requests. I've put the full output of 'pfctl -sa' here:

http://tmp.askask.com/2009/11/pf.txt

Any ideas?


- ask

------------------------------

Message: 3
Date: Mon, 16 Nov 2009 02:59:32 -0800
From: Ask Bj?rn Hansen <a...@develooper.com>
Subject: Re: Avoid keeping state of ntp requests
To: Denny Lin <denny...@cnmc32.hs.ntnu.edu.tw>
Cc: freeb...@freebsd.org
Message-ID: <6967A89E-CF55-4F65...@develooper.com>
Content-Type: text/plain; charset=us-ascii


On Nov 16, 2009, at 2:44, Denny Lin wrote:

>
>> I'm trying to avoid keeping state of ntp requests to our ntp servers. They are on UDP and numerous, so it's just wasting a lot of space in the state table.
>>
>> I've tried various variations of 'pass quick', but some rule keeps adding state for the port 123 requests. I've put the full output of 'pfctl -sa' here:
>
> Have you tried adding "no state" at the end of the rule? This way they
> aren't added to the state table.

Hi Denny,

Yes, indeed - that's what I'm doing; I should have made that explicit in the mail.

I've put the pfctl -vsr output up here:

http://tmp.askask.com/2009/11/pfctl-vsr.txt

[ a little later ]

Aargh! The problem was that the table in my rule was <ntp_servers>, but the table with the IP addresses was <ntp_hosts>!

Thanks for making me take a second[1] look.


- ask


[1] That's a joke, more like look number 217!

------------------------------

Message: 4
Date: Mon, 16 Nov 2009 18:44:13 +0800
From: Denny Lin <denny...@cnmc32.hs.ntnu.edu.tw>
Subject: Re: Avoid keeping state of ntp requests
To: freeb...@freebsd.org
Message-ID: <20091116104...@mx.hs.ntnu.edu.tw>
Content-Type: text/plain; charset=utf-8


> I'm trying to avoid keeping state of ntp requests to our ntp servers. They are on UDP and numerous, so it's just wasting a lot of space in the state table.
>
> I've tried various variations of 'pass quick', but some rule keeps adding state for the port 123 requests. I've put the full output of 'pfctl -sa' here:

Have you tried adding "no state" at the end of the rule? This way they
aren't added to the state table.

--
Denny Lin


------------------------------

Message: 5
Date: Mon, 16 Nov 2009 11:06:58 GMT
From: FreeBSD bugmaster <bugm...@FreeBSD.org>
Subject: Current problem reports assigned to freeb...@FreeBSD.org
To: freeb...@FreeBSD.org
Message-ID: <200911161106....@freefall.freebsd.org>

Note: to view an individual PR, use:
http://www.freebsd.org/cgi/query-pr.cgi?pr=(number).

The following is a listing of current problems submitted by FreeBSD users.
These represent problem reports covering all versions including
experimental development code and obsolete releases.


S Tracker Resp. Description
--------------------------------------------------------------------------------
o kern/137982 pf [pf] when pf can hit state limits, random IP failures
o kern/136781 pf [pf] Packets appear to drop with pf scrub and if_bridg
o kern/135948 pf [pf] [gre] pf not natting gre protocol
o kern/135162 pf [pfsync] pfsync(4) not usable with GENERIC kernel
o kern/134996 pf [pf] Anchor tables not included when pfctl(8) is run w
o kern/133732 pf [pf] max-src-conn issue
o kern/132769 pf [pf] [lor] 2 LOR's with pf task mtx / ifnet and rtent
f kern/132176 pf [pf] pf stalls connection when using route-to [regress
o conf/130381 pf [rc.d] [pf] [ip6] ipv6 not fully configured when pf st
o kern/129861 pf [pf] [patch] Argument names reversed in pf_table.c:_co
o kern/127920 pf [pf] ipv6 and synproxy don't play well together
o conf/127814 pf [pf] The flush in pf_reload in /etc/rc.d/pf does not w
o kern/127439 pf [pf] deadlock in pf
f kern/127345 pf [pf] Problem with PF on FreeBSD7.0 [regression]
o kern/127121 pf [pf] [patch] pf incorrect log priority
o kern/127042 pf [pf] [patch] pf recursion panic if interface group is
o kern/125467 pf [pf] pf keep state bug while handling sessions between
s kern/124933 pf [pf] [ip6] pf does not support (drops) IPv6 fragmented
o kern/124364 pf [pf] [panic] Kernel panic with pf + bridge
o kern/122773 pf [pf] pf doesn't log uid or pid when configured to
o kern/122014 pf [pf] [panic] FreeBSD 6.2 panic in pf
o kern/121704 pf [pf] PF mangles loopback packets
o kern/120281 pf [pf] [request] lost returning packets to PF for a rdr
o kern/120057 pf [pf] [patch] Allow proper settings of ALTQ_HFSC. The c
o bin/118355 pf [pf] [patch] pfctl(8) help message options order false
o kern/114567 pf [pf] [lor] pf_ioctl.c + if.c
o kern/114095 pf [carp] carp+pf delay with high state limit
o kern/111220 pf [pf] repeatable hangs while manipulating pf tables
s conf/110838 pf [pf] tagged parameter on nat not working on FreeBSD 5.
o kern/103283 pf pfsync fails to sucessfully transfer some sessions
o kern/103281 pf pfsync reports bulk update failures
o kern/93825 pf [pf] pf reply-to doesn't work
o sparc/93530 pf [pf] Incorrect checksums when using pf's route-to on s
o kern/92949 pf [pf] PF + ALTQ problems with latency
o bin/86635 pf [patch] pfctl(8): allow new page character (^L) in pf.
o kern/82271 pf [pf] cbq scheduler cause bad latency

36 problems total.

------------------------------

End of freebsd-pf Digest, Vol 269, Issue 1
******************************************

0 new messages