Re: Need Help badly - PF related
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.
Re: Need Help badly - PF related
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.
Re: Need Help badly - PF related
Thanks a lot guys, I seem to have resolved the problem. So in short
it seems like the netopia 30xx series router was doing some funky
thing with packets which PF was rightfully rejecting (as they were not
normalized). This is just my theory. Once I converted my openbsd box
to the router and the netopia box to a dumb bridge. It all worked
like a charm.
Appreciate the group's help on this.
I would like to personaly thank you guys in taking time to
troubleshoot this with me.
Thanks: John Jackson , Stuart henderson, Bryan , Mark and above all
Jason Dixon.
-Parvinder Bhasin
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.
Why is the user in the below pflog
getting blocked. Where as most of the user can access the website
just 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
nat on $ext_if from !($ext_if) - ($ext_if:0)
nat-anchor ftp-proxy/*
rdr-anchor ftp-proxy/*
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
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
If this is a newer OS version, flags S/SA and keep state are
redundant.
If it's an old one, your pass in quick on $int_if should also use
them.
Re: Need Help badly - PF related
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.
Why is the user in the below pflog
getting blocked. Where as most of the user can access the website
just 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
nat on $ext_if from !($ext_if) - ($ext_if:0)
nat-anchor ftp-proxy/*
rdr-anchor ftp-proxy/*
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
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
If this is a newer OS version, flags S/SA and keep state are redundant.
If it's an old one, your pass in quick on $int_if should also use them.
Re: Need Help badly - PF related
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
nat on $ext_if from !($ext_if) - ($ext_if:0)
nat-anchor ftp-proxy/*
rdr-anchor ftp-proxy/*
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
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
Show the output of `pfctl -sr` and `pfctl -sn`. Also, capture the
states of this client when this is happening:
$ sudo pfctl -ss | grep 75.18.177.36
--
Jason Dixon
DixonGroup Consulting
http://www.dixongroup.net/
Re: Need Help badly - PF related
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. Stuart/Jason: The OS version is 4.3. I did pfctl -x misc and I don't see any messages appearing related to the bad connection from that IP. I logged on remotely on one of the system and tried accessing the site but nothing showed up in /var/ log/messages. Here is the output : # pfctl -x misc debug level set to 'misc' # tail -f /var/log/messages Sep 19 07:02:34 firetalk ntpd[18456]: bad peer from pool pool.ntp.org (209.132.176.4) Sep 19 07:02:34 firetalk ntpd[18456]: bad peer from pool pool.ntp.org (208.53.158.34) Sep 20 02:00:01 firetalk syslogd: restart Sep 20 04:00:02 firetalk syslogd: restart Sep 20 14:00:02 firetalk syslogd: restart Sep 21 02:00:01 firetalk syslogd: restart Sep 21 20:43:56 firetalk ntpd[18456]: 3 out of 5 peers valid Sep 21 20:43:56 firetalk ntpd[18456]: bad peer from pool pool.ntp.org (209.132.176.4) Sep 21 20:43:56 firetalk ntpd[18456]: bad peer from pool pool.ntp.org (208.53.158.34) Sep 22 02:00:01 firetalk syslogd: restart Here is the output from pfctl -vss - with the host(75.18.177.36) trying to access the website: # pfctl -vss all udp 204.152.186.173:123 - 172.16.10.12:19727 MULTIPLE:MULTIPLE age 12:04:07, expires in 00:00:31, 1364:1364 pkts, 103664:103664 bytes all udp 172.16.10.12:19727 - 75.44.229.17:60314 - 204.152.186.173:123 MULTIPLE:MULTIPLE age 12:04:07, expires in 00:00:31, 1364:1364 pkts, 103664:103664 bytes all udp 82.165.177.157:123 - 172.16.10.12:44282 MULTIPLE:MULTIPLE age 10:04:30, expires in 00:00:57, 1138:1138 pkts, 86488:86488 bytes all udp 172.16.10.12:44282 - 75.44.229.17:56413 - 82.165.177.157:123 MULTIPLE:MULTIPLE age 10:04:30, expires in 00:00:57, 1138:1138 pkts, 86488:86488 bytes all udp 207.192.69.197:123 - 172.16.10.12:42096 MULTIPLE:MULTIPLE age 03:06:08, expires in 00:00:47, 355:355 pkts, 26980:26980 bytes, rule 14 all udp 172.16.10.12:42096 - 75.44.229.17:60864 - 207.192.69.197:123 MULTIPLE:MULTIPLE age 03:06:08, expires in 00:00:47, 355:355 pkts, 26980:26980 bytes, rule 1 all tcp 75.44.229.17:22 - 76.202.196.187:59799 ESTABLISHED:ESTABLISHED [654074524 + 524232] wscale 0 [3656802774 + 16952] wscale 3 age 00:07:21, expires in 24:00:00, 490:427 pkts, 35301:77260 bytes, rule 11 all tcp 216.39.62.89:25 - 172.16.10.12:29315 CLOSED:SYN_SENT [0 + 16384] [4185608820 + 1] age 00:00:33, expires in 00:00:15, 3:0 pkts, 192:0 bytes, rule 14 all tcp 172.16.10.12:29315 - 75.44.229.17:61775 - 216.39.62.89:25 SYN_SENT:CLOSED [4185608820 + 1] [0 + 16384] age 00:00:33, expires in 00:00:15, 3:0 pkts, 192:0 bytes, rule 1 all udp 75.44.229.17:21902 - 66.250.45.2:123 MULTIPLE:SINGLE age 00:00:22, expires in 00:00:09, 1:1 pkts, 76:76 bytes, rule 1 # pfctl -vss | grep 75.18.177.36 # pfctl -vss all udp 204.152.186.173:123 - 172.16.10.12:19727 MULTIPLE:MULTIPLE age 12:06:24, expires in 00:00:47, 1369:1369 pkts, 104044:104044 bytes all udp 172.16.10.12:19727 - 75.44.229.17:60314 - 204.152.186.173:123 MULTIPLE:MULTIPLE age 12:06:24, expires in 00:00:47, 1369:1369 pkts, 104044:104044 bytes all udp 82.165.177.157:123 - 172.16.10.12:44282 MULTIPLE:MULTIPLE age 10:06:47, expires in 00:00:50, 1142:1142 pkts, 86792:86792 bytes all udp 172.16.10.12:44282 - 75.44.229.17:56413 - 82.165.177.157:123 MULTIPLE:MULTIPLE age 10:06:47, expires in 00:00:50, 1142:1142 pkts, 86792:86792 bytes all udp 207.192.69.197:123 - 172.16.10.12:42096 MULTIPLE:MULTIPLE age 03:08:25, expires in 00:00:38, 359:359 pkts, 27284:27284 bytes, rule 14 all udp 172.16.10.12:42096 - 75.44.229.17:60864 - 207.192.69.197:123 MULTIPLE:MULTIPLE age 03:08:25, expires in 00:00:38, 359:359 pkts, 27284:27284 bytes, rule 1 all tcp 75.44.229.17:22 - 76.202.196.187:59799 ESTABLISHED:ESTABLISHED [654079468 + 524232] wscale 0 [3656804886 + 16952] wscale 3 age 00:09:38, expires in 24:00:00, 603:497 pkts, 43349:85892 bytes, rule 11 all tcp 172.16.10.11:80 - 75.44.229.18:80 - 75.18.177.36:1125 SYN_SENT:ESTABLISHED [2398465402 + 65535] [930424393 + 5840] age 00:00:11, expires in 00:00:30, 3:5 pkts, 144:240 bytes, rule 10 all tcp 75.18.177.36:1125 - 172.16.10.11:80 ESTABLISHED:SYN_SENT [930424393 + 5840] [2398465402 + 65535] age 00:00:11, expires in 00:00:30, 3:5 pkts, 144:240 bytes, rule 1 # pfctl -vss all udp 204.152.186.173:123 - 172.16.10.12:19727 MULTIPLE:MULTIPLE age 12:06:31, expires in 00:00:40,
Re: Need Help badly - PF related
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 Dixon DixonGroup Consulting http://www.dixongroup.net/
Re: Need Help badly - PF related
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 # -Parvinder Bhasin -- Jason Dixon DixonGroup Consulting http://www.dixongroup.net/
Re: Need Help badly - PF related
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. -- Jason Dixon DixonGroup Consulting http://www.dixongroup.net/
Re: Need Help badly - PF related
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 -- Jason Dixon DixonGroup Consulting http://www.dixongroup.net/
Re: Need Help badly - PF related
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? -- Jason Dixon DixonGroup Consulting http://www.dixongroup.net/
Re: Need Help badly - PF related
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? Thanks Parvinder bhasin -- Jason Dixon DixonGroup Consulting http://www.dixongroup.net/
Re: Need Help badly - PF related
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/
Re: Need Help badly - PF related
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, Here are the blocked packets and pfctl -ss , pfctl -sn , pfctl -sr dump. # tcpdump -n -e -ttt -i pflog0 tcpdump: listening on pflog0, link-type PFLOG Sep 22 11:57:34.445702 rule 0/(match) block in on fxp1: 222.134.38.214.80 75.44.229.17.64783: [|tcp] Sep 22 11:57:38.496743 rule 0/(match) block in on fxp1: 222.134.38.214.80 75.44.229.17.64783: [|tcp] Sep 22 11:58:59.557561 rule 0/(match) block in on fxp0: 172.16.10.11.80 75.18.177.36.1058: [|tcp] (DF) # 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 -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
Re: Need Help badly - PF related
Any word Jason/Stuart? I am stuck at this. I have had sniffers all over the pace to see what was wrong that PF was NOT liking this connection but Nothing turned up. -Parvinder Bhasin 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/
Re: Need Help badly - PF related
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??? HEL!!! 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)
Need Help badly - PF related
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
nat on $ext_if from !($ext_if) - ($ext_if:0)
nat-anchor ftp-proxy/*
rdr-anchor ftp-proxy/*
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
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
