Re: Ipf problem
On Fri, Jan 06, 2006 at 04:05:14PM +0200, Giorgos Keramidas wrote: > On 2006-01-06 00:17, Jacob S <[EMAIL PROTECTED]> wrote: > > Hello list, > > > > I'm having a problem setting up ipf on a FreeBSD server and can't > > figure out where I'm going wrong. I copied my ipf.rules file from > > another server I have where ipf is working great. But after I > > customized the rules to this server it is filling /var/log/messages > > with lines like the following: > > > > Jan 4 15:15:21 pikeman ipmon[222]: 15:15:21.465822 2x em0 @0:33 b > > 198.32.64.12,53 -> 65.19.150.68,62097 PR udp len 20 > > 314 IN Jan 4 15:15:21 pikeman ipmon[222]: 15:15:21.492578 em0 @0:33 b > > 216.200.145.35,25 -> 65.19.150.68,57210 PR tcp len 20 60 -AS IN Jan 4 > > 15:15:21 pikeman ipmon[222]: 15:15:21.505821 em0 @0:33 b > > 205.188.156.249,25 -> 65.19.150.68,57209 PR tcp len 20 48 -AS IN > The blocked packets fall through the chain of rules and end up in rule > 0:33 (0 = incoming, 33 = block in log first quick on em0 all). > > > The lines scroll by faster than I can read them, if I tail the logfile. > > The blocked packets in this case are coming from standard ports to > > non-standard ports. Doing a reverse lookup on the ips, it would seem > > that my server has initiated the transfer and the other servers are > > simply replying. (I deduce that from the blocked ips because they belong > > to hostnames that I would not expect to be flooding my server. Namely, > > the first ip is for l.root-servers.net.) > > This seems to be an issue with the timeout of rule states. What do you > see if you run... > > $ sysctl -a | fgrep ipf. > > it should be something like: > > net.inet.ipf.fr_minttl: 4 > net.inet.ipf.fr_chksrc: 0 > net.inet.ipf.fr_defaultauthage: 600 > net.inet.ipf.fr_authused: 0 > net.inet.ipf.fr_authsize: 32 > net.inet.ipf.ipf_hostmap_sz: 2047 > net.inet.ipf.ipf_rdrrules_sz: 127 > net.inet.ipf.ipf_natrules_sz: 127 > net.inet.ipf.ipf_nattable_sz: 2047 > net.inet.ipf.fr_statemax: 4013 > net.inet.ipf.fr_statesize: 5737 > net.inet.ipf.fr_running: 1 > net.inet.ipf.fr_ipfrttl: 120 > net.inet.ipf.fr_defnatage: 1200 > net.inet.ipf.fr_icmptimeout: 120 > net.inet.ipf.fr_udpacktimeout: 24 > net.inet.ipf.fr_udptimeout: 240 > net.inet.ipf.fr_tcpclosed: 120 > net.inet.ipf.fr_tcptimeout: 480 > net.inet.ipf.fr_tcplastack: 480 > net.inet.ipf.fr_tcpclosewait: 480 > net.inet.ipf.fr_tcphalfclosed: 14400 > net.inet.ipf.fr_tcpidletimeout: 864000 > net.inet.ipf.fr_active: 0 > net.inet.ipf.fr_pass: 134217730 > net.inet.ipf.fr_flags: 0 sysctl -a | fgrep ipf shows this on the problem server: net.inet.ipf.fr_flags: 0 net.inet.ipf.fr_pass: 514 net.inet.ipf.fr_active: 0 net.inet.ipf.fr_tcpidletimeout: 864000 net.inet.ipf.fr_tcpclosewait: 480 net.inet.ipf.fr_tcplastack: 480 net.inet.ipf.fr_tcptimeout: 480 net.inet.ipf.fr_tcpclosed: 120 net.inet.ipf.fr_tcphalfclosed: 14400 net.inet.ipf.fr_udptimeout: 240 net.inet.ipf.fr_udpacktimeout: 24 net.inet.ipf.fr_icmptimeout: 120 net.inet.ipf.fr_icmpacktimeout: 12 net.inet.ipf.fr_defnatage: 1200 net.inet.ipf.fr_ipfrttl: 120 net.inet.ipf.ipl_unreach: 13 net.inet.ipf.fr_running: 1 net.inet.ipf.fr_authsize: 32 net.inet.ipf.fr_authused: 0 net.inet.ipf.fr_defaultauthage: 600 net.inet.ipf.fr_chksrc: 0 net.inet.ipf.ippr_ftp_pasvonly: 0 net.inet.ipf.fr_minttl: 3 net.inet.ipf.fr_minttllog: 1 net.link.ether.ipfw: 0 Incidentally, the server I copied my ipf.rules file from has an identical output from sysctl -a | fgrep ipf. Any more thoughts or tips? Thanks, Jacob -- GnuPG Key: 1024D/16377135 Random .signature #19: Computers are like air conditioners -- they stop working properly if you open Windows signature.asc Description: Digital signature
Re: Ipf problem
On 2006-01-06 00:17, Jacob S <[EMAIL PROTECTED]> wrote: > Hello list, > > I'm having a problem setting up ipf on a FreeBSD server and can't > figure out where I'm going wrong. I copied my ipf.rules file from > another server I have where ipf is working great. But after I > customized the rules to this server it is filling /var/log/messages > with lines like the following: > > Jan 4 15:15:21 pikeman ipmon[222]: 15:15:21.465822 2x em0 @0:33 b > 198.32.64.12,53 -> 65.19.150.68,62097 PR udp len 20 > 314 IN Jan 4 15:15:21 pikeman ipmon[222]: 15:15:21.492578 em0 @0:33 b > 216.200.145.35,25 -> 65.19.150.68,57210 PR tcp len 20 60 -AS IN Jan 4 > 15:15:21 pikeman ipmon[222]: 15:15:21.505821 em0 @0:33 b > 205.188.156.249,25 -> 65.19.150.68,57209 PR tcp len 20 48 -AS IN Your rules seem to be (numbered by running a script like the following in your ipf.rules file): echo 'incoming traffic rules:' echo '' grep '^[^#].* in ' ipf.rules | cat -n echo '' echo 'outgoing traffic rules:' echo '' grep '^[^#].* out ' ipf.rules | cat -n +- |incoming traffic rules: | | 1 pass in quick on lo0 all | 2 block in quick on em0 from 192.168.0.0/16 to any#RFC 1918 private IP | 3 block in quick on em0 from 172.16.0.0/12 to any #RFC 1918 private IP | 4 block in quick on em0 from 10.0.0.0/8 to any#RFC 1918 private IP | 5 block in quick on em0 from 127.0.0.0/8 to any #loopback | 6 block in quick on em0 from 0.0.0.0/8 to any #loopback | 7 block in quick on em0 from 169.254.0.0/16 to any#DHCP auto-config | 8 block in quick on em0 from 192.0.2.0/24 to any #reserved for docs | 9 block in quick on em0 from 204.152.64.0/23 to any #Sun cluster interconnect |10 block in quick on em0 from 224.0.0.0/3 to any #Class D & E multicast |11 block in quick on em0 all with frags |12 block in quick on em0 proto tcp all with short |13 block in quick on em0 all with opt lsrr |14 block in quick on em0 all with opt ssrr |15 block in log first quick on em0 proto tcp from any to any flags FUP |16 block in quick on em0 all with ipopts |17 block in quick on em0 proto tcp from any to any port = 113 |18 block in log first quick on em0 proto tcp/udp from any to any port = 137 |19 block in log first quick on em0 proto tcp/udp from any to any port = 138 |20 block in log first quick on em0 proto tcp/udp from any to any port = 139 |21 block in log first quick on em0 proto tcp/udp from any to any port = 81 |22 pass in quick on em0 proto tcp from any to any port = 21 flags S keep state |23 pass in quick on em0 proto tcp from any to any port = 22 flags S keep state |24 pass in quick on em0 proto tcp from any to any port = 25 flags S keep state |25 pass in quick on em0 proto tcp from any to any port = 53 flags S keep state |26 pass in quick on em0 proto udp from any to any port = 53 keep state |27 pass in quick on em0 proto tcp from any to any port = 110 flags S keep state |28 pass in quick on em0 proto tcp from any to any port = 628 flags S keep state |29 pass in quick on em0 proto tcp from 65.19.150.66 to any flags S keep state |30 pass in quick on em0 proto udp from 65.19.150.66 to any keep state |31 pass in quick on em0 proto tcp from 66.252.129.164 to any flags S keep state |32 pass in quick on em0 proto tcp from 66.252.129.165 to any flags S keep state |33 block in log first quick on em0 all | |outgoing traffic rules: | | 1 pass out quick on lo0 all | 2 pass out quick on em0 proto tcp from any to 65.19.150.66 port = 53 flags S keep state | 3 pass out quick on em0 proto udp from any to 65.19.150.66 port = 53 keep state | 4 pass out quick on em0 proto tcp from any to any port = 80 flags S keep state | 5 pass out quick on em0 proto tcp from any to any port = 443 flags S keep state | 6 pass out quick on em0 proto tcp from any to any port = 110 flags S keep state | 7 pass out quick on em0 proto tcp from any to any port = 25 flags S keep state | 8 pass out quick on em0 proto tcp from any to any port = 37 flags S keep state | 9 pass out quick on em0 proto tcp from any to any port = 119 flags S keep state |10 pass out quick on em0 proto tcp from any to any port = 21 flags S keep state |11 pass out quick on em0 proto tcp from any to any port = 22 flags S keep state |12 pass out quick on em0 proto tcp from any to any port = 23 flags S keep state |13 pass out quick on em0 proto tcp from any to any port = 5999 flags S keep state |14 pass out quick on em0 proto icmp from any to any icmp-type 8 keep state |15 pass out quick on em0 proto tcp from any to any port = 43 flags S keep state +- The blocked pa
Ipf problem
Hello list, I'm having a problem setting up ipf on a FreeBSD server and can't figure out where I'm going wrong. I copied my ipf.rules file from another server I have where ipf is working great. But after I customized the rules to this server it is filling /var/log/messages with lines like the following: Jan 4 15:15:21 pikeman ipmon[222]: 15:15:21.465822 2x em0 @0:33 b 198.32.64.12,53 -> 65.19.150.68,62097 PR udp len 20 314 IN Jan 4 15:15:21 pikeman ipmon[222]: 15:15:21.492578 em0 @0:33 b 216.200.145.35,25 -> 65.19.150.68,57210 PR tcp len 20 60 -AS IN Jan 4 15:15:21 pikeman ipmon[222]: 15:15:21.505821 em0 @0:33 b 205.188.156.249,25 -> 65.19.150.68,57209 PR tcp len 20 48 -AS IN The lines scroll by faster than I can read them, if I tail the logfile. The blocked packets in this case are coming from standard ports to non-standard ports. Doing a reverse lookup on the ips, it would seem that my server has initiated the transfer and the other servers are simply replying. (I deduce that from the blocked ips because they belong to hostnames that I would not expect to be flooding my server. Namely, the first ip is for l.root-servers.net.) I've attached the ipf.rules file to this e-mail. A uname -r on the server returns 5.4-RELEASE-p4. Can anybody see what I'm doing wrong? TIA, Jacob ipf.rules Description: Binary data ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Vexing IPF problem
On Fri, 17 Jun 2005 08:12:45 -0700 (PDT) DH <[EMAIL PROTECTED]> wrote: > I'm having a problem with IPF blocking packets that appear should be let > through. > > I've sent quite a bit of time going through the Handbook, man pages, etc & I > must be missing something so any help is greatly appriciated. > > uname -a freebsd 4.11-release #0 > > SMP kernel, dual PIII processor, 512 MB ECC RAM, SCSI HDs > > execerpt from rule set: > > Kernel compiled with "default allow" until I finish getting the ruleset > rewritten. > > Rule #1 block in log from any to any > > pass in quick on lo0 > pass out quick on lo0 > > block in log quick on fxp0 from any to any with ipopts > block in log quick proto tcp from any to any with short > ... > pass in log first proto tcp from any to any port = 80 flags S keep state > pass in log first proto tcp from any port = 80 to any flags S keep state > pass out log first proto tcp from any to any port = 80 flags S keep state > > > netstat -m = 129/576/16384 > 9% of mb_map in use > > Proxy Server - Squid 2.5.stable10 > > > The behavior I'm seeing is out going connections to websites on port 80 are > being passed > but the in bound traffic is being blocked. The ipflog entries look like this: > > > my ip = s theirs = d > > @0:390 p s.s.s.s,3601 -> d.d.d.d,80 PR tcp len 20 60 -S K-S OUT > > @0:1 b d.d.d.d,80 -> s.s.s.s,3601 PR tcp len 20 43 -AR IN > > > > Thanks in advance to those giving their time to lend a hand, I know you time > is valuable. > > Please CC my address in your reply. > > David Hutchens III > Network Technician > > > > > > - > Yahoo! Sports > Rekindle the Rivalries. Sign up for Fantasy Football > ___ > freebsd-questions@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > Any reason you avoid 'quick' keywords in rules around 390 ? Also, from my vague memory 'first' should not be necessary with 'quick'. horio shoichi ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Vexing IPF problem
David, If you just REM'd the ipopts rule the firewall will stop at the next line: block in log quick proto tcp from any to any with short Try commenting out both these lines as the "quick" in the second rule would also cause the firewall to reject incoming traffic. Using "quick" tells the firewall to stop traversing the rule set. In this case it will have read the above rule and ignored the other "in" rules. Hope this helps, John --- DH <[EMAIL PROTECTED]> wrote: > Hello John, > > The "opts" rule is actually rule # 4 - Rule #1 is: > block in log from any to any > > and the log indicates the return packet is getting > blocked at rule 1: [EMAIL PROTECTED]:1. > > Just for the heck of it I did try your suggestion & > REM'd out the "ipopts" rule but this had no effect. > > > > Thanks for the rsvp > > David Hutchens III > Network Technician > > John Conner <[EMAIL PROTECTED]> wrote: > Hello David, > > Im not expert on IPF but on first inspeciton it > would > look like the problem is in your first fxp0 rule: > > block in log quick on fxp0 from any to any with > ipopts > > To the best of my knowledge when quick is added the > firewall does not look at any of the other rules. If > this is the case having quick in the above rule > would > cause the firewall to block every incoming packet. > Hope this helps > > John > > --- DH wrote: > > > I'm having a problem with IPF blocking packets > that > > appear should be let through. > > > > I've sent quite a bit of time going through the > > Handbook, man pages, etc & I must be missing > > something so any help is greatly appriciated. > > > > uname -a freebsd 4.11-release #0 > > > > SMP kernel, dual PIII processor, 512 MB ECC RAM, > > SCSI HDs > > > > execerpt from rule set: > > > > Kernel compiled with "default allow" until I > finish > > getting the ruleset rewritten. > > > > Rule #1 block in log from any to any > > > > pass in quick on lo0 > > pass out quick on lo0 > > > > block in log quick on fxp0 from any to any with > > ipopts > > block in log quick proto tcp from any to any with > > short > > ... > > pass in log first proto tcp from any to any port = > > 80 flags S keep state > > pass in log first proto tcp from any port = 80 to > > any flags S keep state > > pass out log first proto tcp from any to any port > = > > 80 flags S keep state > > > > > > netstat -m = 129/576/16384 > > 9% of mb_map in use > > > > Proxy Server - Squid 2.5.stable10 > > > > > > The behavior I'm seeing is out going connections > to > > websites on port 80 are being passed > > but the in bound traffic is being blocked. The > > ipflog entries look like this: > > > > > > my ip = s theirs = d > > > > @0:390 p s.s.s.s,3601 -> d.d.d.d,80 PR tcp len 20 > 60 > > -S K-S OUT > > > > @0:1 b d.d.d.d,80 -> s.s.s.s,3601 PR tcp len 20 43 > > -AR IN > > > > > > > > Thanks in advance to those giving their time to > lend > > a hand, I know you time is valuable. > > > > Please CC my address in your reply. > > > > David Hutchens III > > Network Technician > > > > > > > > > > > > - > > Yahoo! Sports > > Rekindle the Rivalries. Sign up for Fantasy > > Football > > ___ > > freebsd-questions@freebsd.org mailing list > > > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > > To unsubscribe, send any mail to > > "[EMAIL PROTECTED]" > > > > > > > > > ___ > > Yahoo! Messenger - NEW crystal clear PC to PC > calling worldwide with voicemail > http://uk.messenger.yahoo.com > > __ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam > protection around > http://mail.yahoo.com ___ How much free photo storage do you get? Store your holiday snaps for FREE with Yahoo! Photos http://uk.photos.yahoo.com ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: Vexing IPF problem
Nuke & pave unfortunately is not a desireable option - there are a hair over 1k rules in the total rule set ( 99 % are address blocks of "evil doers" ). I'm observing the blocking behavior relative to addresses that are not specifically blocked. Looking at the log entries it looks as though the inbound ACK packet gets dropped after the ogoing connection request is made. Thank You for your rsvp. David Hutchens III Network Technician fbsd_user <[EMAIL PROTECTED]> wrote: 1. Best thing is scrap your firewall rules and use the IPF rules listed in the firewall/ipfilter section of the official handbook. 2. There are a lot of spoof packets using port 80 on the public internet and that may be what you are seeing. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of DH Sent: Friday, June 17, 2005 11:13 AM To: freebsd-questions@freebsd.org Subject: Vexing IPF problem I'm having a problem with IPF blocking packets that appear should be let through. I've sent quite a bit of time going through the Handbook, man pages, etc & I must be missing something so any help is greatly appriciated. uname -a freebsd 4.11-release #0 SMP kernel, dual PIII processor, 512 MB ECC RAM, SCSI HDs execerpt from rule set: Kernel compiled with "default allow" until I finish getting the ruleset rewritten. Rule #1 block in log from any to any pass in quick on lo0 pass out quick on lo0 block in log quick on fxp0 from any to any with ipopts block in log quick proto tcp from any to any with short ... pass in log first proto tcp from any to any port = 80 flags S keep state pass in log first proto tcp from any port = 80 to any flags S keep state pass out log first proto tcp from any to any port = 80 flags S keep state netstat -m = 129/576/16384 9% of mb_map in use Proxy Server - Squid 2.5.stable10 The behavior I'm seeing is out going connections to websites on port 80 are being passed but the in bound traffic is being blocked. The ipflog entries look like this: my ip = s theirs = d @0:390 p s.s.s.s,3601 -> d.d.d.d,80 PR tcp len 20 60 -S K-S OUT @0:1 b d.d.d.d,80 -> s.s.s.s,3601 PR tcp len 20 43 -AR IN Thanks in advance to those giving their time to lend a hand, I know you time is valuable. Please CC my address in your reply. David Hutchens III Network Technician - Yahoo! Sports Rekindle the Rivalries. Sign up for Fantasy Football ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]" David Hutchens III Network Technician DRS Surveillance Support Systems - A division of DRS Technologies. - Yahoo! Sports Rekindle the Rivalries. Sign up for Fantasy Football ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Vexing IPF problem
Hello David, Im not expert on IPF but on first inspeciton it would look like the problem is in your first fxp0 rule: block in log quick on fxp0 from any to any with ipopts To the best of my knowledge when quick is added the firewall does not look at any of the other rules. If this is the case having quick in the above rule would cause the firewall to block every incoming packet. Hope this helps John --- DH <[EMAIL PROTECTED]> wrote: > I'm having a problem with IPF blocking packets that > appear should be let through. > > I've sent quite a bit of time going through the > Handbook, man pages, etc & I must be missing > something so any help is greatly appriciated. > > uname -a freebsd 4.11-release #0 > > SMP kernel, dual PIII processor, 512 MB ECC RAM, > SCSI HDs > > execerpt from rule set: > > Kernel compiled with "default allow" until I finish > getting the ruleset rewritten. > > Rule #1 block in log from any to any > > pass in quick on lo0 > pass out quick on lo0 > > block in log quick on fxp0 from any to any with > ipopts > block in log quick proto tcp from any to any with > short > ... > pass in log first proto tcp from any to any port = > 80 flags S keep state > pass in log first proto tcp from any port = 80 to > any flags S keep state > pass out log first proto tcp from any to any port = > 80 flags S keep state > > > netstat -m = 129/576/16384 > 9% of mb_map in use > > Proxy Server - Squid 2.5.stable10 > > > The behavior I'm seeing is out going connections to > websites on port 80 are being passed > but the in bound traffic is being blocked. The > ipflog entries look like this: > > > my ip = s theirs = d > > @0:390 p s.s.s.s,3601 -> d.d.d.d,80 PR tcp len 20 60 > -S K-S OUT > > @0:1 b d.d.d.d,80 -> s.s.s.s,3601 PR tcp len 20 43 > -AR IN > > > > Thanks in advance to those giving their time to lend > a hand, I know you time is valuable. > > Please CC my address in your reply. > > David Hutchens III > Network Technician > > > > > > - > Yahoo! Sports > Rekindle the Rivalries. Sign up for Fantasy > Football > ___ > freebsd-questions@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to > "[EMAIL PROTECTED]" > ___ Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: Vexing IPF problem
1. Best thing is scrap your firewall rules and use the IPF rules listed in the firewall/ipfilter section of the official handbook. 2. There are a lot of spoof packets using port 80 on the public internet and that may be what you are seeing. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of DH Sent: Friday, June 17, 2005 11:13 AM To: freebsd-questions@freebsd.org Subject: Vexing IPF problem I'm having a problem with IPF blocking packets that appear should be let through. I've sent quite a bit of time going through the Handbook, man pages, etc & I must be missing something so any help is greatly appriciated. uname -a freebsd 4.11-release #0 SMP kernel, dual PIII processor, 512 MB ECC RAM, SCSI HDs execerpt from rule set: Kernel compiled with "default allow" until I finish getting the ruleset rewritten. Rule #1 block in log from any to any pass in quick on lo0 pass out quick on lo0 block in log quick on fxp0 from any to any with ipopts block in log quick proto tcp from any to any with short ... pass in log first proto tcp from any to any port = 80 flags S keep state pass in log first proto tcp from any port = 80 to any flags S keep state pass out log first proto tcp from any to any port = 80 flags S keep state netstat -m = 129/576/16384 9% of mb_map in use Proxy Server - Squid 2.5.stable10 The behavior I'm seeing is out going connections to websites on port 80 are being passed but the in bound traffic is being blocked. The ipflog entries look like this: my ip = s theirs = d @0:390 p s.s.s.s,3601 -> d.d.d.d,80 PR tcp len 20 60 -S K-S OUT @0:1 b d.d.d.d,80 -> s.s.s.s,3601 PR tcp len 20 43 -AR IN Thanks in advance to those giving their time to lend a hand, I know you time is valuable. Please CC my address in your reply. David Hutchens III Network Technician - Yahoo! Sports Rekindle the Rivalries. Sign up for Fantasy Football ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Vexing IPF problem
I'm having a problem with IPF blocking packets that appear should be let through. I've sent quite a bit of time going through the Handbook, man pages, etc & I must be missing something so any help is greatly appriciated. uname -a freebsd 4.11-release #0 SMP kernel, dual PIII processor, 512 MB ECC RAM, SCSI HDs execerpt from rule set: Kernel compiled with "default allow" until I finish getting the ruleset rewritten. Rule #1 block in log from any to any pass in quick on lo0 pass out quick on lo0 block in log quick on fxp0 from any to any with ipopts block in log quick proto tcp from any to any with short ... pass in log first proto tcp from any to any port = 80 flags S keep state pass in log first proto tcp from any port = 80 to any flags S keep state pass out log first proto tcp from any to any port = 80 flags S keep state netstat -m = 129/576/16384 9% of mb_map in use Proxy Server - Squid 2.5.stable10 The behavior I'm seeing is out going connections to websites on port 80 are being passed but the in bound traffic is being blocked. The ipflog entries look like this: my ip = s theirs = d @0:390 p s.s.s.s,3601 -> d.d.d.d,80 PR tcp len 20 60 -S K-S OUT @0:1 b d.d.d.d,80 -> s.s.s.s,3601 PR tcp len 20 43 -AR IN Thanks in advance to those giving their time to lend a hand, I know you time is valuable. Please CC my address in your reply. David Hutchens III Network Technician - Yahoo! Sports Rekindle the Rivalries. Sign up for Fantasy Football ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
