RE: Re[2]: PF rules for internal interface
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:owner-freebsd-
> [EMAIL PROTECTED] On Behalf Of Vitaliy Vladimirovich
> Sent: Wednesday, March 26, 2008 6:58 AM
> To: Jeremy Chadwick
> Cc: freebsd-pf@freebsd.org
> Subject: Re[2]: PF rules for internal interface
>
> --- Original Message --- From: Jeremy Chadwick To: Vitaliy
> Vladimirovich Date: 26 march, 12:00:30 Subject: Re: PF rules for
> internal interface > On Wed, Mar 26, 2008 at 10:51:52AM +0200, Vitaliy
> Vladimirovich wrote: > > Hello! I have problem with restriction rules
> for my internal interface. > > ... > > Please don't stick stuff like
> this all on one line. It's impossible to > read. > > > This is my rules
> for $int_if: > > > > pass out quick on $int_if > > block in on $int_if
> > > pass in on $int_if from $mynet to any > > > > But in this situation
> computers from another subnets can ping my > > internal interface. Were
> is my mistake? Thanks in advance. > > Are these the ONLY RULES you have
> in your pf.conf? > > If not: you must remember that the deny/block in
> "block in on $int_if" > may get overridden later in the file, depending
> upon what rules past > that point are. This may be what's happening,
> assuming later rules do > not specify an interface (thus matching all
> interfaces). For
> example, > if your rules are: > > pass out quick on $int_if > block in
> on $int_if > pass in on $int_if from $mynet to any > pass in from
> $othernet to any > > In this case, the "block" will not happen when
> incoming packets from > $othernet arrive on $int_if. > > I've two
> recommendations: > > 1) Consider using "antispoof", if your concern is
> someone spoofing > packets across $int_if > > 2) Consider using these
> rules instead: > > pass in quick on $int_if from $mynet to any > pass
> out quick on $int_if from $mynet to any > block in quick on $int_if >
> {...other rules...} OK. Below my new rules within your recommendations:
> int_if="sk0" mynet="10.0.100.0/16" antispoof quick for { lo0 sk0 } pass
> in quick on $int_if from $mynet to any pass out quick on $int_if from
> any to $mynet block in quick on $int_if But it is not work. I can ping
> my server from another host not in mynet. What's wrong??
Something is wrong with your formatting in your emails. Newlines are
non-existant and your email is impossible to read. Please re-format your
emails.
___
freebsd-pf@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-pf
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Problem with consistent disconnection of IRC sessions
I am running a basic freebsd 7.0 pf router/firewall for my home computer. On this same machine I am usually running an IRC (tcp 6667) session. It seems as though every 30 minutes to every several hours, my IRC session disconnects and reconnects itself. I'm passing in/out tcp 6667 w/ FLAGS S/SA keep state. I'm scrub in all + scrub out all , and basically it's a standard setup. I'm wondering if anyone can help me more. I have my PF rules if more information is needed but hopefully someone has a suggestion without requiring that. Thank you, Kevin K. ___ freebsd-pf@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-pf To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: UDP weirdness
Try pass out proto udp from any to any port 53 > -Original Message- > From: [EMAIL PROTECTED] [mailto:owner-freebsd- > [EMAIL PROTECTED] On Behalf Of Ansar Mohammed > Sent: Wednesday, May 07, 2008 1:34 PM > To: freebsd-pf@freebsd.org > Subject: UDP weirdness > > I have a very simple configuration yet I am bemused as to what I am > doing > wrong. > > > Windows 2003 <- FreeBSD-PF ->Windows 2003 > 192.168.3.2 192.168.3.1 192.168.2.2 192.168.2.130 > Here are my rules > > > ext_if="le0" > int_if="le1" > int_net="192.168.3.0/24" > ext_net="192.168.2.0/24" > int_addr="192.168.3.1" > ext_addr="192.168.2.2" > scrub on $ext_if all reassemble tcp > scrub on $int_if all reassemble tcp > block in log all > pass in proto icmp from any to any > pass in proto udp from any to any port 53 > pass in on $ext_if inet proto tcp from any to any port 3389 > > > DNS traffic is allowed though but the return packet gets blocked. Can > anyone > explain why? > This is true on ALL UDP traffic TCP traffic works well > > Pflog message: > > 065276 rule 0/0(match): block in on le1: 192.168.3.2.53 > > 192.168.2.130.3837: [|domain] > > > > > ___ > freebsd-pf@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-pf > To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-pf@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-pf To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: UDP weirdness
You cannot track state of stateless protocols such as UDP. > -Original Message- > From: Ansar Mohammed [mailto:[EMAIL PROTECTED] > Sent: Wednesday, May 07, 2008 4:54 PM > To: 'Jille' > Cc: 'Kevin K'; freebsd-pf@freebsd.org > Subject: RE: UDP weirdness > > But I thought pf would be tracking state? > Isnt that the whole point of statefull firewalls? > > > > > -Original Message- > > From: Jille [mailto:[EMAIL PROTECTED] > > Sent: May 7, 2008 4:50 PM > > To: Ansar Mohammed > > Cc: 'Kevin K'; freebsd-pf@freebsd.org > > Subject: Re: UDP weirdness > > > > > > > > Ansar Mohammed schreef: > > > Ok, so adding the line as you suggested worked. > > > Thanks Kevin. > > > > > > But why do I need to have both entries in for > > > > > > pass in proto udp from any to any port 53 > > > pass out proto udp from any to any port 53 > > > > > > what makes UDP so special? > > UDP is stateless, > > With TCP you've got an connection (identified by: local host:port and > > remote host:port) > > With UDP, well, you just trow the packages over the line, and hope > the > > is (still) someone on the other end. > > > > So the is (almost) no way to detect whether packets are responses to > > eachother > > > > -- Jille ___ freebsd-pf@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-pf To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: (No subject)
You can use tools from ports like trafshow, iftop and pftop to display the statistics that you are looking for. > -Original Message- > From: [EMAIL PROTECTED] [mailto:owner-freebsd- > [EMAIL PROTECTED] On Behalf Of Vitaliy Vladimirovich > Sent: Tuesday, June 03, 2008 3:56 PM > To: freebsd-pf@freebsd.org > Subject: (No subject) > > Hi, All! > > I use pfstat on my FreeBSD box and I have some questions: > > 1. How can I monitorig not only bandwidth but total upload and download > data? > 2 Can I have statistic on each IP from LAN? > > TIA > > ___ > freebsd-pf@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-pf > To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-pf@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-pf To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: PF in kernel or as a module
I'm curious if there has been some benchmarking done to compare the two methods of enabling PF. The security debate could be argued to be circumstantial, but I'd like to hear from people who use it in production via loaded module, as my only experience with PF is building it into the kernel. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Martin Turgeon Sent: Friday, January 26, 2007 8:54 AM To: Max Laier Cc: freebsd-pf@freebsd.org Subject: Re: PF in kernel or as a module Max Laier a écrit : On Tuesday 23 January 2007 22:57, Martin Turgeon wrote: I would like to start a debate on this subject. Which method of enabling PF is the more secure (buffer overflow for example), the fastest, the most stable, etc. I searched the web for some info but without result. So I would like to know your opinion on the pros and cons of each method. Kernel module - loaded via loader.conf - is as secure as built in. There is a slight chance, that somebody might be able to compromise the module on disk, but then they are likely to be able to write to the kernel (in the same location) as well. An additional plus is the possibility of freebsd-update if you do not have to build a custom kernel. Note that some features are only available when built in: pfsync and altq - this is not going to change for technical reasons. Performance wise there should be no difference. Thanks a lot, that's exactly the type of answer I wanted. I'm always surprised to see how much knowledge the FreeBSD mailinglists are sharing. Thank you for your effort Martin Turgeon ___ freebsd-pf@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-pf To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-pf@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-pf To unsubscribe, send any mail to "[EMAIL PROTECTED]"
PF & Windows Vista
I am using FreeBSD 6.2-release w/ PF. Everything seems to be okay, except the fact that Windows Vista machines cant get through the network. I have tried many things, including just using a skeleton PF configuration and I'm still having trouble. Just curious if anyone has experienced issues with this? If so, any suggestions or resolutions would be appreciated. Below is what we thought would fix the vista issue, but to no avail : ### Office for Vista issue -- no state pass in log quick on $ext_if inet proto tcp from xxx.xxx.xxx.xxx/32 to any pass in quick on $ext_if inet proto udp from xxx.xxx.xxx.xxx/32 to any pass in quick on $ext_if inet proto icmp from xxx.xxx.xxx.xxx/32 to any pass in quick on $ext_if inet proto tcp from xxx.xxx.xxx.xxx/32 to any ___ freebsd-pf@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-pf To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: PF & Windows Vista
>Do you imply that you have other operating system behind your FreeBSD wall, but have not this sort of issue? Is the >problem Vista specific? Only FreeBSD machines are behind the firewall. The issue lies with a Vista machine accessing the network through the firewall. The connection attempt (regardless of protocol) eventually times out. ___ freebsd-pf@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-pf To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: PF & Windows Vista
> > >Do you imply that you have other operating system behind your FreeBSD > wall, > but have not this sort of issue? Is the >problem Vista specific? > > > Only FreeBSD machines are behind the firewall. The issue lies with a > Vista > machine accessing the network through the firewall. The connection > attempt > (regardless of protocol) eventually times out. > To clarify even further (sorry for the 2nd msg). Most (if not all) other machines are able to access my network through the PF firewall without any issues (xp/2000/nt , linux, bsd). As soon as a Windows Vista machine tries to access my network, the connection attempt times out (www, ftp, ssh). I'd like to know if anyone else has experienced something similar with Vista and their firewall. I realize it may be something with Vista, but this issue seems to be related with PF firewalls and Vista. ___ freebsd-pf@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-pf To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: PF & Windows Vista
Dennis Berger wrote: > We have a vista client and openbsd 3.9 pf box here. no problems at all. > What you could try is something like this. > > pass in quick on $ext_if fastroute inet proto tcp from $somewhere to > any > I'm going to try that, but I'm looking for a solution where I don't have to add $somewhere for each vista machine trying to get in. ___ freebsd-pf@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-pf To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: PF & Windows Vista
Volker wrote:
>
> Kevin,
>
> helping you with just this snippet of rules is like fishing in the
> dark.
>
> Your rules do the following: A connection coming from a single IP
> address (/32) is passing the firewall on the external IF. As it does
> not create state (no keep state option) the answer to that incoming
> connection will probably never reach the originating IP address.
>
> As you're logging but do not keep state, you're getting a whole
> bunch of log entries which might render your logs unreadable (every
> packet is being logged instead of every connection).
>
> If your rules work properly for other hosts (again, your snippet of
> rules is useless for supporting you) I'm wondering if your Vista
> machine does IPv6 and does not try v4? I don't know Vista at all but
> I guess v6 support is built in.
>
> Greetings,
>
> Volker
I was hoping that the issue was simple and common, due to Vista's emphasis
on ipv6 among other networking issues. Either way, below is my entire pf
configuration. I hope it helps.
### Firewalls are Sun Netra X1 UltraSPARC IIe 400
ext_if="dc1"
int_if="dc0"
loop_if="lo0"
internal_addr="xxx.xxx.xxx.x
external_addr="xx.xxx.xxx.xxx
internal_net="xxx.xxx.xxx.x
external_net="xx.xxx.xxx.xxx
### Load carp interfaces
c1="carp1"
c130="carp130"
c131="carp131"
c132="carp132"
c133="carp133"
c134="carp134"
c135="carp135"
c136="carp136"
c137="carp137"
c138="carp138"
c139="carp139"
c140="carp140"
c141="carp141"
c142="carp142"
c143="carp143"
c144="carp144"
c145="carp145"
c146="carp146"
c147="carp147"
c148="carp148"
c149="carp149"
c150="carp150"
c151="carp151"
c152="carp152"
c153="carp153"
c154="carp154"
c155="carp155"
c156="carp156"
c157="carp157"
c158="carp158"
c159="carp159"
c160="carp160"
c161="carp161"
c162="carp162"
c163="carp163"
c164="carp164"
c165="carp165"
c166="carp166"
c167="carp167"
c168="carp168"
c169="carp169"
c170="carp170"
c171="carp171"
c172="carp172"
c173="carp173"
c174="carp174"
c175="carp175"
c176="carp176"
c177="carp177"
c178="carp178"
c179="carp179"
c180="carp180"
c181="carp181"
c182="carp182"
c183="carp183"
c184="carp184"
c185="carp185"
c186="carp186"
c187="carp187"
c188="carp188"
InServicesTCP = "{ http, https }"
InServicesUDP = "{ domain, ntp, rpc }"
OutServicesTCP = "{ http, https, whois }"
OutServicesUDP = "{ ntp, domain, rpc }"
ProtoBlocked = "{ tcp, udp }"
table const file "/etc/firewall/carp_extaddr.tbl"
table const file "/etc/firewall/ip_localblock.tbl"
table persist file "/etc/firewall/ip_caught.tbl" file
"/etc/firewall/ip_exploit.tbl"
#table file "/etc/firewall/excess_conns.tbl"
table persist
table persist
table persist
table persist
table persist
table persist
table persist
table persist
table persist
table persist
table persist
table persist
table persist
table persist
table persist
table persist
table persist
table persist
table persist
table persist
table const file "/etc/firewall/web_server_ips.tbl"
#table persist file "/etc/firewall/ssh_hackers.tbl"
table persist
table persist file "/etc/firewall/sendmail_hacks.tbl"
table persist file "/etc/firewall/blacklistproxies.tbl"
table persist file "/etc/firewall/port_scanners.tbl"
open for unabated users
table { xx.xxx.xxx.xxx }
nfs table for hosts
#table { xxx.xxx.xxx.x
# Safe users
table { xxx.xxx.xxx.x }
# Options: tune the behavior of pf, default values are given.
set timeout { interval 30, frag 60, src.track 180 }
set timeout { tcp.first 120, tcp.opening 30, tcp.established 86400 }
set timeout { tcp.closing 900, tcp.finwait 45, tcp.closed 90 }
set timeout { udp.first 60, udp.single 30, udp.multiple 60 }
set timeout { icmp.first 20, icmp.error 10 }
set timeout { other.first 60, other.single 30, other.multiple 60 }
set timeout { adaptive.start 0, adaptive.end 0 }
set limit { states 200, frags 100 }
set loginterface none
set optimization normal
set block-policy drop
set require-order yes
set fingerprints "/etc/pf.os"
# Normalization: reassemble fragments and resolve or reduce traffic
ambiguities.
scrub in all
### rdr's
rdr on $ext_if proto tcp from any to ($c130) port 80 -> xxx.xxx.xxx.x
rdr on $ext_if proto tcp from any to ($c131) port 80 -> xxx.xxx.xxx.x
rdr on $ext_if proto tcp from any to ($c132) port 80 -> xxx.xxx.xxx.x
rdr on $ext_if proto tcp from any to ($c133) port 80 -> xxx.xxx.xxx.x
rdr on $ext_if proto tcp from any to ($c134) port 80 -> xxx.xxx.xxx.x
rdr on $ext_if proto tcp from any to ($c135) port 80 -> xxx.xxx.xxx.x
rdr on $ext_if proto tcp from any to ($c136) port 80 -> xxx.xxx.xxx.x
rdr on $ext_if proto tcp from any to ($c137) port 80 -> xxx.xxx.xxx.x
rdr on $ext_if proto tcp from any to ($c138) port 80 -> xxx.xxx.xxx.x
rdr on $ext_if proto tcp from any to ($c139) port 80 -> xxx.xxx.xxx.x
rdr on $ext_if proto tcp from any to ($c140) port 80 -> xxx.xxx.xxx.x
rdr on $ext_if proto tcp from any to ($c141) port 80 -> xxx.xxx.xxx.x
rdr on $ext_if proto tcp from any to ($c142) port 80 -> xxx.xxx.xxx.x
rdr on $ext_
RE: PF & Windows Vista
> David Nguyen wrote: > >I've installed Vista recently and it detected the network drivers and > "seemed" to be working (default drivers with >Vista). I thought it was > the network, but it was actually the network drivers that came with > vista (nForce). I would >retrieve a DHCP, but would not communicate. no > ping, no dns > > > >I then installed the ones from nVidia site and everything worked. So > it may be the drivers are broken, have you tried >installing the > manufacturers drivers. I hope this helps. > > > >Cheers > >David > > I think the issue is with Vista working fine with other networks / firewalls (as far as I can tell) ,but with my freebsd PF firewall it is not able to connect to anything behind it. ___ freebsd-pf@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-pf To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: PF and AD
The only thing I can think of is if maybe the firewall uses the Microsoft server as DNS, and you should be able to resolve computer names and write rules in PF accordingly. I am planning on implementing a couple FBSD PF boxes in front of some Windows servers, so it would be interesting if anyone else has done such a thing. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ricardo Benq Sent: Thursday, May 03, 2007 5:01 PM To: freebsd-pf@freebsd.org Subject: PF and AD Hello. Is it possible to make filter rules that are based on Microsoft Active Directory users? Do I have to install samba/winbind? Are there tutorials? Thanks in advance, Ben. _ MSN Messenger: instale grátis e converse com seus amigos. http://messenger.msn.com.br ___ freebsd-pf@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-pf To unsubscribe, send any mail to "[EMAIL PROTECTED]" __ NOD32 2237 (20070503) Information __ This message was checked by NOD32 antivirus system. http://www.eset.com ___ freebsd-pf@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-pf To unsubscribe, send any mail to "[EMAIL PROTECTED]"
