freebsd-pf Digest, Vol 273, Issue 1
freebsd-p...@freebsd.org
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. Re: Transition from IPFW: PF flags for IPFW "setup" and
"established" keywords (Artyom Viklenko)
2. Re: IPv6, PF problem (Max Laier)
3. Re: IPv6, PF problem (Aaron Stellman)
4. Current problem reports assigned to freeb...@FreeBSD.org
(FreeBSD bugmaster)
5. Re: IPv6, PF problem (Max Laier)
6. PF Transparent Bridge Firewall + CARP (Kevin)
7. RE: PF Transparent Bridge Firewall + CARP (Kevin)
8. Lots of weird PF behavior on 7.2-STABLE (Linda Messerschmidt)
9. Re: Lots of weird PF behavior on 7.2-STABLE (Ermal Lu?i)
10. Re: Lots of weird PF behavior on 7.2-STABLE (Linda Messerschmidt)
11. Re: Lots of weird PF behavior on 7.2-STABLE (Peter Maxwell)
12. Re: Lots of weird PF behavior on 7.2-STABLE (Linda Messerschmidt)
13. Re: Lots of weird PF behavior on 7.2-STABLE (Peter Maxwell)
14. Re: Lots of weird PF behavior on 7.2-STABLE (Linda Messerschmidt)
15. new firewall config (David Mehler)
16. RE: new firewall config (Greg Hennessy)
17. Re: PF Transparent Bridge Firewall + CARP (Tom Judge)
18. RE: PF Transparent Bridge Firewall + CARP (Kevin)
19. Re: PF Transparent Bridge Firewall + CARP (Tom Judge)
20. Re: Lots of weird PF behavior on 7.2-STABLE (Helmut Schneider)
21. Network ACK loss problem (pierre.reveillon)
22. External scripts with PF. (Gaurav Ghimire)
23. Re: External scripts with PF. (Tom Uffner)
24. Current problem reports assigned to freeb...@FreeBSD.org
(FreeBSD bugmaster)
25. Re: External scripts with PF. (Peter Maxwell)
----------------------------------------------------------------------
Message: 1
Date: Sat, 12 Dec 2009 15:58:17 +0200
From: Artyom Viklenko <ar...@aws-net.org.ua>
Subject: Re: Transition from IPFW: PF flags for IPFW "setup" and
"established" keywords
To: Holger Rauch <holger...@empic.de>
Cc: freeb...@freebsd.org
Message-ID: <4B23A179...@aws-net.org.ua>
Content-Type: text/plain; charset=KOI8-U; format=flowed
Holger Rauch �����:
> Hi to everybody,
>
> what are the correct combinations of flags for the IPFW "setup" and
> "established" keywords?
PF's equivalent of IPFW's "setup" is 'flags S/SA'.
Also, you have to include 'keep state' in the same rule
(for FreeBSD versions up to 6.4, in 7.x and 8.x - it's
a default behavior).
If connection is established, PF create state and match
thraffic "internally" whithout special dedicated rules.
E.g.,
pass in on fxp0 inet proto tcp from any to any port 80 flags S/SA keep state
will pass TCP traffic to port 80 if it starts as it should
beginning from the firts packet with only SYN-bit set
of two bits SYN and ACK. State will be created for this
flow if rest packets will follow usual three-way handshake.
After this all packets in this flow will pass automatically
untill connection will be closed (packets with FIN bits seen
by PF) or timed out.
Something like this. :)
--
Sincerely yours,
Artyom Viklenko.
-------------------------------------------------------
ar...@aws-net.org.ua | http://www.aws-net.org.ua/~artem
FreeBSD: The Power to Serve - http://www.freebsd.org
------------------------------
Message: 2
Date: Sat, 12 Dec 2009 21:37:19 +0100
From: Max Laier <m...@love2party.net>
Subject: Re: IPv6, PF problem
To: freeb...@freebsd.org
Message-ID: <20091212213...@love2party.net>
Content-Type: Text/Plain; charset="iso-8859-1"
On Saturday 12 December 2009 02:25:08 Aaron Stellman wrote:
> Hello there,
> Here is the problem I've encountered on a dual stack amd64 FreeBSD 8.0p1
> machine.
>
> What works:
> pass in on $ext_if proto tcp to port 21
>
> What doesn't work:
> pass in on $ext_if proto tcp to ($ext_if) port 21
>
> here is what's logged when it doesn't work:
> listening on pflog0, link-type PFLOG (OpenBSD pflog file), capture size
> 1515 bytes
> 00:00:00.000000 rule 0/0(match): block in on bge0:
> 2001:1938:235:beef:21b:21ff:fe37:d799.11220 >
> 2001:1938:235:dead:226:b9ff:fe75:6e5e.21: Flags [S], seq 413041093, win
> 65535, options [mss 1440,nop,nop,sackOK,nop,wscale 1,nop,nop,TS val
> 3435338387 ecr 0], length 0
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) ..."
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
and check the number of addresses with pfctl -vvsr?
> ext_if="bge0"
>
> epsilon# ifconfig -a
> bge0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu
> 1500
> options=9b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM>
> ether 00:26:b9:75:6e:5e
> inet 10.10.11.5 netmask 0xffffffe0 broadcast 10.10.11.31
> inet6 fe80::226:b9ff:fe75:6e5e%bge0 prefixlen 64 scopeid 0x1
> inet 10.10.11.8 netmask 0xffffffe0 broadcast 10.10.11.31
> inet6 2001:1938:235:dead:226:b9ff:fe75:6e5e prefixlen 64
> autoconf
> media: Ethernet autoselect (1000baseT <full-duplex>)
> status: active
> lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
> options=3<RXCSUM,TXCSUM>
> inet 127.0.0.1 netmask 0xff000000
> inet6 ::1 prefixlen 128
> inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2
> pflog0: flags=0<> metric 0 mtu 33152
>
>
> Notice, that it works as expected with IPv4; meaning that when I use "to
> ($ext_if)" and use ipv4 to connect, connection passes through, unlike
> IPv6.
> Also, OpenBSD pf works as expected with both IPv{4,6}
> _______________________________________________
> freeb...@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-pf
> To unsubscribe, send any mail to "freebsd-pf-...@freebsd.org"
>
>
> !DSPAM:4b22f113621191134040011!
>
------------------------------
Message: 3
Date: Sat, 12 Dec 2009 13:11:28 -0800
From: Aaron Stellman <zi...@x96.org>
Subject: Re: IPv6, PF problem
To: freeb...@freebsd.org
Message-ID: <200912122...@x96.org>
Content-Type: text/plain; charset=us-ascii
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: 17 Bytes: 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.
Thanks
------------------------------
Message: 4
Date: Mon, 14 Dec 2009 11:07:00 GMT
From: FreeBSD bugmaster <bugm...@FreeBSD.org>
Subject: Current problem reports assigned to freeb...@FreeBSD.org
To: freeb...@FreeBSD.org
Message-ID: <200912141107....@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/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/86635 pf [patch] pfctl(8): allow new page character (^L) in pf.
o kern/82271 pf [pf] cbq scheduler cause bad latency
37 problems total.
------------------------------
Message: 5
Date: Mon, 14 Dec 2009 15:54:46 +0100
From: Max Laier <m...@love2party.net>
Subject: Re: IPv6, PF problem
To: freeb...@freebsd.org
Message-ID: <20091214155...@love2party.net>
Content-Type: Text/Plain; charset="iso-8859-1"
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: 17 Bytes: 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
------------------------------
Message: 6
Date: Mon, 14 Dec 2009 11:19:30 -0500
From: "Kevin" <k...@kevinkevin.com>
Subject: PF Transparent Bridge Firewall + CARP
To: <freeb...@freebsd.org>
Message-ID: <002601ca7cd9$380cc970$a8265c50$@com>
Content-Type: text/plain; charset="US-ASCII"
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 admin@fw:/usr/obj/usr/src/sys/FW i386
If you need additional information ,please let me know.
Suggestions are welcome.
Thanks,
Kevin
------------------------------
Message: 7
Date: Mon, 14 Dec 2009 11:39:43 -0500
From: "Kevin" <k...@kevinkevin.com>
Subject: RE: PF Transparent Bridge Firewall + CARP
To: <freeb...@freebsd.org>
Message-ID: <003001ca7cdc$0b530540$21f90fc0$@com>
Content-Type: text/plain; charset="US-ASCII"
> -----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?
------------------------------
Message: 8
Date: Tue, 15 Dec 2009 01:21:53 -0500
From: Linda Messerschmidt <linda.mes...@gmail.com>
Subject: Lots of weird PF behavior on 7.2-STABLE
To: freeb...@freebsd.org
Message-ID:
<237c27100912142221k6cf...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
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 <mss 1460,nop,wscale
9,sackOK,timestamp 953726452 0>
20:00:02.038328 IP 5.6.7.8.80 > 1.2.3.4.61645: S 40565958:40565958(0)
ack 620577088 win 0 <mss 1460>
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 <mss 1460,nop,wscale
9,sackOK,timestamp 953726452 0>
20:00:02.038311 IP 5.6.7.8.80 > 1.2.3.4.61645: S 40565958:40565958(0)
ack 620577088 win 0 <mss 1460>
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 2000000
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 2000000
set timeout tcp.established 86400
set timeout tcp.closed 5
set timeout tcp.closing 30
ExtIf = "em0"
IntIf = "em1"
table <NoRouteIPs> { 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 <OurIPs> { ... }
table <DNSServers> { ... }
table <BalanceBlocks> { ... }
scrub
## Block Reserved Addresses
block log quick on $ExtIf from <NoRouteIPs> to any
block log quick on $ExtIf from any to <NoRouteIPs>
## Block our own Addresses
block in log quick on $ExtIf inet from <OurIPs> to any
## Anti-DDOS
table <AntiDDOS> persist
block quick from <AntiDDOS> to any
block quick from any to <AntiDDOS>
## Block HTTP traffic to DNS servers
block quick inet proto tcp from any to <DNSServers> port 80
## Weird DNS people added 2009-06-18
block drop log quick proto 255
table <GTExperimentDNS> { 61.220.4.0/24 }
block drop in quick proto { udp, tcp } from <GTExperimentDNS> to any port 53
## Load Balancing
pass in on $ExtIf route-to { ($IntIf 3.4.5.6), ($IntIf 3.4.5.7),
($IntIf 3.4.5.8), ($IntIf 3.4.5.9) } round-robin proto tcp from any to
<BalanceBlocks> port 80
------------------------------
Message: 9
Date: Tue, 15 Dec 2009 10:55:58 +0100
From: Ermal Lu?i <e...@freebsd.org>
Subject: Re: Lots of weird PF behavior on 7.2-STABLE
To: Linda Messerschmidt <linda.mes...@gmail.com>
Cc: freeb...@freebsd.org
Message-ID:
<9a542da30912150155k22c...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
On Tue, Dec 15, 2009 at 7:21 AM, Linda Messerschmidt <
linda.mes...@gmail.com> wrote:
> 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 <mss 1460,nop,wscale
> 9,sackOK,timestamp 953726452 0>
> 20:00:02.038328 IP 5.6.7.8.80 > 1.2.3.4.61645: S 40565958:40565958(0)
> ack 620577088 win 0 <mss 1460>
> 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 <mss 1460,nop,wscale
> 9,sackOK,timestamp 953726452 0>
> 20:00:02.038311 IP 5.6.7.8.80 > 1.2.3.4.61645: S 40565958:40565958(0)
> ack 620577088 win 0 <mss 1460>
> 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 2000000
>
> 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 2000000
> set timeout tcp.established 86400
> set timeout tcp.closed 5
> set timeout tcp.closing 30
>
> ExtIf = "em0"
> IntIf = "em1"
>
> table <NoRouteIPs> { 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 <OurIPs> { ... }
> table <DNSServers> { ... }
> table <BalanceBlocks> { ... }
>
> scrub
>
> ## Block Reserved Addresses
> block log quick on $ExtIf from <NoRouteIPs> to any
> block log quick on $ExtIf from any to <NoRouteIPs>
>
> ## Block our own Addresses
> block in log quick on $ExtIf inet from <OurIPs> to any
>
> ## Anti-DDOS
> table <AntiDDOS> persist
> block quick from <AntiDDOS> to any
> block quick from any to <AntiDDOS>
>
> ## Block HTTP traffic to DNS servers
> block quick inet proto tcp from any to <DNSServers> port 80
>
> ## Weird DNS people added 2009-06-18
> block drop log quick proto 255
> table <GTExperimentDNS> { 61.220.4.0/24 }
> block drop in quick proto { udp, tcp } from <GTExperimentDNS> to any port
> 53
>
> ## Load Balancing
> pass in on $ExtIf route-to { ($IntIf 3.4.5.6), ($IntIf 3.4.5.7),
> ($IntIf 3.4.5.8), ($IntIf 3.4.5.9) } round-robin proto tcp from any to
> <BalanceBlocks> port 80
>
> Try enabling sticky connections here.
--
Ermal
------------------------------
Message: 10
Date: Tue, 15 Dec 2009 10:01:47 -0500
From: Linda Messerschmidt <linda.mes...@gmail.com>
Subject: Re: Lots of weird PF behavior on 7.2-STABLE
To: Ermal Lu?i <e...@freebsd.org>
Cc: freeb...@freebsd.org
Message-ID:
<237c27100912150701w9f...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
On Tue, Dec 15, 2009 at 4:55 AM, Ermal Lu�i <e...@freebsd.org> wrote:
> Try enabling sticky connections here.
As a practical matter we don't care if two connections from the same
client go to the same server or not. Is there some reason to suspect
that this option would alter the behavior of single connections, like
the problem we're having?
Although even in that case, all the servers on the same interface so
if it were a problem with load balancing, I would expect to see the
stray packets addressed to the wrong MAC address, not to have them
disappear completely.
Thanks!
------------------------------
Message: 11
Date: Tue, 15 Dec 2009 16:08:49 +0000
From: Peter Maxwell <pe...@allicient.co.uk>
Subject: Re: Lots of weird PF behavior on 7.2-STABLE
To: Linda Messerschmidt <linda.mes...@gmail.com>,
freeb...@freebsd.org
Message-ID:
<7731938b0912150808y5c...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Hi Linda,
I'm pretty sure you can run tcpdump against a packet capture from the
pflog interface on the pf box; that will include fields like
block/pass and rule number for each packet filtered. That way you at
least know what rule is dropping/passing your packets. And if my
memory serves me right, pf uses a default pass rule - if it were me
I'd check that the SYN-ACK from the webserver isn't creating a second
state table entry using the default pass rule, or something equally as
annoying.
It is also possible I'm completely wrong, as it's been a while since
I've actually messed about with pf in any meaningful way.
However one thing that I would strongly suggest is using proper packet
filter design: either decide upon a default deny then pass what you
want, or decide on a default pass and only deny what is bad. This
methodology applies to any firewall whether pf, checkpoint, cisco,
etc. If you're having to use the "quick" keyword, you've probably*
done something wrong. The default deny approach is usually
preferable, so you should have one block all rule at the top of the
ruleset then all other rules should be pass rules.
Best wishes,
Peter
* there are some situations where you may have to use quick, but not
particularly often.
2009/12/15 Linda Messerschmidt <linda.mes...@gmail.com>:
> 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 <mss 1460,nop,wscale
> 9,sackOK,timestamp 953726452 0>
> 20:00:02.038328 IP 5.6.7.8.80 > 1.2.3.4.61645: S 40565958:40565958(0)
> ack 620577088 win 0 <mss 1460>
> 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 <mss 1460,nop,wscale
> 9,sackOK,timestamp 953726452 0>
> 20:00:02.038311 IP 5.6.7.8.80 > 1.2.3.4.61645: S 40565958:40565958(0)
> ack 620577088 win 0 <mss 1460>
> 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 2000000
>
> 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 2000000
> set timeout tcp.established 86400
> set timeout tcp.closed 5
> set timeout tcp.closing 30
>
> ExtIf = "em0"
> IntIf = "em1"
>
> table <NoRouteIPs> { 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 <OurIPs> { ... }
> table <DNSServers> { ... }
> table <BalanceBlocks> { ... }
>
> scrub
>
> ## �Block Reserved Addresses
> block log quick on $ExtIf from <NoRouteIPs> to any
> block log quick on $ExtIf from any to <NoRouteIPs>
>
> ## �Block our own Addresses
> block in log quick on $ExtIf inet from <OurIPs> to any
>
> ## �Anti-DDOS
> table <AntiDDOS> persist
> block quick from <AntiDDOS> to any
> block quick from any to <AntiDDOS>
>
> ## �Block HTTP traffic to DNS servers
> block quick inet proto tcp from any to <DNSServers> port 80
>
> ## �Weird DNS people added 2009-06-18
> block drop log quick proto 255
> table <GTExperimentDNS> { 61.220.4.0/24 }
> block drop in quick proto { udp, tcp } from <GTExperimentDNS> to any port 53
>
> ## Load Balancing
> pass in on $ExtIf route-to { ($IntIf 3.4.5.6), ($IntIf 3.4.5.7),
> ($IntIf 3.4.5.8), ($IntIf 3.4.5.9) } round-robin proto tcp from any to
> <BalanceBlocks> port 80
> _______________________________________________
> freeb...@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-pf
> To unsubscribe, send any mail to "freebsd-pf-...@freebsd.org"
>
------------------------------
Message: 12
Date: Tue, 15 Dec 2009 14:14:08 -0500
From: Linda Messerschmidt <linda.mes...@gmail.com>
Subject: Re: Lots of weird PF behavior on 7.2-STABLE
To: Peter Maxwell <pe...@allicient.co.uk>
Cc: freeb...@freebsd.org
Message-ID:
<237c27100912151114w691...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
On Tue, Dec 15, 2009 at 11:08 AM, Peter Maxwell <pe...@allicient.co.uk> wrote:
> I'm pretty sure you can run tcpdump against a packet capture from the
> pflog interface on the pf box; that will include fields like
> block/pass and rule number for each packet filtered.
I have done that with "log" on all block rules. The packets shown as
missing are *not* present in the dump when I do, so as far as I can
tell they are not being dropped by a filter rule. Which makes sense,
since none of the few block rules we have would touch packets in the
middle of an established connection that was permitted.
For comparison, endless streams of packets from those DNS guys we
block *are* present in the tcpdump output, exactly as you describe, so
I know pflog is working.
So it really seems like something wrong in the internals of pf. I
just don't know how to pursue it further.
> However one thing that I would strongly suggest is using proper packet
> filter design: either decide upon a default deny then pass what you
> want, or decide on a default pass and only deny what is bad.
We are doing the latter; default pass and denying only what is bad.
This isn't even really a firewall, it's for load balancing web
connections. We just threw a couple of block rules in there because
it was a good place to stop a particular attack. There are other
"default deny" firewalls on other machines that handle all the traffic
that isn't getting diverted by the load balance rule.
> If you're having to use the "quick" keyword, you've probably*
> done something wrong.
Since we are using load balancing, the "pass" rule that wouldn't pass
all the traffic we've just gone to the trouble to block would be
outrageously complex. Hence, quick.
If a case can be made that the use of "quick" is causing our packets
to disappear, we'd probably be willing to tackle trying to restructure
the rules.
Thanks!
------------------------------
Message: 13
Date: Tue, 15 Dec 2009 20:33:24 +0000
From: Peter Maxwell <pe...@allicient.co.uk>
Subject: Re: Lots of weird PF behavior on 7.2-STABLE
To: Linda Messerschmidt <linda.mes...@gmail.com>,
freeb...@freebsd.org
Message-ID:
<7731938b0912151233u6d6...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
2009/12/15 Linda Messerschmidt <linda.mes...@gmail.com>:
> On Tue, Dec 15, 2009 at 11:08 AM, Peter Maxwell <pe...@allicient.co.uk> wrote:
>> I'm pretty sure you can run tcpdump against a packet capture from the
>> pflog interface on the pf box; that will include fields like
>> block/pass and rule number for each packet filtered.
>
> I have done that with "log" on all block rules. �The packets shown as
> missing are *not* present in the dump when I do, so as far as I can
> tell they are not being dropped by a filter rule. �Which makes sense,
> since none of the few block rules we have would touch packets in the
> middle of an established connection that was permitted.
Although it's not likely to be causing the problem (the default
"flags" on tcp rules are S/SA, which should exclude this possibility),
I'd check that the implicit pass rule isn't getting hit by the web
traffic. Add in an explicit "pass all" rule at the start and set the
log keyword on it. Make sure *none* of the web traffic is hitting
this rule.
>
> For comparison, endless streams of packets from those DNS guys we
> block *are* present in the tcpdump output, exactly as you describe, so
> I know pflog is working.
>
> So it really seems like something wrong in the internals of pf. �I
> just don't know how to pursue it further.
If the box isn't too loaded, you may try using "log (all)" on the pass
rules (so that ALL packets are logged, not just the initial SYN) -
that way at least you'd find out which rules those data packets are
hitting, which would likely pin down the problem quite a bit.. those
missing packets must have went somewhere ;-) If it were me, that
would be my preferable option if it was available.
Barring that, I'd suggest simplifying your setup as much as possible -
is there too much traffic to remove the "route-to" and try it against
a single webserver? If it's not possible, you could try setting up a
simple TCP service on internal hosts and get something that works,
then build up (ECHO or TIME are not bad for this).
I'd also suggest removing the "scrub" directive until you have it
working properly. Is the "state-policy" floating or if-bound?
Does the problem affect other services in a similar manner, can you
replicate the exact same problem with the web servers with sshd, for
example?
What's annoying me is that I'm fairly sure I've seen this problem
before, but for the life of me I can't remember what caused it :-(
>
>> However one thing that I would strongly suggest is using proper packet
>> filter design: either decide upon a default deny then pass what you
>> want, or decide on a default pass and only deny what is bad.
>
> We are doing the latter; default pass and denying only what is bad.
> This isn't even really a firewall, it's for load balancing web
> connections. �We just threw a couple of block rules in there because
> it was a good place to stop a particular attack. �There are other
> "default deny" firewalls on other machines that handle all the traffic
> that isn't getting diverted by the load balance rule.
>
>> If you're having to use the "quick" keyword, you've probably*
>> done something wrong.
>
> Since we are using load balancing, the "pass" rule that wouldn't pass
> all the traffic we've just gone to the trouble to block would be
> outrageously complex. �Hence, quick.
>
pf uses the last rule in the ruleset that matches for a given packet,
so for a first instance setup I'd suggest putting an explicit "pass
all" as the first rule, then any pass rules that do load-balancing and
the like, then a list of block rules. It makes it a lot easier to
read and debug. Then once it's working as you want, you can move the
block rules up to the top and add in the "quick" keyword for
performance purposes.
> If a case can be made that the use of "quick" is causing our packets
> to disappear, we'd probably be willing to tackle trying to restructure
> the rules.
>
> Thanks!
>
------------------------------
Message: 14
Date: Tue, 15 Dec 2009 16:37:14 -0500
From: Linda Messerschmidt <linda.mes...@gmail.com>
Subject: Re: Lots of weird PF behavior on 7.2-STABLE
To: Peter Maxwell <pe...@allicient.co.uk>
Cc: freeb...@freebsd.org
Message-ID:
<237c27100912151337y27c...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
On Tue, Dec 15, 2009 at 3:33 PM, Peter Maxwell <pe...@allicient.co.uk> wrote:
> Add in an explicit "pass all" rule at the start and set the
> log keyword on it. �Make sure *none* of the web traffic is hitting
> this rule.
> If the box isn't too loaded, you may try using "log (all)" on the pass
> rules (so that ALL packets are logged, not just the initial SYN) -
> that way at least you'd find out which rules those data packets are
> hitting, which would likely pin down the problem quite a bit.. those
> missing packets must have went somewhere ;-) �If it were me, that
> would be my preferable option if it was available.
> Barring that, I'd suggest simplifying your setup as much as possible -
> is there too much traffic to remove the "route-to" and try it against
> a single webserver?
> I'd also suggest removing the "scrub" directive until you have it
> working properly.
These are all great suggestions, but I will probably have to wait
until the middle of the night to try them just in case of catastrophe.
:) I will report back what I find.
>�Is the "state-policy" floating or if-bound?
I don't know what that means. :( I'll check the manual. But it's
whatever the default is; I didn't leave anything but IP addresses out
of the config file.
> Does the problem affect other services in a similar manner, can you
> replicate the exact same problem with the web servers with sshd, for
> example?
In theory it probably affects DNS as well (the other service being
load balanced), but since that's a UDP protocol.
When it happens to my ssh sessions, it seems to happen to all of them at once.
> What's annoying me is that I'm fairly sure I've seen this problem
> before, but for the life of me I can't remember what caused it :-(
Oh no!
> pf uses the last rule in the ruleset that matches for a given packet,
> so for a first instance setup I'd suggest putting an explicit "pass
> all" as the first rule, then any pass rules that do load-balancing and
> the like, then a list of block rules. �It makes it a lot easier to
> read and debug. �Then once it's working as you want, you can move the
> block rules up to the top and add in the "quick" keyword for
> performance purposes.
We could probably do that while nothing bad is happening, as long as
we get it done before the next time we get DDOS'd. At such times, we
really don't want hundreds of megs of garbage going through the load
balance rule, so "quick" becomes pretty important. :) But in the
everyday case, we can squeak by the other way long enough to test.
Thanks!
------------------------------
Message: 15
Date: Tue, 15 Dec 2009 19:59:23 -0500
From: David Mehler <dave....@gmail.com>
Subject: new firewall config
To: freeb...@freebsd.org
Message-ID:
<78e0dabc0912151659h5d2...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Hello,
I'm writing a new firewall for an 8.0 machine. It's a gateway box, it
runs an ftp proxy, dhcp and dns services and ntp. It also routes.
Other than that it should block everything else. I've got the below
rules, and am wondering since it works if it's the most efficient it
can be or if there are any holes in it?
Comments appreciated.
Thanks.
Dave.
# Required order: options, normalization, queueing, translation, filtering.
# Macros and tables may be defined and used anywhere.
ext_if="em0" # replace with actual external interface name i.e., dc0
int_if="em1" # replace with actual internal interface name i.e., dc1
internal_net="192.168.5.0/24"
tcp_services="{ ftp-data, ftp, ssh, domain, http, pop3, https, 1503,
1863, 3389, 5999, 7001, 8000, 8080 }"
udp_services="{ 9, domain, bootps, ntp, 7001 }"
icmp_types = "echoreq"
set optimization normal
set block-policy return
set require-order yes
set fingerprints "/etc/pf.os"
set skip on lo0
scrub in all
nat on $ext_if from $internal_net to any -> ($ext_if)
nat-anchor "ftp-proxy/*"
rdr-anchor "ftp-proxy/*"
rdr pass on $int_if proto tcp from any to any port ftp -> 127.0.0.1 \
port 8021
antispoof for $ext_if
antispoof for $int_if
block all
anchor "ftp-proxy/*"
pass out proto tcp from 127.0.0.1 to any port 21 keep state
pass quick inet proto tcp to any port $tcp_services flags S/SA keep state
pass quick inet proto { tcp, udp } to any port $udp_services keep state
pass inet proto icmp all icmp-type $icmp_types keep state
pass inet proto icmp all icmp-type unreach code needfrag keep state
# allow out the default range for traceroute(8):
# "base+nhops*nqueries-1" (33434+64*3-1)
pass inet proto udp from any to any \
port 33433 >< 33626 keep state
------------------------------
Message: 16
Date: Wed, 16 Dec 2009 11:50:16 +0000
From: Greg Hennessy <Greg.H...@nviz.net>
Subject: RE: new firewall config
To: "freeb...@freebsd.org" <freeb...@freebsd.org>
Message-ID:
<9E8D76EC267C9444AC737...@PEMEXMBXVS02.jellyfishnet.co.uk.local>
Content-Type: text/plain; charset="us-ascii"
s/block all/block log all/
Or debug will come back and bite you.
Regards
Greg
-----Original Message-----
From: owner-fr...@freebsd.org [mailto:owner-fr...@freebsd.org] On Behalf Of David Mehler
Sent: 16 December 2009 12:59 AM
To: freeb...@freebsd.org
Subject: new firewall config
Hello,
I'm writing a new firewall for an 8.0 machine. It's a gateway box, it
runs an ftp proxy, dhcp and dns services and ntp. It also routes.
Other than that it should block everything else. I've got the below
rules, and am wondering since it works if it's the most efficient it
can be or if there are any holes in it?
Comments appreciated.
Thanks.
Dave.
# Required order: options, normalization, queueing, translation, filtering.
# Macros and tables may be defined and used anywhere.
ext_if="em0" # replace with actual external interface name i.e., dc0
int_if="em1" # replace with actual internal interface name i.e., dc1
internal_net="192.168.5.0/24"
tcp_services="{ ftp-data, ftp, ssh, domain, http, pop3, https, 1503,
1863, 3389, 5999, 7001, 8000, 8080 }"
udp_services="{ 9, domain, bootps, ntp, 7001 }"
icmp_types = "echoreq"
set optimization normal
set block-policy return
set require-order yes
set fingerprints "/etc/pf.os"
set skip on lo0
scrub in all
nat on $ext_if from $internal_net to any -> ($ext_if)
nat-anchor "ftp-proxy/*"
rdr-anchor "ftp-proxy/*"
rdr pass on $int_if proto tcp from any to any port ftp -> 127.0.0.1 \
port 8021
antispoof for $ext_if
antispoof for $int_if
block all
anchor "ftp-proxy/*"
pass out proto tcp from 127.0.0.1 to any port 21 keep state
pass quick inet proto tcp to any port $tcp_services flags S/SA keep state
pass quick inet proto { tcp, udp } to any port $udp_services keep state
pass inet proto icmp all icmp-type $icmp_types keep state
pass inet proto icmp all icmp-type unreach code needfrag keep state
# allow out the default range for traceroute(8):
# "base+nhops*nqueries-1" (33434+64*3-1)
pass inet proto udp from any to any \
port 33433 >< 33626 keep state
------------------------------
Message: 17
Date: Wed, 16 Dec 2009 18:20:04 +0000
From: Tom Judge <t...@tomjudge.com>
Subject: Re: PF Transparent Bridge Firewall + CARP
To: Kevin <k...@kevinkevin.com>
Cc: freeb...@freebsd.org
Message-ID: <4B2924D4...@tomjudge.com>
Content-Type: text/plain; charset=ISO-8859-1
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Kevin wrote:
>
>> -----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?
This would be easier to do with spanning tree:
[router]
|
[------switch 1------]
| |
[FW1]--{pfsync}--[FW2]
| |
[------switch 2------]
|
[clients]
Then you can leave carp out of the equation and your network would be
the same as before.
FW1 /etc/rc.conf:
cloned_interfaces="bridge0"
ifconfig_em0="up -tso"
ifconfig_em1="up -tso"
ifconfig_em2="inet 192.168.255.1/30"
ifconfig_bridge0="up addm em0 stp em0 addm em1 stp em1"
pfsync_enable="YES"
pfsync_syncdev="em2"
pfsync_ifconfig="syncpeer 192.168.255.2"
FW2 /etc/rc.conf:
cloned_interfaces="bridge0"
ifconfig_em0="up -tso"
ifconfig_em1="up -tso"
ifconfig_em2="inet 192.168.255.2/30"
ifconfig_bridge0="up addm em0 stp em0 addm em1 stp em1"
pfsync_enable="YES"
pfsync_syncdev="em2"
pfsync_ifconfig="syncpeer 192.168.255.1"
Make sure that the spanning tree priority on either switch side is
higher (smaller number) than the bridges so that they will remain the
root bridges.
Tom
- --
TJU13-ARIN
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.13 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJLKSTUAAoJEMSwVS7lr0OdVpMH/A1zQdIxKTiwm12dIklzCg4w
CFp09ZPQEK3zjkes2qUpf6VGvg88rhhQE6iMn/BLIYhpdsqmoejHB2a3k397/qKq
yevnl4iyB2xaOTZhbIufasI+dtMy1t30ZET4NlMSFZKEsIm6KQGVX8Il2DqyW2AB
xW79glm6/YSHUnBCcL9UGEQzIOtkeqsApNAGIQc2TWvQUz0z7jbKaBU72dhl/Yni
+ys3tG7/4m4/2ybMVNW+pjs4/TlEwz31HOgM96MfEkgl0xss4k249kSSnYvn5SZ5
lqre6l+xU2WgSVVXydzIJPNNYSThZrJhTfRNYMBv0bF0covT9aZ2IPzLxoqNeAg=
=KoIu
-----END PGP SIGNATURE-----
------------------------------
Message: 18
Date: Wed, 16 Dec 2009 14:25:06 -0500
From: "Kevin" <k...@kevinkevin.com>
Subject: RE: PF Transparent Bridge Firewall + CARP
To: "'Tom Judge'" <t...@tomjudge.com>
Cc: freeb...@freebsd.org
Message-ID: <005301ca7e85$7a992f10$6fcb8d30$@com>
Content-Type: text/plain; charset="us-ascii"
> -----Original Message-----
> From: Tom Judge
> Sent: Wednesday, December 16, 2009 1:20 PM
> To: Kevin
> Cc: freeb...@freebsd.org
> Subject: Re: PF Transparent Bridge Firewall + CARP
>
> [router]
> |
> [------switch 1------]
> | |
> [FW1]--{pfsync}--[FW2]
> | |
> [------switch 2------]
> |
> [clients]
My environment would be better described as the following :
[router]
|
[------switch 1 [vlan1]------]
| |
[FW1]--{pfsync}--[FW2]
| |
[------switch 1 [vlan2]------]
|
[clients]
Also, I'm assumine em2 is a physical interface, which I probably will have
to implement on fw2. Do you forsee problems doing this through vlans instead
of two switches?
Thanks.
------------------------------
Message: 19
Date: Wed, 16 Dec 2009 19:47:33 +0000
From: Tom Judge <t...@tomjudge.com>
Subject: Re: PF Transparent Bridge Firewall + CARP
To: Kevin <k...@kevinkevin.com>
Cc: freeb...@freebsd.org
Message-ID: <4B293955...@tomjudge.com>
Content-Type: text/plain; charset=ISO-8859-1
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Kevin wrote:
>
>
>
> My environment would be better described as the following :
>
> [router]
> |
> [------switch 1 [vlan1]------]
> | |
> [FW1]--{pfsync}--[FW2]
> | |
> [------switch 1 [vlan2]------]
> |
> [clients]
>
> Also, I'm assumine em2 is a physical interface, which I probably will have
> to implement on fw2. Do you forsee problems doing this through vlans instead
> of two switches?
>
This poses some interesting questions:
1) Do you have 2 physical interfaces in each FW?
2) If the answer to 1 in yes, your ports into vlan 1+2 are access ports?
3) If you disable spanning tree in the ports will the switch forward the
STP BPDUS ingressing on one port to another port on the switch (that has
STP disabled)?
If you and up with 1-3 yes then you are ok with one switch if any is no
then you will need to get a second switch.
You may be able to achieve the desired results with one switch if your
switch supports MSTP but I have never tried it. I assume that the port
would be detected as RSTP and the switch would convert the RSTP frame
into an MSTP frame with the appropriate vlans bits toggled.
Tom
- --
TJU13-ARIN
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.13 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJLKTlUAAoJEMSwVS7lr0OdWJoH/1AAkR6DcGBHXbIjIYKGrllP
0Q0Zbgj5dDOcsuPt2qSbpA3Wj0uCk2GeE2ZL7k4IkhurnXZH1o9FxfcZCqRE/KfV
UbCvxwp5II5dFu099ioL77XzevJHQyQerzKPManEafzR74WxEbTfzSbgPE6cjDzj
xDO8jNilHbeAzRPhYF0AOjTgOCkHPyEXchgVtwGKYh6Hq70BurnL/8x0zp2koHgL
kKgjpVZF+ZNlBRvTYyI9J4UTQkArfAxCPQg72wUEmqO1B4E1V1gdqq6sHt2U4OKW
oRVzfA6cy/2TT0rk6e55MD7+GqPnOF2jsAE0P3sLS3QYAIirEBDsRPcDlKOqaq8=
=7p+9
-----END PGP SIGNATURE-----
------------------------------
Message: 20
Date: Fri, 18 Dec 2009 11:50:50 +0000 (UTC)
From: "Helmut Schneider" <jump...@gmx.de>
Subject: Re: Lots of weird PF behavior on 7.2-STABLE
To: freeb...@freebsd.org
Message-ID: <xn0gj1op...@news.gmane.org>
Content-Type: text/plain; charset=iso-8859-1
Linda Messerschmidt wrote:
> 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.
If no suggestion helped so far try to scrub the mss to a smaller value
like 1400 or even lower.
Helmut
------------------------------
Message: 21
Date: Fri, 18 Dec 2009 16:14:47 +0100
From: "pierre.reveillon" <pierre.r...@gmail.com>
Subject: Network ACK loss problem
To: freeb...@freebsd.org
Cc: freeb...@freebsd.org
Message-ID: <4B2B9C67...@gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Hi,
I just upgraded a server to 8.0_RELEASE and I started having network
problems when pf is enabled (even with only "pass all" rules).
It seems that some ACK are loss (see tcpdump results at the end).
I still have some strange mail server problems when pf is disabled but
I'm not sure it's linked.
Thanks,
Pierre
Informations about my configuration :
[root@papaya ~]# uname -a
FreeBSD papaya.yyy.net 8.0-RELEASE FreeBSD 8.0-RELEASE #0: Sat Nov 21
15:48:17 UTC 2009
ro...@almeida.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386
[root@papaya ~]# dmesg | grep vge0
vge0: <VIA Networking Gigabit Ethernet> port 0xfc00-0xfcff mem
0xfdfff000-0xfdfff0ff irq 18 at device 14.0 on pci0
miibus0: <MII bus> on vge0
vge0: WARNING: using obsoleted if_watchdog interface
vge0: Ethernet address: 00:xx:xx:xx:xx:xx
vge0: [ITHREAD]
vge0: link state changed to UP
vge0: promiscuous mode enabled
vge0: promiscuous mode disabled
[root@papaya ~]# pfctl -sr
No ALTQ support in kernel
ALTQ related functions disabled
pass in all flags S/SA keep state
pass out all flags S/SA keep state
Tcpdump output:
********************
BAD ONE (pf enabled)
********************
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
15:29:26.847488 IP bagherra.local.42567 > papaya.yyy.net.www: Flags [S],
seq 4010981448, win 5840, options [mss 1460,sackOK,TS val 27823034 ecr
0,nop,wscale 7], length 0
15:29:26.891968 IP papaya.yyy.net.www > bagherra.local.42567: Flags
[S.], seq 3588656077, ack 4010981449, win 65535, options [mss
1412,nop,wscale 3,sackOK,TS val 1087266140 ecr 27823034], length 0
15:29:26.892034 IP bagherra.local.42567 > papaya.yyy.net.www: Flags [.],
ack 1, win 46, options [nop,nop,TS val 27823045 ecr 1087266140], length 0
15:29:26.892281 IP bagherra.local.42567 > papaya.yyy.net.www: Flags
[P.], seq 1:120, ack 1, win 46, options [nop,nop,TS val 27823045 ecr
1087266140], length 119
15:29:26.982496 IP papaya.yyy.net.www > bagherra.local.42567: Flags [.],
seq 1:1401, ack 120, win 8225, options [nop,nop,TS val 1087266186 ecr
27823045], length 1400
15:29:26.982536 IP bagherra.local.42567 > papaya.yyy.net.www: Flags [.],
ack 1401, win 69, options [nop,nop,TS val 27823068 ecr 1087266186], length 0
15:29:27.027653 IP papaya.yyy.net.www > bagherra.local.42567: Flags [.],
seq 1401:2801, ack 120, win 8225, options [nop,nop,TS val 1087266275 ecr
27823068], length 1400
15:29:27.028035 IP papaya.yyy.net.www > bagherra.local.42567: Flags [.],
seq 2801:4201, ack 120, win 8225, options [nop,nop,TS val 1087266275 ecr
27823068], length 1400
15:29:27.446470 IP papaya.yyy.net.www > bagherra.local.42567: Flags [.],
seq 1401:2801, ack 120, win 8225, options [nop,nop,TS val 1087266694 ecr
27823068], length 1400
15:29:28.082905 IP papaya.yyy.net.www > bagherra.local.42567: Flags [.],
seq 1401:2801, ack 120, win 8225, options [nop,nop,TS val 1087267331 ecr
27823068], length 1400
15:29:29.156079 IP papaya.yyy.net.www > bagherra.local.42567: Flags [.],
seq 1401:2801, ack 120, win 8225, options [nop,nop,TS val 1087268404 ecr
27823068], length 1400
15:29:31.100271 IP papaya.yyy.net.www > bagherra.local.42567: Flags [.],
seq 1401:2801, ack 120, win 8225, options [nop,nop,TS val 1087270349 ecr
27823068], length 1400
15:29:34.788167 IP papaya.yyy.net.www > bagherra.local.42567: Flags [.],
seq 1401:2801, ack 120, win 8225, options [nop,nop,TS val 1087274038 ecr
27823068], length 1400
15:29:40.266521 IP papaya.yyy.net.www > bagherra.local.42567: Flags [.],
seq 1401:2801, ack 120, win 8225, options [nop,nop,TS val 1087279519 ecr
27823068], length 1400
15:29:51.023919 IP papaya.yyy.net.www > bagherra.local.42567: Flags [.],
seq 1401:2801, ack 120, win 8225, options [nop,nop,TS val 1087290280 ecr
27823068], length 1400
15:30:12.336745 IP papaya.yyy.net.www > bagherra.local.42567: Flags [.],
seq 1401:2801, ack 120, win 8225, options [nop,nop,TS val 1087311601 ecr
27823068], length 1400
15:30:54.762699 IP papaya.yyy.net.www > bagherra.local.42567: Flags [.],
seq 1401:2801, ack 120, win 8225, options [nop,nop,TS val 1087354042 ecr
27823068], length 1400
15:31:58.740422 IP papaya.yyy.net.www > bagherra.local.42567: Flags [.],
seq 1401:2801, ack 120, win 8225, options [nop,nop,TS val 1087418043 ecr
27823068], length 1400
15:33:02.718736 IP papaya.yyy.net.www > bagherra.local.42567: Flags [.],
seq 1401:2801, ack 120, win 8225, options [nop,nop,TS val 1087482044 ecr
27823068], length 1400
15:34:06.696421 IP papaya.yyy.net.www > bagherra.local.42567: Flags [.],
seq 1401:2801, ack 120, win 8225, options [nop,nop,TS val 1087546045 ecr
27823068], length 1400
**********************
GOOD ONE (pf disabled)
**********************
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
15:35:20.857405 IP bagherra.local.52734 > papaya.yyy.net.www: Flags [S],
seq 989268196, win 5840, options [mss 1460,sackOK,TS val 27911536 ecr
0,nop,wscale 7], length 0
15:35:20.901493 IP papaya.yyy.net.www > bagherra.local.52734: Flags
[S.], seq 2220327620, ack 989268197, win 65535, options [mss
1412,nop,wscale 3,sackOK,TS val 1324570413 ecr 27911536], length 0
15:35:20.901541 IP bagherra.local.52734 > papaya.yyy.net.www: Flags [.],
ack 1, win 46, options [nop,nop,TS val 27911548 ecr 1324570413], length 0
15:35:20.901682 IP bagherra.local.52734 > papaya.yyy.net.www: Flags
[P.], seq 1:120, ack 1, win 46, options [nop,nop,TS val 27911548 ecr
1324570413], length 119
15:35:20.949199 IP papaya.yyy.net.www > bagherra.local.52734: Flags [.],
seq 1:1401, ack 120, win 8225, options [nop,nop,TS val 1324570459 ecr
27911548], length 1400
15:35:20.949243 IP bagherra.local.52734 > papaya.yyy.net.www: Flags [.],
ack 1401, win 69, options [nop,nop,TS val 27911559 ecr 1324570459], length 0
15:35:20.994274 IP papaya.yyy.net.www > bagherra.local.52734: Flags [.],
seq 1401:2801, ack 120, win 8225, options [nop,nop,TS val 1324570504 ecr
27911559], length 1400
15:35:20.994310 IP bagherra.local.52734 > papaya.yyy.net.www: Flags [.],
ack 2801, win 91, options [nop,nop,TS val 27911571 ecr 1324570504], length 0
15:35:20.994758 IP papaya.yyy.net.www > bagherra.local.52734: Flags [.],
seq 2801:4201, ack 120, win 8225, options [nop,nop,TS val 1324570504 ecr
27911559], length 1400
15:35:20.994772 IP bagherra.local.52734 > papaya.yyy.net.www: Flags [.],
ack 4201, win 114, options [nop,nop,TS val 27911571 ecr 1324570504],
length 0
15:35:21.038843 IP papaya.yyy.net.www > bagherra.local.52734: Flags [.],
seq 4201:5601, ack 120, win 8225, options [nop,nop,TS val 1324570549 ecr
27911571], length 1400
15:35:21.038876 IP bagherra.local.52734 > papaya.yyy.net.www: Flags [.],
ack 5601, win 137, options [nop,nop,TS val 27911582 ecr 1324570549],
length 0
15:35:21.039366 IP papaya.yyy.net.www > bagherra.local.52734: Flags [.],
seq 5601:7001, ack 120, win 8225, options [nop,nop,TS val 1324570549 ecr
27911571], length 1400
15:35:21.039383 IP bagherra.local.52734 > papaya.yyy.net.www: Flags [.],
ack 7001, win 159, options [nop,nop,TS val 27911582 ecr 1324570549],
length 0
15:35:21.040337 IP papaya.yyy.net.www > bagherra.local.52734: Flags [.],
seq 7001:8401, ack 120, win 8225, options [nop,nop,TS val 1324570550 ecr
27911571], length 1400
15:35:21.040351 IP bagherra.local.52734 > papaya.yyy.net.www: Flags [.],
ack 8401, win 182, options [nop,nop,TS val 27911582 ecr 1324570550],
length 0
15:35:21.084159 IP papaya.yyy.net.www > bagherra.local.52734: Flags [.],
seq 8401:9801, ack 120, win 8225, options [nop,nop,TS val 1324570594 ecr
27911582], length 1400
15:35:21.084201 IP bagherra.local.52734 > papaya.yyy.net.www: Flags [.],
ack 9801, win 204, options [nop,nop,TS val 27911593 ecr 1324570594],
length 0
15:35:21.085054 IP papaya.yyy.net.www > bagherra.local.52734: Flags [.],
seq 9801:11201, ack 120, win 8225, options [nop,nop,TS val 1324570595
ecr 27911582], length 1400
15:35:21.085076 IP bagherra.local.52734 > papaya.yyy.net.www: Flags [.],
ack 11201, win 227, options [nop,nop,TS val 27911593 ecr 1324570595],
length 0
15:35:21.085088 IP papaya.yyy.net.www > bagherra.local.52734: Flags
[P.], seq 11201:11727, ack 120, win 8225, options [nop,nop,TS val
1324570595 ecr 27911582], length 526
15:35:21.085098 IP bagherra.local.52734 > papaya.yyy.net.www: Flags [.],
ack 11727, win 249, options [nop,nop,TS val 27911593 ecr 1324570595],
length 0
15:35:21.085950 IP bagherra.local.52734 > papaya.yyy.net.www: Flags
[F.], seq 120, ack 11727, win 249, options [nop,nop,TS val 27911594 ecr
1324570595], length 0
15:35:21.131345 IP papaya.yyy.net.www > bagherra.local.52734: Flags [.],
ack 121, win 8225, options [nop,nop,TS val 1324570642 ecr 27911594],
length 0
15:35:21.131563 IP papaya.yyy.net.www > bagherra.local.52734: Flags
[F.], seq 11727, ack 121, win 8225, options [nop,nop,TS val 1324570642
ecr 27911594], length 0
15:35:21.131596 IP bagherra.local.52734 > papaya.yyy.net.www: Flags [.],
ack 11728, win 249, options [nop,nop,TS val 27911605 ecr 1324570642],
length 0
------------------------------
Message: 22
Date: Mon, 21 Dec 2009 11:43:53 +0545
From: Gaurav Ghimire <gau...@subisu.net.np>
Subject: External scripts with PF.
To: freeb...@freebsd.org
Message-ID: <4B2F0E9D...@subisu.net.np>
Content-Type: text/plain; charset=ISO-8859-1
Hi all,
Are there any possibilities that I could run a script (bash, perl) when
any rule is matched.
For example, I have some distinct rule and want to get an alert email
each time any connection threshold is crossed on it from a singe IP. Say
I want one IP only have 1 http connection to a web service in my server,
if it goes 2 pf would update a table or run a external script that would
alert me about that IP.
This is just a concept and I am not doing it in real.
Just wanted to know if there are any possibilities that I could run
external scripts or invoke them when a rule is matched.
I would appreciate any hints or references.
Regards,
--
Gaurav Ghimire
System Administrator - Systems (R&D)
Subisu Cablenet (P.) Ltd.
148 Thirbum Sadak
Baluwatar, Kathmandu
Nepal
T: 00977 1 4429616/17 Ext.: 121
F: 00977 1 4430572
(An ISO 9001:2000 Certified Company)
------------------------------
Message: 23
Date: Mon, 21 Dec 2009 04:03:06 -0500
From: Tom Uffner <t...@uffner.com>
Subject: Re: External scripts with PF.
To: Gaurav Ghimire <gau...@subisu.net.np>
Cc: freeb...@freebsd.org
Message-ID: <4B2F39CA...@uffner.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Gaurav Ghimire wrote:
> Are there any possibilities that I could run a script (bash, perl) when
> any rule is matched.
make sure the rule you want to trigger your script includes "log".
have your script tail pflog, and watch for your trigger rule before
performing its action.
------------------------------
Message: 24
Date: Mon, 21 Dec 2009 11:07:00 GMT
From: FreeBSD bugmaster <bugm...@FreeBSD.org>
Subject: Current problem reports assigned to freeb...@FreeBSD.org
To: freeb...@FreeBSD.org
Message-ID: <200912211107....@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/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/86635 pf [patch] pfctl(8): allow new page character (^L) in pf.
o kern/82271 pf [pf] cbq scheduler cause bad latency
37 problems total.
------------------------------
Message: 25
Date: Mon, 21 Dec 2009 14:57:57 +0000
From: Peter Maxwell <pe...@allicient.co.uk>
Subject: Re: External scripts with PF.
To: Tom Uffner <t...@uffner.com>, freeb...@freebsd.org
Message-ID:
<7731938b0912210657q756...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
2009/12/21 Tom Uffner <t...@uffner.com>:
> Gaurav Ghimire wrote:
>>
>> Are there any possibilities that I could run a script (bash, perl) when
>> any rule is matched.
>
> make sure the rule you want to trigger your script includes "log".
>
> have your script tail pflog, and watch for your trigger rule before
> performing its action.
Erm, not to sound completely ignorant but I'm assuming that implies he
has to write a perl script to parse binary output? He can't pipe it
though tcpdump as that would be a seriously bad idea.
------------------------------
End of freebsd-pf Digest, Vol 273, Issue 1
******************************************