I have done this already for the sake of troubleshooting. I have
tried removing BLOCKs , I have tried removing anti-spoof ,
I have tried re-writing the redirector by putting "pass" but for some
reason PF doesn't seem to like packets coming from some DSL links. I
have also tried various scrubbing rules. But no luck there either.
To add to this confusion, when I spin off a PIX firewall. Everything
(all the connection) can connect to the web servers.
I don't know about this but do I file a bug report??? I know probably
I will get flamed but I have tried everything here though I still
haven't given up on this. I would appreciate if someone who has
worked on PF's code can help with this. I know they may not have
time .. but I would appreciate some feedback. I can provide all the
troubleshooting steps and infact give access to systems (remote) if
needed with all the wonderful sniffing tools etc.
-Parvinder Bhasin
On Sep 23, 2008, at 12:06 AM, John Jackson wrote:
Comments are inline.
On Sun, Sep 21, 2008 at 10:00:58PM -0700, Parvinder Bhasin wrote:
I have users that can access the website fine (75.44.229.18) and some
user that complain they can't access it. I don't know what gives. I
have asked on the list for help but haven't still resolved this. I
would really appreciate any help. Why is the user in the below pflog
getting blocked. Where as most of the user can access the website
just fine. I have spent countless hours on this. I really don't
want
a PIX firewall. When I switch to the pix the access seems fine.
tcpdump: listening on pflog0, link-type PFLOG
Sep 21 21:53:21.903554 rule 0/(match) block in on fxp0:
172.16.10.11.80 > 75.18.177.36.1106: [|tcp] (DF)
Sep 21 21:53:34.570469 rule 0/(match) block in on fxp1:
75.18.177.36.1105 > 172.16.10.11.80: [|tcp] (DF)
Here is my pf.conf file:
##### MACROS ####
ext_if="fxp1"
int_if="fxp0"
pf_log="pflog0"
icmp_types="echoreq"
#### OPTIONS #####
set loginterface $ext_if
set loginterface $int_if
set block-policy return
set skip on lo
# scrub
scrub in
What are you trying to accomplish with the following? I assume
NAT'ing outbound traffic from internal networks? If so try creating a
macro for your internal networks and explicitly NAT that.
nat on $ext_if from !($ext_if) -> ($ext_if:0)
Try this (put the table statement in the appropriate place with your
internal networks):
table <internal_nets> persist { 10.0.0.0/24, 172.16.0.0/24 }
nat on $ext_if from <internal_nets> to any -> ($ext_if:0)
nat-anchor "ftp-proxy/*"
rdr-anchor "ftp-proxy/*"
You may gain some clarity by placing a 'pass' in your rdr instead of
a seperate pass rule down lower:
rdr pass on $ext_if inet proto tcp from any to 75.44.229.18 port 80
-> 172.16.10.11 port 80
rdr on $ext_if proto tcp from any to 75.44.229.18 port 80 ->
172.16.10.11 port 80
rdr on $ext_if proto tcp from any to 75.44.229.19 port 3128 ->
172.16.10.12 port 3128
# filter
block in log (all, to pflog0)
pass out keep state
For the sake of troubleshooting try removing the $int_if in the
antispoof statement:
antispoof quick for { lo $int_if }
pass in on $ext_if inet proto tcp from any to 172.16.10.11 port 80
flags S/SA keep state
pass in on $ext_if inet proto tcp from any to 75.44.229.17 port 22
flags S/SA keep state
pass in on $ext_if inet proto tcp from any to 172.16.10.12 port 3128
flags S/SA synproxy state
pass in inet proto icmp all icmp-type $icmp_types keep state
pass in quick on $int_if
I'd try simplifying as much as possible while troubleshooting, like
commenting out the default 'block' rule and see if the 'antispoof' is
tripping you up and vice versa.
