Current problem reports assigned to freebsd-pf@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/140697 pf [pf] pf behaviour changes - must be documented 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/86635pf [patch] pfctl(8): allow new page character (^L) in pf. o kern/82271 pf [pf] cbq scheduler cause bad latency 37 problems total. ___ freebsd-pf@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-pf To unsubscribe, send any mail to "freebsd-pf-unsubscr...@freebsd.org"
Re: IPv6, PF problem
On Saturday 12 December 2009 22:11:28 Aaron Stellman wrote: > Hello there, > > > What does "pfctl -vvsr" give you for the rule? It should include the > > number of addresses assigned to the interface in the braces - e.g. "... > > (bge0:4) ..." > > @8 pass in on bge0 proto tcp from any to (bge0:4) port = ftp flags S/SA > keep state [ Evaluations: 0 Packets: 0 Bytes: 0 > States: 0 ] [ Inserted: uid 0 pid 79900 ] > > > In addition, can you try to add separate rules for inet and inet6 - i.e. > > > > pass in on $ext_if inet proto tcp to ($ext_if) port 21 > > pass in on $ext_if inet6 proto tcp to ($ext_if) port 21 > > @8 pass in on bge0 inet proto tcp from any to (bge0:2) port = ftp flags > S/SA keep state [ Evaluations: 1 Packets: 17Bytes: 916 > States: 1 ] [ Inserted: uid 0 pid 80198 ] > @9 pass in on bge0 inet6 proto tcp from any to (bge0:2) port = ftp flags > S/SA keep state [ Evaluations: 1 Packets: 0 Bytes: 0 > States: 0 ] [ Inserted: uid 0 pid 80198 ] > > and it passes inet6 connection with these two rules. Do you consider it > a bug? This essentially forces me to have 2 separate rules for inet and > inet6. I do consider it a bug, but I can't reproduce it here. Can you think of anything in your setup that might be special - e.g. the way you add the addresses to your interface? Are you certain that you were testing with the right rules in place (your output above shows zero rule evaluations) which is a sign that something else went wrong. Can anyone else reproduce this problem or did you see something similar? Regards, -- Max ___ freebsd-pf@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-pf To unsubscribe, send any mail to "freebsd-pf-unsubscr...@freebsd.org"
PF Transparent Bridge Firewall + CARP
Hello, I have what I would consider not a standard firewall scenario that requires a second, redundant PF firewall. My first / main firewall is pf + transparent bridging with no internal network / ip addresses. I would like to implement a second failover firewall w/ CARP and have a pretty good idea of how I can accomplish this -- however , I would like to hear opinions / suggestions of implementing the most logical solution with CARP. I would like to implement CARP on the gateway IP address which will sit on the bridge0 interface, which bridges br01 + br02. Bridge0 will have no ip address assigned , and the gateway ip address will be assigned to carp0. Will I have to NAT traffic from carp0 > bridge0 ? will bridge0 be my ext_if in pf.conf , and int_if will be carp0? The main issue is maintaining redundancy, for me. It seems like an easy question, however Im just trying to wrap my brain around the one that doesn't cost as much overhead and is the simplest / most logical. Pertinent info : FreeBSD fw 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #4: Tue Dec 16 13:00:03 EST 2008 ad...@fw:/usr/obj/usr/src/sys/FW i386 If you need additional information ,please let me know. Suggestions are welcome. Thanks, Kevin ___ freebsd-pf@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-pf To unsubscribe, send any mail to "freebsd-pf-unsubscr...@freebsd.org"
RE: PF Transparent Bridge Firewall + CARP
> -Original Message- > From: Kevin [mailto:k...@kevinkevin.com] > I have what I would consider not a standard firewall scenario that > requires a second, redundant PF firewall. My first / main firewall is > pf + transparent bridging with no internal network / ip addresses. I realize that carp would require an ip address on both interfaces to work properly... this is correct, right? Could I just assign the 1 ip address / gateway on the bridge0 interface and add a carp interface to fail that over to the 2nd firewall? ___ freebsd-pf@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-pf To unsubscribe, send any mail to "freebsd-pf-unsubscr...@freebsd.org"
Lots of weird PF behavior on 7.2-STABLE
Hi all,
I have a PF machine that is giving fits. I see a lot of weird behavior.
1) TCP connections (mainly port 80) sometimes take 3 seconds to get
started instead of being virtually instant.
2) Sometimes HTTP connections just stop responding. (Client program
times out waiting for response.)
3) Sometimes connections get weirdly dropped ("Connection reset by peer.")
4) Sometimes if I am ssh'd through the firewall, something will happen
and my inbound packets will start getting dropped, but outbound
packets still pass. For example, if I'm at the shell prompt, it is
non-responsive. But if I log alongside a stuck connection and "write"
to that tty, I will see it no problem.
5) States that have no right to still be there continue to pile up
into the hundreds of thousands.
I kind of get the feeling that all of these are related. In
particular, I think 2, 3, and 4.
Of all of these, the only one I can document at the moment is #3.
Here is a packet capture from the public (web client) interface:
20:00:02.038067 IP 1.2.3.4.61645 > 5.6.7.8.80: S
620577087:620577087(0) win 65535
20:00:02.038328 IP 5.6.7.8.80 > 1.2.3.4.61645: S 40565958:40565958(0)
ack 620577088 win 0
20:00:02.065678 IP 1.2.3.4.61645 > 5.6.7.8.80: . ack 1 win 65535
20:00:02.095158 IP 1.2.3.4.61645 > 5.6.7.8.80: P 1:80(79) ack 1 win 65535
20:00:02.378248 IP 1.2.3.4.61645 > 5.6.7.8.80: P 1:80(79) ack 1 win 65535
20:00:02.746163 IP 1.2.3.4.61645 > 5.6.7.8.80: P 1:80(79) ack 1 win 65535
20:00:03.282122 IP 1.2.3.4.61645 > 5.6.7.8.80: P 1:80(79) ack 1 win 65535
20:00:04.154112 IP 1.2.3.4.61645 > 5.6.7.8.80: P 1:80(79) ack 1 win 65535
20:00:05.698002 IP 1.2.3.4.61645 > 5.6.7.8.80: P 1:80(79) ack 1 win 65535
20:00:07.913721 IP 1.2.3.4.61645 > 5.6.7.8.80: P 1:80(79) ack 1 win 65535
20:00:12.145438 IP 1.2.3.4.61645 > 5.6.7.8.80: P 1:80(79) ack 1 win 65535
20:00:12.287038 IP 5.6.7.8.80 > 1.2.3.4.61645: F 1:1(0) ack 1 win 65535
20:00:20.408734 IP 1.2.3.4.61645 > 5.6.7.8.80: P 1:80(79) ack 1 win 65535
20:00:20.409874 IP 5.6.7.8.80 > 1.2.3.4.61645: R 40565959:40565959(0) win 0
Here is a packet capture of the same session from the private (web
server) interface:
20:00:02.038089 IP 1.2.3.4.61645 > 5.6.7.8.80: S
620577087:620577087(0) win 65535
20:00:02.038311 IP 5.6.7.8.80 > 1.2.3.4.61645: S 40565958:40565958(0)
ack 620577088 win 0
20:00:02.065694 IP 1.2.3.4.61645 > 5.6.7.8.80: . ack 1 win 65535
20:00:12.287026 IP 5.6.7.8.80 > 1.2.3.4.61645: F 1:1(0) ack 1 win 65535
20:00:20.408747 IP 1.2.3.4.61645 > 5.6.7.8.80: P 1:80(79) ack 1 win 65535
20:00:20.409859 IP 5.6.7.8.80 > 1.2.3.4.61645: R 40565959:40565959(0) win 0
So that client -> server push packet is not making it through the
firewall despite numerous retransmits, until 18 seconds later when the
server has already given up on it.
That connection hangs around in the state table for a long time as:
all tcp 5.6.7.8:80 <- 1.2.3.4:61645 CLOSED:CLOSING
This despite:
set timeout tcp.closed 5
set timeout tcp.closing 30
To test, I stopped connections from 1.2.3.4 to 5.6.7.8. At present,
there are *zero* established connections between 1.2.3.4 and 5.6.7.8.
None. But:
$ sudo pfctl -s state | fgrep 1.2.3.4: | fgrep :80 | wc
2243 13458 160932
A few minutes later I broke this down by connection status:
1222 CLOSED:CLOSING
556 ESTABLISHED:ESTABLISHED
15 FIN_WAIT_2:CLOSING
27 SYN_SENT:FIN_WAIT_2
That doesn't add up to 2243, so they *are* slowly dying off. I did
some poking around, and the CLOSED:CLOSING ones expire after fifteen
minutes, which is the timeout for tcp.opening. Um, OK.
The 556 ESTABLISHED:ESTABLISHED states appear content to persist until
they age off too, even though those connections are long gone.
As far as the "3 second" thing, I noticed somebody here recently had a
similar problem and made it go away by upping their states and
dropping their timeouts. Well, he dropped his timeouts to where ours
are, and we're at:
set limit states 200
We are definitely not out of states; we're seeing these problems right
now and due to my playing around with the tcp.established timeout,
we're at 66412 states right now. (Ordinarily it hovers around
350,000.) The machine is a dual-core Core 2 6320 with 2GB of RAM and
nothing to but load balance this traffic. It shows as 95% idle all
day.
So sometimes pf loses packets related to connections that are still
around, and sometimes it thinks connections are still around long
after the packets are gone.
I would be really, really grateful for any suggestions or help. I am
completely lost here and at my wits' end!
I've included my pf.conf below.
set limit states 200
set timeout tcp.established 86400
set timeout tcp.closed 5
set timeout tcp.closing 30
ExtIf = "em0"
IntIf = "em1"
table { 127.0.0.0/8, 169.254.0.0/16, 192.0.2.0/24,
192.168.0.0/16, 172.16.0.0/12, 10.0.0.0/8 }
table { ... }
table { ... }
table { ... }
scrub
##
