On Saturday 09 September 2006 19:06, Stuart Henderson wrote:
So,
- the only difference in pf.conf between working and not-working
is that working uses addresses directly in the rules, and not-working
uses tables;
- your tables did load correctly and show the addresses with -Ts
Lists all
On 2006/09/10 09:08, steve szmidt wrote:
Maybe it would help to post pfctl -sr -vv with the direct entry
(i.e. working) and table (i.e. not-working). Perhaps pfctl -sT -v
too.
Since pflog0 tells me which rule was used I only include that rule. The first
one is working and 2nd not.
On Sunday 10 September 2006 10:32, Stuart Henderson wrote:
On 2006/09/10 09:08, steve szmidt wrote:
Maybe it would help to post pfctl -sr -vv with the direct entry
(i.e. working) and table (i.e. not-working). Perhaps pfctl -sT -v
too.
Since pflog0 tells me which rule was used I only
On 2006/09/10 10:54, steve szmidt wrote:
Since pflog0 tells me which rule was used I only include that rule. The
first one is working and 2nd not.
pass out log on $WAN proto tcp from any to any port $Web keep state
oh, I thought you were putting the addresses in there (instead of
On Sunday 10 September 2006 11:15, Stuart Henderson wrote:
I was until I finally got it that the rules are looking at IP's after -
not before, NAT. :)
well, same applies when you use tables :)
Yes, that's what was going on, but it took a while for me to get it.
If you prefer simpler
Hi,
I'm stuck on some obvious pf table error but I can't see it.
I got a small test subnet 192.168.0.0 under my own subnet 10.1.0.0, where I
test this firewall.
Internet--[firewall]--10.1.0.0--[this test firewall]--192.168.0.0
Queues are not active yet, nor are web or ftp servers.
I added a
I'm stuck on some obvious pf table error but I can't see it.
snip
## Tables (File content shown in brackets)
table admins file /etc/tAdmins ( 192.168.0.3 )
table managers file /etc/tManagers (192.168.0.2)
table operators file /etc/tOperators (192.168.0.128)
table http-managers file
On Saturday 09 September 2006 15:21, you wrote:
I would only filter traffic on ONE interface, as is often recommended
in applicable documentation -- e.g. just filter traffic on your $WAN
interface. It's very hard to get things right when filtering on two
interfaces.
Agreed. Oops, the pass in
On Saturday 09 September 2006 15:21, Steve Welham wrote:
I'm stuck on some obvious pf table error but I can't see it.
snip
## Tables (File content shown in brackets)
table admins file /etc/tAdmins ( 192.168.0.3 )
table managers file /etc/tManagers (192.168.0.2)
table operators
On 2006/09/09 16:40, steve szmidt wrote:
I also added proper data to all table files to ensure it does not mess things
up. Though the persist command should allow for empty files.
Do your tables actually load? Check pfctl -t tablename -Ts.
If not, does pfctl -vvt tablename -Tr -f /path/to/file
On Saturday 09 September 2006 17:59, Stuart Henderson wrote:
On 2006/09/09 16:40, steve szmidt wrote:
I also added proper data to all table files to ensure it does not mess
things up. Though the persist command should allow for empty files.
Do your tables actually load? Check pfctl -t
On 2006/09/09 18:04, steve szmidt wrote:
On Saturday 09 September 2006 17:59, Stuart Henderson wrote:
On 2006/09/09 16:40, steve szmidt wrote:
I also added proper data to all table files to ensure it does not mess
things up. Though the persist command should allow for empty files.
Do
12 matches
Mail list logo
