On Mon, Jun 29, 2015 at 10:52:01AM +0200, Milan Obuch wrote:
Does this answerred your question fully or something more would be
usefull?
How are you doing ARP?
You're not assigning every address on x.y.26.0/23 as an alias, are you?
So who answers ARP requests of the upstream router?
Daniel
On Sun, Jun 21, 2015 at 01:32:36PM +0200, Milan Obuch wrote:
One observation, on pfctl -vs info output - when src-limit counters
rises to 30 or so, I am getting first messages someone has problem. Is
it only coincidence or is there really some relation to my problem?
This might be a clue.
On Sun, Jun 28, 2015 at 10:06:09AM +0200, Milan Obuch wrote:
So, now I am at 10.2-PRERELEASE, r284884, and the issue is still here.
It is totally weird, just change of IP the device is being natted to
makes the issue disappear for this particular customer, but as soon as
this exact IP is used
On Mon, Jun 29, 2015 at 10:52:01AM +0200, Milan Obuch wrote:
Does this answerred your question fully or something more would be
usefull?
Which one is the magical IP address, i.e. the one that causes trouble
once it's being used (I guess from x.y.26.0/27)?
It's always the same one, even across
On Thu, Sep 25, 2014 at 11:24:01AM -0700, Laszlo Danielisz via freebsd-pf wrote:
I was wondering how is possible to accept a connection, lets say on port 80
only if it comes from a specified referer.
Let's say there is a link on server A (IP 1.1.1.1) pointing to server B (IP
2.2.2.2). And
On Fri, Aug 16, 2013 at 04:16:34PM +0400, Alexander wrote:
Now my question is, is there any solution to stop PF block syn-ack
packets that don't have wscale option in a connection where syn
packet has it (in my case wscale proposed by windows 7 host is 8)
The missing wscale on the SYN-ACK is
On Fri, Aug 16, 2013 at 06:22:43PM +0400, Alexander wrote:
My connection with server (port ) starts to work and i think i
can be satisfied by this solution. But i still cannot understand why
packets are dropped without no state rules. As i revealed they are
dropped between bridge0 and
On Tue, Nov 20, 2012 at 01:52:43PM +0330, Hooma Fazaeli wrote:
If we could connect both ADSl modems to the box, a config like below
would work:
lan_if = em0
wan_if1 = em1
wan_if2 = em2
nat on $wan_if1 from $lan_if1:network to any - $wan_if1
nat on $wan_if2 from $lan_if1:network to any
On Mon, Aug 20, 2012 at 12:23:15PM -0400, J David wrote:
Anything based on the source address is ineffective as the number of
attack packets from any given IP is very low (frequently 1 if they are
forged).
Why not use synproxy state?
The goal for us is to clamp down on attacks directed at a
On Tue, Jul 24, 2012 at 08:41:54AM -0600, Jason Mattax wrote:
The other thing I did was I accessed the wikipedia server at
208.80.154.225 on the firewall. I did this so that I could do the nc
command on the firewall, the output of the tcpdump of which is attached
as xl0_tcpdump_nc and
On Mon, Jul 23, 2012 at 11:37:27AM +0200, Tonix (Antonio Nati) wrote:
What it is not clear to me is related to in/out rules evaluation.
Diagram starts obviously from the packet entering the system, until the
packet exits the system. When the packet enters the system, which rules
are
On Mon, Jul 23, 2012 at 01:32:07PM +0200, Tonix (Antonio Nati) wrote:
I have customers which should be allowed to go whetever they like and
accept from all.
So I'd love to make something like this:
- deny on INPUT WAN from hackers/abusers
- allow any other INPUT on WAN
- allow any
On Sat, Jul 21, 2012 at 05:22:07PM +0200, Tonix (Antonio Nati) wrote:
If you can provide a link to this PF diagram it would be very useful.
A copy is preserved on http://www.benzedrine.cx/pf_flow.png
Yes, there are two phases.
HTH,
Daniel
___
On Mon, Jul 09, 2012 at 06:31:55PM -0700, Hao Bryan Cheng wrote:
Is there a rule in pf that behaves similarly to ipfw's fwd rule? I have
heard mentions of a divert-to rule, but I was unsuccessful in finding any
official documentation on the subject anywhere online.
No, there's no generic rule
On Fri, Jun 01, 2012 at 10:25:39AM +0200, Joerg Pulz wrote:
panic: pf_test: 1: m-m_pkthdr.len 176, m-m_len 0
pf_test() at pf_test+0x259
pf_check_out() at pf_check_out+0x71
pfil_run_hooks() at pfil_run_hooks+0x113
ip_output() at ip_output+0x6de
ip_forward() at ip_forward+0x19e
ip_input() at
I think I found what might happen in your case. When reading the
ipfilter hook previously, I thought that it would return quickly due to
fr_running not being enabled, but it's not an 'enabled' flag as set
manually with pfctl -e!
If you compile in ipfilter (as your kernel config does), it will run
The following reply was made to PR kern/168190; it has been noted by GNATS.
From: Daniel Hartmeier dan...@benzedrine.cx
To: Joerg Pulz joerg.p...@frm2.tum.de
Cc: bug-follo...@freebsd.org, freebsd-pf@freebsd.org
Subject: Re: kern/168190: [pf] panic when using pf and route-to (maybe: bad
fragment
Here's a patch that directly tests this theory.
If correct, it will replace the panics with simple log messages that
show when ipfilter left an m_len==0 mbuf.
Daniel
Index: sys/contrib/ipfilter/netinet/ip_fil_freebsd.c
===
RCS
The following reply was made to PR kern/168190; it has been noted by GNATS.
From: Daniel Hartmeier dan...@benzedrine.cx
To: Joerg Pulz joerg.p...@frm2.tum.de
Cc: bug-follo...@freebsd.org, freebsd-pf@freebsd.org
Subject: Re: kern/168190: [pf] panic when using pf and route-to (maybe: bad
fragment
On Sun, May 27, 2012 at 06:30:09PM +, Joerg Pulz wrote:
i've seen 12 more pf_route: m0-m_len sizeof(struct ip) messages since
the system is running after adding your patch, but no panic.
Is there another place in the code where i can add an additional check?
Yes, the following patch
On Wed, May 23, 2012 at 10:10:04PM +, Joerg Pulz wrote:
here is what i could get out.
I was unable to print *pfh and pfh-pfil_func, but i printed the other
two and *ph, maybe this helps.
That looks corrupted: ph_type = 92404512, ph_nhooks = -512 makes no
sense to me.
Can you go up
On Thu, May 24, 2012 at 09:10:04AM +, Joerg Pulz wrote:
panic: ipfw_check_hook:281 ASSERT_HOST_BYTE_ORDER 45056 176
ipfw_check_hook() at ipfw_check_hook+0x511
pfil_run_hooks() at pfil_run_hooks+0xf1
ip_output() at ip_output+0x6de
ip_forward() at ip_forward+0x19e
ip_input() at
On Wed, May 23, 2012 at 07:50:04PM +, Joerg Pulz wrote:
Let me know if you need more output.
Oh, we can identify the pfil hook by printing *pfh, pfh-pfil_func and
comparing the address to that of pf_check_out, fr_check_wrapper, and the
one for ipfw, right?
Daniel
On Tue, May 22, 2012 at 06:10:03AM +, Joerg Pulz wrote:
And i got another panic, this time without pf(4) involved at all.
Unfortunately dump in kdb is doing nothing but hang. :-(
Here is what was displayed on the screen:
panic: m_copym, offset size of mbuf chain
cpuid = 1
This (or something similar) was reported before:
help w/panic under heavy load - 5.4
http://www.mail-archive.com/freebsd-hackers@freebsd.org/msg52452.html
panic on ip_input, ip_len byte ordering problem?
http://lists.freebsd.org/pipermail/freebsd-net/2009-July/022473.html
But no
If you have the chance, please try the patch below.
It adds byte order checks all over the place, hoping for a panic closer
to the source of the problem.
Daniel
Index: sys/sys/mbuf.h
===
RCS file: /home/ncvs/src/sys/sys/mbuf.h,v
It looks like the byte order of ip_len is wrong, htons(334) = 19969,
triggering fragmentation (334 if_mtu, but 19969 if_mtu).
The reason is most likely the recursive pf_route() call:
m_copym() at m_copym+0x280
ip_fragment() at ip_fragment+0x1e5
pf_route() at pf_route+0x75c
pf_test() at
On Mon, May 21, 2012 at 02:20:04PM +, Joerg Pulz wrote:
ext_if=bge0
int_if=bge1
vpn_net=10.1.1.0/24
srv_net=172.16.1.0/24
gw_addr=172.16.1.254
scrub in all
pass out on $ext_if route-to ($int_if $gw_addr) from $vpn_net to any keep
state
pass out on $int_if route-to
But you're not referencing the tables in your rules!
From pf.conf(5)
persist The persist flag forces the kernel to keep the table even when
no rules refer to it. If the flag is not set, the kernel will
automatically remove the table when the last rule referring
On Fri, Jan 06, 2012 at 02:21:07PM +, Gerald McNulty wrote:
I don't understand how rerouting the the loopback address would solve this.
There are 2 steps here - first the TCP handshake needs to be completed and
then the kernel/pf needs to pass the packets to the correct socket. How is
On Fri, Jan 06, 2012 at 02:51:07AM +, Gerald McNulty wrote:
Is this something that requires further pf rules? Or something in the C
code?
I think you're describing
http://lists.freebsd.org/pipermail/freebsd-net/2011-March/028225.html
With pf, you could try to reroute the replies to the
On Sat, Sep 10, 2011 at 10:42:53AM -0300, Mario Lobo wrote:
Sep 10 10:27:16 lobos kernel: pf_map_addr: selected address 177.17.68.103
Sep 10 10:27:49 lobos last message repeated 83 times
Sep 10 10:28:59 lobos last message repeated 283 times
This looks as if you're not allowing the packet out
Why do you have a tun0 interface on the NAT box? That's a virtual tunnel
interface, not a physical interface.
I thought the client (!= the NAT box) is the VPN endpoint. Not all
encapsulation is done there, the NAT box is somehow involved in this?
Daniel
On Fri, Sep 09, 2011 at 04:46:15PM -0300, Mario Lobo wrote:
Any suggestions?
Unlike most commercial NAT devices, pf is not aware of payload in PPTP
packets, which means it only supports a single PPTP connection between
your single external home addresses and the constant public work address
On Thu, Sep 08, 2011 at 02:47:29PM +0200, Dag-Erling Sm??rgrav wrote:
According to the pf.conf(5) man page in FreeBSD 8.2, the address part of
but pf complains of a syntax error if I leave it out, so
pass in on $lan2 route-to ($ext2) from ($lan2:network)
doesn't work, while
pass in
On Tue, May 10, 2011 at 06:45:08PM +0200, Nicolas GRENECHE wrote:
Regarding tcpdump, packets seems to go through the interface. Why does
pf doesn't see them ?
The destination MAC addresses of the ethernet frames do not match the
firewall's.
By putting the interfaces into promiscuous mode, the
I read those graphs differently: the problem doesn't arise slowly,
but rather seems to start suddenly at 13:00.
Right after 13:00, traffic on em0 drops, i.e. the firewall seems
to stop forwarding packets completely.
Yet, at the same time, the states start to increase, almost linearly
at about
On Mon, May 02, 2011 at 06:58:54PM -0700, Jeremy Chadwick wrote:
Status: Enabled for 76 days 06:49:10 Debug: Urgent
The pf uptime shown above, by the way, matches system uptime.
ps -axl
UID PID PPID CPU PRI NI VSZ RSS MWCHAN STAT TT TIME COMMAND
0 422 0
On Mon, May 02, 2011 at 06:58:54PM -0700, Jeremy Chadwick wrote:
Here's one piece of core.0.txt which makes no sense to me -- the rate
column. I have a very hard time believing that was the interrupt rate
of all the relevant devices at the time (way too high). Maybe this data
becomes wrong
On Tue, Apr 26, 2011 at 10:49:24AM +0300, Zeus V Panchenko wrote:
here we see outgoing via $if_wan traffic successfully coming through wan_http
queue, the rull 18
but no traffic comming trough the rull 24 but 10 instead ...
so, what am i missing, please?
why pflog row:
... rule
On Mon, Apr 11, 2011 at 06:22:30PM +0300, Zeus V Panchenko wrote:
first rull catches traffic from LAN to inet so, the sequence is:
LAN - if_lan - proxy server - if_wan - inet - some_web_server
and backward ...
some_web_server - if_wan - proxy server - if_lan - LAN
is it because
On Mon, Apr 11, 2011 at 08:45:44AM +0300, Zeus V Panchenko wrote:
what i am missing, please? why traffic outgoing to LAN is missed on pflog0?
It seems you want log(all), but are only using log, see pf.conf(5):
log Only the packet that establishes the state is logged
log (all)
On Mon, Apr 11, 2011 at 11:06:48AM +0300, Zeus V Panchenko wrote:
pass out log (all) on $if_wan inet proto { tcp, udp } from $if_wan:0 \
to any port { $ports_proxy } keep state queue wan_http
pass out log (all) on $if_lan inet proto { tcp, udp } from any port {
$ports_proxy } \
to
On Tue, Mar 29, 2011 at 01:16:32PM +0200, Leslie Jensen wrote:
I'm also running
tcpdump -s 256 -n -e - -i pflog0
But I cannot see any of the outgoing packets getting detected by pf and
sent to the proxy.
You have logging enabled on the rule explicitely passing the
redirected
On Wed, Mar 09, 2011 at 09:41:17AM +, Michael wrote:
I was thinking about something else, please correct me if I'm wrong. I'm
using two interfaces to get online on a regular basis, one is gsm and
another one is wifi.
I want to monitor both of them at any given time so I thought I need
On Tue, Feb 08, 2011 at 08:07:52PM -0500, Vadym Chepkov wrote:
No idea, why it didn't stop after 9 attempts.
The connection rate is not calculated precisely, from pf.conf(5)
max-src-conn-rate number / seconds
Limit the rate of new connections over a time interval. The con-
$
*/
+
+/*
+ * Copyright (c) 2001 Daniel Hartmeier
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ *
+ *- Redistributions of source code must retain the above copyright
On Fri, Jan 28, 2011 at 08:49:27AM +, andy thomas wrote:
and this works fine as I can access webmail on port 444. But why can't I
access the Sonicwall on port 444? Does anyone know if the Sonicwall uses
additional ports or has anyone got this device to with with a PF-based
firewall?
On Wed, Aug 04, 2010 at 08:45:42AM +0600, Rushan R. Shaymardanov wrote:
When there is, for example some idle ssh connection, pf stops tracking
it in its states table after some period of inactivity (I don't see it
in pfctl -ss). So, packets are blocked my default block rule and my
connection
On Wed, Aug 04, 2010 at 01:39:01PM +0600, Rushan R. Shaymardanov wrote:
I think, here's the problem. This connection - is that I using for
executing pfctl -ss, so expires in must be about 24 hrs like in your
example. But as you can see, the value is 4:13 here. When I execute
command again, I
The connection is from 10.10.0.8 to 10.0.10.2:22, it comes in
on tun0, matching
pass log on tun0 inet proto tcp from 10.10.0.0/24 to 10.0.10.2 flags S/SA
keep
and then passes out on sk0, but there is no matching rule.
Since your default block rule
block drop in log all
only applies to
On Wed, Jul 28, 2010 at 07:59:20PM -0700, Justin wrote:
Confirmed - synproxy works great if the synproxy machine is the
default gateway for the end host. Sadly this means scalability (adding
multiple synproxy boxes) is not possible, nor is it possible to filter a
specific IP out of the
On Tue, Jul 27, 2010 at 07:24:56PM -0700, Justin wrote:
- tcpdumps showing the initial connect attempt (logs below were
furhter along the process);
external:
02:21:25.595977 IP (tos 0x0, ttl 118, id 10020, offset 0, flags [DF],
proto TCP
(6), length 52)
REMOTE_VIEWING_HOST.53782
On Wed, Jul 28, 2010 at 01:04:42PM -0700, Justin wrote:
Logged to files and dumped;
Outside:
19:58:09.571810 IP (tos 0x0, ttl 118, id 12726, offset 0, flags [DF],
proto TCP
(6), length 52)
REMOTE_CLIENT.56270 TARGET_HOST.80: Flags [S], cksum 0xb15f
(correct), se
q 3641874856, win
On Mon, Jul 26, 2010 at 05:26:21AM -0700, Justin wrote:
When using synproxy state - the connection never completes. If we change
synproxy to keep, everything works fine. Alternately, if the service in
question is running locally on the actual firewall itself, I'll see
state entries show up
On Sun, Jul 11, 2010 at 11:20:42PM -0700, Doug Hardie wrote:
I am trying to understand what pf is trying to tell me. Its generating those
messages for a reason. The volume of them depends on how many rules have log
in them and how often they are invoked.
Some explanations can be found
On Wed, Feb 27, 2008 at 11:02:08PM -0500, Vadym Chepkov wrote:
My question is, why the reply packet was blocked?
It seems you're misunderstanding what 'floating state' means.
It does NOT mean allow connection on all interfaces.
If a connection traverses two interfaces, you need to allow it on
On Tue, Nov 20, 2007 at 10:50:41AM +0100, Jan Srzednicki wrote:
And the state becomes:
self tcp MY_IP_HERE:12525 - MY_IP_HERE:64829 ESTABLISHED:FIN_WAIT_2
[390096685 + 66608] wscale 1 [3173294128 + 66608] wscale 1
age 00:00:04, expires in 00:00:05, 4:3 pkts, 441:168 bytes, rule
On Mon, Nov 19, 2007 at 09:21:42PM +0100, Jan Srzednicki wrote:
I'm positively sure it's precisely this value that timeouts this
conection (which later on get state mismatches).
What does pfctl -vvss show for such a state entry, in particular the
right-most part of the first line
On Fri, Nov 16, 2007 at 04:30:17PM +0200, N. Ersen SISECI wrote:
I wrote some scripts for adding or removing rules to the current ruleset.
If there is a syntax error or something is wrong in new rule set, pf
will not load rules and default rule
will effect the new connections. Default pass
On Mon, Nov 12, 2007 at 10:45:57AM +0200, Jeremy wrote:
is it possible to describe queue all hosts on network.
No.
Daniel
___
freebsd-pf@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-pf
To unsubscribe, send any mail to
On Wed, Oct 24, 2007 at 01:50:55PM +0800, Nex Mon wrote:
hello, is there a way to disable implicit creation of states for NAT, BINAT
and RDR rules? the man page of pf.conf says this:
Note: nat, binat and rdr rules implicitly create state for connections.
Yes, translations require states.
On Thu, Sep 27, 2007 at 01:24:45PM -0300, David Verzolla wrote:
Its possible creates a rule that can match all the traffic designated to an
specific interface?
Example:
pass in on $vlan10 from vlan10 to (the interface, not the address) $ext_if
The $ext_if:network doesn't works for me.
On Wed, Aug 01, 2007 at 05:42:19PM +0200, Patrick Proniewski wrote:
While playing around with systat I've discovered that the transfer
rate can be as low as 20 KB/s and as high as 850 KB/s on a single
download from http://test-debit.free.fr, but the mean value will
always be around
On Wed, Feb 07, 2007 at 10:24:57AM -0500, Kevin K. wrote:
I was hoping that the issue was simple and common, due to Vista's emphasis
on ipv6 among other networking issues. Either way, below is my entire pf
configuration. I hope it helps.
I'm afraid you'll have to do the usual debug routine:
On Sat, Dec 16, 2006 at 02:54:23PM +0100, Martijn Broeders - HUB Labs wrote:
self tcp 192.168.0.2:80 - 217.194.110.35:80 - 213.84.86.15:35452
PROXY:DST
Can someone tell me what is means? And why does the redirection fail to
the internal webserver?
Most likely that 192.168.0.2's default
On Sat, Nov 11, 2006 at 11:04:25PM +, Kimi Ostro wrote:
All of those messages State failure on: messages are like this:
Nov 10 15:40:24 ehost kernel: pf: State failure on: |
which doesn't help I guess?
more here:
Nov 10 15:40:24 ehost kernel: pf: BAD state: TCP
The diff, in case you want to apply it manually, is
http://www.openbsd.org/cgi-bin/cvsweb/src/sys/net/pf.c.diff?r1=1.514r2=1.515f=h
Subject: CVS: cvs.openbsd.org: src
From: Markus Friedl [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Date: Mon, 18 Sep 2006 03:53:05 -0600 (MDT)
CVSROOT:/cvs
On Mon, Oct 23, 2006 at 06:49:35PM -0200, Aristeu Gil Alves Jr wrote:
he reply-to is not working when it is used with synproxy.
Yes, that's a known problem. Packets generated by pf itself (synproxy,
return-rst, etc.) don't honour route-to or reply-to options.
It's on some to-do list, but
On Thu, Oct 05, 2006 at 12:08:27PM -0400, Adam McDougall wrote:
(44.18 is the squid server (trident), 37.163 is the system running portsnap
(ice))
Oct 5 11:22:03 jolly-fw1 kernel: pf: BAD state: TCP 35.9.44.18:3128
35.9.44.18:3128 35.9.37.163:55357
[lo=646710754 high=646777361
On Fri, Sep 29, 2006 at 01:00:30AM +0200, Rolf Grossmann wrote:
I've been suspecting that the test is flawed, but I couldn't put my
finger on it. However, I also need a way to actually test my
application with a lot of requests and I wouldn't want to buy another
server farm for that ;)
On Thu, Sep 28, 2006 at 11:30:48PM +0200, Rolf Grossmann wrote:
Sep 28 23:56:56 balancer kernel: pf: BAD state: TCP 10.1.1.2:8080
10.25.0.41:8080 10.25.0.100:52209 [lo=2341692840 high=2341759447 win=33304
modulator=0 wscale=1] [lo=2919421554 high=2919488162 win=33304 modulator=0
wscale=1]
On Mon, Aug 21, 2006 at 10:47:17AM -0400, beno wrote:
Apparently, it doesn't like *one* my nested macros in line #16 (it likes
all the others) and it doesn't like the CIDR netmask in line 22. Someone
suggested I research the archives concerning the latter where this
known problem was
Can you give us an example of just one connection that doesn't work?
Like, local workstation i.i.10.3, connected to em1, matching $inwr,
tries to connect to an external host 62.65.145.30. Protocol TCP, source
port 12345, destination port 80. The TCP SYN is seen (with tcpdump)
incoming on em1. But
On Fri, Jul 21, 2006 at 02:05:45AM +0200, Max Laier wrote:
Which proxies are you using? The pool_ticket: 1429 != 1430 messages you
quote below indicate a synchronization problem within the app talking to pf
via ioctl's. Tickets are used to ensure atomic commits for operations that
On Sun, Jul 16, 2006 at 11:05:27PM +0200, Dag-Erling Smørgrav wrote:
Hence, a default block switch or compile time option _within_ pf is
not going to make any difference.
Sure it will, if pf is compiled into the kernel or loaded by the BTX
loader.
Ok, in that case I guess you want to
On Mon, Jul 17, 2006 at 01:36:01AM +0300, Giorgos Keramidas wrote:
I haven't verified that this is the _only_ change needed to make PF
block everything by default, but having it as a compile-time option
which defaults to block everything would be nice, right?
Sure, when FreeBSD's default
On Sat, Jul 08, 2006 at 02:18:12AM -0500, J. Buck Caldwell wrote:
Is it possible to track pf ALTQ usage with MRTG? I notice that FreeBSD's
built-in bsnmpd has a module and mibs to support pf, but I know too
little about SNMP to figure out how to access the queue stats.
Specifically, I'm
On Fri, Jun 30, 2006 at 11:06:02AM +0400, [EMAIL PROTECTED] wrote:
There is a problem in pf, when I try to add rules with keyword
self. Example:
self always translates to IP addresses at load-time. To re-translate,
you have to re-load the ruleset.
In rule addresses (but not tables) you can
On Tue, Jun 27, 2006 at 01:36:52PM +0300, N. Ersen SISECI wrote:
My first rule is pass in all with keep state. But the packets do not
seem to be able pass out from the other interface. If i change the last
block's to pass everything works fine. It seems that the state table
is always on
On Tue, Jun 27, 2006 at 04:58:04PM +0300, N. Ersen SISECI wrote:
For pf a solution we come up with:
pass in quick ... port 22 ... keep state tag XYZ
pass in quick keep state tag XYZ
pass in quick keep state tag XYZ
pass in quick keep state tag XYZ
pass in quick keep
On Fri, May 26, 2006 at 04:52:33PM +0200, Peter Ankerstål wrote:
I am using authpf for my wifi-network. But I want to redirect all of the
http-traffic to a webserver to show a error message when not
authenticated via authpf. But how to remove this rule when I
authenticate? As far as I know
On Mon, May 15, 2006 at 02:24:41PM +1200, Andrew Thompson wrote:
Looks good to me and it looks like its working for Adam. Did you want to
commit this Daniel?, ive made a few comments below.
Commited to HEAD including your changes.
Daniel
___
On Mon, May 08, 2006 at 11:49:30AM -0400, Adam McDougall wrote:
Could someone possibly produce a patch to force if_bridge to
recalculate the checksum on every packet so I can test that as well?
To me, the extra load on the firewall is less important than breaking
packets I am trying to pass.
On Thu, May 04, 2006 at 08:03:55PM +0400, Dmitry Andrianov wrote:
May 4 19:52:53 vrn1 kernel: pf: BAD state: TCP 10.2.0.2:3389
10.2.0.2:3389 192.168.10.100:1919 [lo=4162748520 high=4162681620
win=65535 modulator=0] [lo=0 high=65535 win=1 modulator=0] 2:0 PA
seq=4162748520 ack=0 len=632
The second bug is is userland pfctl, I suggest
Index: parse.y
===
RCS file: /cvs/src/sbin/pfctl/parse.y,v
retrieving revision 1.496
diff -u -r1.496 parse.y
--- parse.y 6 Apr 2006 21:54:56 - 1.496
+++ parse.y 28 Apr
On Wed, Apr 05, 2006 at 02:41:09PM +0200, Max Laier wrote:
The other big problem that just crossed my mind: Reassembly in the bridge
path!? It doesn't look like the current bridge code on either OS is ready to
deal with packets MTU coming out of the filter. The question here is
It begins to look like OpenBSD does fix IP checksums on bridges outside
of pf, while FreeBSD doesn't.
The weird thing is that I haven't found where exactly this happens. It's
kind of a layer violation for bridge code to do that, but maybe it's
somewhere else along the code path.
Instead of
Ok, I found the reason for all these IP checksum problems. The reason is
that OpenBSD's bridge code always recalculates the IP checksum, while
FreeBSD's doesn't.
In OpenBSD we have src/sys/net/if_bridge.c with the following code path.
bridgeintr_frame()
Main entry point on input path,
On Wed, Mar 22, 2006 at 04:03:16PM +0100, Volker wrote:
It smells like a memory leak isn't it?
If it were an mbuf leak, it wouldn't go away right after you run pfctl
-d, as disabling pf will not cause any memory to get released at all.
You might simply be hitting the (default) 10,000 state
On Wed, Feb 01, 2006 at 09:58:45AM -0600, Keith Bottner wrote:
I am having a problem getting packet filter to redirect incoming traffic
destined for a specific IP and port to an internal DMZ host. Interestingly
enough I am not having a problem doing the same with SSH just with these
On Mon, Jan 02, 2006 at 05:18:30PM +0100, TYBERGHIEN Eric TRANSPAC wrote:
Can you help me to solve this feature. Is it a bug, a mechanism of DOS
auto-protection or a mis-understood of the PF features ?
Look at the TCP RFC, sections Knowing When to Keep Quiet and The TCP
Quiet Time Concept
On Sat, Dec 31, 2005 at 12:50:57AM +0100, ?ukasz Bromirski wrote:
Is there by any chance work being done on pf to include functionality
that is present in FreeBSD ipfw, that checks if packet entered
router via correct interface as pointed out by routing table?
Not that I know of, no.
Daniel
Doh.
delta_tsval == 1424952994 - 1424712993 == 240001
delta_time == 120082719 us (120.082719 s)
freq == delta_tsval / delta_time
== 240001 / 120.082719
== 240001 * 100 / 120082719
== 1998 Hz ( 1000 Hz)
So it's not that far off, the server seems to increment timestamps at
On Tue, Nov 29, 2005 at 01:24:04AM -0500, Forrest Aldrich wrote:
Is it not valid to specify in a file based table:
11.22.33.0/24
using slash notation?
I looked at the PF page, and it seems ambiguious about whether this is
valid or not.
It's valid:
# cat file
1.2.3.4
On Tue, Nov 29, 2005 at 03:53:20AM -0500, Forrest Aldrich wrote:
Here is what I'm using for the tables:
block in quick on $ext_if proto { tcp, udp } from { table1, table2 } \
to $ext_if:network port 25
I wonder if this should be written differently.
I don't see anything obviously
On Tue, Nov 29, 2005 at 03:56:34AM -0500, Forrest Aldrich wrote:
In PF, I am trying to determine how to accomplish similiarly. The command:
pf -vvs Tables
Provides summaries only. I don't see a way to accomplish the above.
Additional per-table counters can be printed with
pfctl -t
On Tue, Nov 29, 2005 at 06:39:54PM -0500, Forrest Aldrich wrote:
On FreeBSD-6-STABLE if I use:
tcp_services = imap imaps http https
rdr pass on $ext_if inet proto tcp from any to $ext_ad \
port { $tcp_services } - $server
it fails.
I can't confirm that, it works for me (substituting
On Tue, Nov 29, 2005 at 06:48:37PM -0500, Forrest Aldrich wrote:
Yes, it was the only variable that I changed. Once I added the commas,
it works like a charm.
But see my previous post - maybe there's a connection. Where I can't
get to my public address via the private net (I have my
Can you reproduce the problem (create one connection), then run
pfctl -vsn (entire output) and pfctl -vss (the state using the wrong
source address)?
The connection might match the wrong nat rule (unlike filter rules,
translation rules are first-match).
Or the connection might not be nat'ed at
1 - 100 of 119 matches
Mail list logo
