Here is some more info: The request gets to the web server but when webserver is responding back to the client's request, PF BLOCKS the request:

Here is tcpdump view from webserver:

20:44:47.539217 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto 6, length: 48) 172.16.10.11.80 > 75.18.177.36.1120: S [tcp sum ok] 802414809:802414809(0) ack 740304551 win 5840 <mss 1460,nop,nop,sackOK> 20:44:51.738331 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto 6, length: 48) 172.16.10.11.80 > 75.18.177.36.1120: S [tcp sum ok] 802414809:802414809(0) ack 740304551 win 5840 <mss 1460,nop,nop,sackOK> 20:44:57.737882 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto 6, length: 48) 172.16.10.11.80 > 75.18.177.36.1120: S [tcp sum ok] 802414809:802414809(0) ack 740304551 win 5840 <mss 1460,nop,nop,sackOK> 20:45:09.935925 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto 6, length: 48) 172.16.10.11.80 > 75.18.177.36.1120: S [tcp sum ok] 802414809:802414809(0) ack 740304551 win 5840 <mss 1460,nop,nop,sackOK> 20:45:33.932113 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto 6, length: 48) 172.16.10.11.80 > 75.18.177.36.1120: S [tcp sum ok] 802414809:802414809(0) ack 740304551 win 5840 <mss 1460,nop,nop,sackOK> 20:46:22.124476 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto 6, length: 48) 172.16.10.11.80 > 75.18.177.36.1120: S [tcp sum ok] 802414809:802414809(0) ack 740304551 win 5840 <mss 1460,nop,nop,sackOK> 20:46:22.125818 IP (tos 0x10, ttl 64, id 35465, offset 0, flags [DF], proto 6, length: 40) 75.18.177.36.1120 > 172.16.10.11.80: R [tcp sum ok] 1:1(0) ack 1 win 0


Here is PF blocking the same:

# tcpdump -n -e -ttt -i pflog0
tcpdump: listening on pflog0, link-type PFLOG
Sep 22 22:16:18.905238 rule 0/(match) block in on fxp0: 172.16.10.11.80 > 75.18.177.36.1120: [|tcp] (DF) Sep 22 22:17:07.101648 rule 0/(match) block in on fxp0: 172.16.10.11.80 > 75.18.177.36.1120: [|tcp] (DF)


Why is PF blocking???????

HELPPPPPPPP!!!



On Sep 22, 2008, at 11:40 AM, Jason Dixon wrote:

On Mon, Sep 22, 2008 at 11:16:53AM -0700, Parvinder Bhasin wrote:
On Sep 22, 2008, at 7:30 AM, Jason Dixon wrote:

On Mon, Sep 22, 2008 at 07:20:50AM -0700, Parvinder Bhasin wrote:
On Sep 22, 2008, at 6:10 AM, Jason Dixon wrote:

On Mon, Sep 22, 2008 at 05:23:31AM -0700, Parvinder Bhasin wrote:

On Sep 22, 2008, at 4:46 AM, Jason Dixon wrote:

On Mon, Sep 22, 2008 at 02:25:01AM -0700, Parvinder Bhasin wrote:
On Sep 22, 2008, at 1:14 AM, Stuart Henderson wrote:

On 2008-09-22, Parvinder Bhasin <[EMAIL PROTECTED]>
wrote:
I have users that can access the website fine
(75.44.229.18) and
some
user that complain they can't access it.

Include the dmesg so we can see what OS version you're running.
Set pfctl -x misc and watch /var/log/messages, include any
output
from around the time of a failed connection. Include the
relevant
state table entries from pfctl -vss.

Here is the output from pfctl -vss - with the host(75.18.177.36)
trying
to access the website:

Please do that again, but grep only the relevant bits.  I'm not
going
to
sift through all the noise.

$ sudo pfctl -ss | grep 75.18.177.36

I'm pretty sure your outbound nat needs to be moved *after* your
rdr's.
I think the inbound traffic is having the src_addr translated to
your
firewall's ($ext_if)

Jason,

Here it is without the noise.

# pfctl -ss | grep 75.18.177.36
all tcp 172.16.10.11:80 <- 75.44.229.18:80 <- 75.18.177.36:1056
SYN_SENT:ESTABLISHED
all tcp 75.18.177.36:1056 -> 172.16.10.11:80
ESTABLISHED:SYN_SENT
# pfctl -ss | grep 75.18.177.36
all tcp 172.16.10.11:80 <- 75.44.229.18:80 <- 75.18.177.36:1056
SYN_SENT:ESTABLISHED
all tcp 75.18.177.36:1056 -> 172.16.10.11:80
ESTABLISHED:SYN_SENT

Looks ok.  Let's see the output of `pfctl -sr` and `pfctl -sn`.
Also,
let's correlate your states to the logged blocks.  In separate
terminals, do the `pfctl -ss | grep <foo>` and then find the
corresponding traffic in pflog0 that's being blocked.  Let's see
them
both.


# pfctl -sr
scrub in all fragment reassemble
block return in log (all) all
pass out all flags S/SA keep state
block drop in quick on ! lo inet from 127.0.0.0/8 to any
block drop in quick on ! lo inet6 from ::1 to any
block drop in quick inet from 127.0.0.1 to any
block drop in quick on ! fxp0 inet from 172.16.10.0/24 to any
block drop in quick inet from 172.16.10.10 to any
block drop in quick inet6 from ::1 to any
block drop in quick on lo0 inet6 from fe80::1 to any
block drop in quick on fxp0 inet6 from fe80::206:29ff:fecf:7d5f to
any
pass in on fxp1 inet proto tcp from any to 172.16.10.11 port = www
flags
S/SA keep state
pass in on fxp1 inet proto tcp from any to 75.44.229.17 port = ssh
flags
S/SA keep state
pass in on fxp1 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 echoreq keep state
pass in quick on fxp0 all flags S/SA keep state
# pfctl -sn
nat on fxp1 from ! (fxp1) to any -> (fxp1:0)
nat-anchor "ftp-proxy/*" all
rdr-anchor "ftp-proxy/*" all
rdr on fxp1 inet proto tcp from any to 75.44.229.18 port = www ->
172.16.10.11 port 80
rdr on fxp1 inet proto tcp from any to 75.44.229.19 port = 3128 ->
172.16.10.12 port 3128


# pfctl -ss | grep 75.18.177.36
all tcp 172.16.10.11:80 <- 75.44.229.18:80 <- 75.18.177.36:1057
SYN_SENT:ESTABLISHED
all tcp 75.18.177.36:1057 -> 172.16.10.11:80
ESTABLISHED:SYN_SENT

And the blocked packets?


How should I capture them?  did you mean via pflog?

Yes, just like you did before.  I'd like to see where they're being
passed (pfctl -ss) *and* blocked (pflog) at the same time.

--
Jason Dixon
DixonGroup Consulting
http://www.dixongroup.net/

Reply via email to