Re: pf vs ASIC firewalls
Hi all, Checkpoint guys wrote an article on checkpoint based firewalls vs Asic firewalls. You can find it here: http://www.checkpoint.com/promoforms/downloads/Specialized_Hardware_WP.pdf I do not agree upon all their visions here, but my opinion doesn't matter. Neither do i believe their software is free of giant and fully implented locking, same story for ipso on nokia machines. I believe this is necessary on content level fw's to remain performing well. And ... what exactly is the difference between proprietary os'ses and commercial software who don't publish their source? Bye, Mipam.
Re: PF and IP Precedence
* John Merriam [EMAIL PROTECTED] [2005-03-24 16:31]: What exactly does PF think 'lowdelay' is though? IPTOS_LOWDELAY of course, dunno the numeric value tho I found buried in the pf.conf man page that I should be able to specify a TOS value using something like: pass out on IF inet proto tcp from any to any tos 0xYY keep state queue QUEUE where YY is, I assume, the hexadecimal TOS byte. with that you can limit the whole rule to matching those indeed If PF gives priority to packets based on thier IP precedence/DSCP value automaticly that is not what I said -- Henning Brauer, [EMAIL PROTECTED], [EMAIL PROTECTED] BS Web Services, http://bsws.de OpenBSD-based Webhosting, Mail Services, Managed Servers, ...
AIM connection issues
Hello, I have a new firewall in development for the college i work at. I have tried extensively googling this issue in various ways and have not managed to find anything that seems pertinent. Essentially, the problem I'm having is that a client that connects to the internet through the new firewall (pf on openbsd 3.6) has problems establishing a connection to AIM (login.oscar.aol.com). I have performed severl ethereal packet sniffing sessions and can confirm that there is a successful connection established between the server and the client and then it just drops. Usually after about an hour or two of stubborn retrying and waiting it eventually works. Are there any possible pf configuration snafus that could be at fault? The only other factor that I see as possibly contributing to the problem (i'm not sure how) is that the internet connection is a set of 4 bonded t1s, but I've been given the impression that this shouldn't make a difference. Thanks. -- Florian Mosleh Network Admin. Support Manager Capitol College 301.369.2800 ext.2040 800.950.1992 ext.2040 This message was sent using IMP, the Internet Messaging Program.
Re: AIM connection issues
florian mosleh wrote: Essentially, the problem I'm having is that a client that connects to the internet through the new firewall (pf on openbsd 3.6) has problems establishing a connection to AIM (login.oscar.aol.com). I have performed severl ethereal packet sniffing sessions and can confirm that there is a successful connection established between the server and the client and then it just drops. Usually after about an hour or two of stubborn retrying and waiting it eventually works. The first thing I'd do is check that the firewall was allowing packets to the correct destination ports. One site tells me that iChat and AIM use the same ports for transactions, so this page might be interesting: http://docs.info.apple.com/article.html?artnum=93208 If you've allowed most of the ports needed, but not all, then the connection will go nicely until the client suddenly uses a service that requires a forbidden port, and then it all goes bad. (I've had a similar problem in the past getting Steam and Counter-Strike:Source to work over firewalls.) However, I've no idea why, if that is the problem, the connection would suddenly take and hold after an hour of trying. And I'm afraid I know nothing about the effect bonded T1 lines would have on a firewall setup. By the way, iChat (and seemingly AIM) seem to need a large number of ports open to work. I wouldn't be keen on that. Make sure that you don't allow incoming packets that don't match stateful inspection, unless you absolutely have to. (If an application requires me to leave ports open from the outside, I ban that application on my network.) -- Bob
Re: AIM connection issues
No pf.conf == No Answer. Sanitize and post your pf.conf. _Raju On Fri, 25 Mar 2005 13:03:38 -0500, florian mosleh [EMAIL PROTECTED] wrote: Hello, I have a new firewall in development for the college i work at. I have tried extensively googling this issue in various ways and have not managed to find anything that seems pertinent. Essentially, the problem I'm having is that a client that connects to the internet through the new firewall (pf on openbsd 3.6) has problems establishing a connection to AIM (login.oscar.aol.com). I have performed severl ethereal packet sniffing sessions and can confirm that there is a successful connection established between the server and the client and then it just drops. Usually after about an hour or two of stubborn retrying and waiting it eventually works. Are there any possible pf configuration snafus that could be at fault? The only other factor that I see as possibly contributing to the problem (i'm not sure how) is that the internet connection is a set of 4 bonded t1s, but I've been given the impression that this shouldn't make a difference. Thanks. -- Florian Mosleh Network Admin. Support Manager Capitol College 301.369.2800 ext.2040 800.950.1992 ext.2040 This message was sent using IMP, the Internet Messaging Program. -- May the packets be with you.
Re: AIM connection issues
On Fri, 2005-03-25 at 13:03, florian mosleh wrote: The only other factor that I see as possibly contributing to the problem (i'm not sure how) is that the internet connection is a set of 4 bonded t1s, but I've been given the impression that this shouldn't make a difference. you're pretty light on details--so the quality of help you receive is going to reflect that. the only thing that jumps out at me is that awhile back, AOL changed its login process such that the user actually connects to about 4 different servers in order to complete the login process. if the user's source IP changes during this process--the login fails. if you are performing outbound NAT for your clients and using a pool of addresses like so: nat on $outside inet from $inside_nets to any - $nat_pool round-robin (where prefix length of $nat_pool 32) try adding sticky-address for TCP 5190 connections (this obviously must come before the previous rule): nat on $outside inet proto tcp from $inside_nets to any port = 5190 \ - $nat_pool sticky-address if this doesn't help...well--what did you really expect? -j -- Mr. Simpson, why are you here? Don't say revenge! Don't say revenge! Revenge? That's it! I'm outta here! --The Simpsons
Re: AIM connection issues
I had the same problem with a 3.6 firewall. I was load balancing over two WAN connections and needed to force all AIM connections through one of them - apparently aol doesn't like seeing multiple source IP's. Below is the section of my pf.conf that fixed it # aim bypass rule - needed to go out only one interface pass in on $int_if route-to ($ext_if1 $ext_gw1) \ proto tcp from $lan_net to any port 5190 flags S/SA modulate state Cheers, Brian On Fri, 25 Mar 2005 13:03:38 -0500, florian mosleh [EMAIL PROTECTED] wrote: Hello, I have a new firewall in development for the college i work at. I have tried extensively googling this issue in various ways and have not managed to find anything that seems pertinent. Essentially, the problem I'm having is that a client that connects to the internet through the new firewall (pf on openbsd 3.6) has problems establishing a connection to AIM (login.oscar.aol.com). I have performed severl ethereal packet sniffing sessions and can confirm that there is a successful connection established between the server and the client and then it just drops. Usually after about an hour or two of stubborn retrying and waiting it eventually works. Are there any possible pf configuration snafus that could be at fault? The only other factor that I see as possibly contributing to the problem (i'm not sure how) is that the internet connection is a set of 4 bonded t1s, but I've been given the impression that this shouldn't make a difference. Thanks. -- Florian Mosleh Network Admin. Support Manager Capitol College 301.369.2800 ext.2040 800.950.1992 ext.2040 This message was sent using IMP, the Internet Messaging Program.
Re: AIM connection issues
I am interested in Brian Kerr's suggestion, but I guess I'll have to wait until
Monday. Thank you.
In response to M Raju, here's my pf.conf.
njoy.
---begin pf.conf
## here are my macros
EXTIF=xl2
DMZIF=xl1
INTIF=xl0
#DMZ
DORMS=10.0.0.11
DORMSEXT=x.x.x.12
DAVINCI=10.0.0.13
DAVINCIEXT=x.x.x.13
COOLIDGE=192.168.28.65
COOLIDGEEXT=x.x.x.14
HTTP_PORTS={ 80, 443 }
MAIL_PORTS={ 25, 143, 220, 109, 110, 993, 995 }
##these are runtime options for pf to make it fit our needs better
set block-policy return
set loginterface $EXTIF
##scrub adds an extra layer of packet defragmentation to the good 'ol native
tcp
one
scrub in all
scrub out all
##queuing. let's give qos a shot
altq on xl2 cbq bandwidth 100% queue { main, dorms, misc }
queue main bandwidth 50% cbq(borrow) { pri_q, def_q }
queue pri_q bandwidth 10% priority 7
queue def_q bandwidth 90% priority 1 cbq(borrow)
queue dorms bandwidth 35% { dorms_http_q, dorms_pri_q, dorms_mail_q }
queue dorms_http_q bandwidth 70% priority 4 cbq(borrow)
queue dorms_pri_q bandwidth 10% priority 6
queue dorms_mail_q bandwidth 20% priority 5
queue misc bandwidth 15% priority 2 cbq(default)
##nat and redirection (i love this part)
nat pass on $EXTIF from $INTIF:network to any - ($EXTIF)
binat on $EXTIF from $DORMS to any - $DORMSEXT
binat on $EXTIF from $DAVINCI to any - $DAVINCIEXT
rdr on $INTIF proto tcp from any to $DAVINCIEXT - $DAVINCI
binat on $EXTIF from $COOLIDGE to any - $COOLIDGEEXT
binat pass on $INTIF from $COOLIDGE to any - $COOLIDGEEXT
rdr on $EXTIF proto tcp from any to $COOLIDGEEXT port 80 - $COOLIDGE port
rdr on $EXTIF proto tcp from any to $COOLIDGEEXT port 3306 - $COOLIDGE
rdr pass on $INTIF proto tcp from $INTIF:network to $COOLIDGEEXT port 80 -
127.
0.0.1 port
rdr pass on $INTIF proto tcp from $INTIF:network to $COOLIDGEEXT port 3306 -
12
7.0.0.1 port 3306
rdr on $INTIF proto tcp from any to any port 21 - 127.0.0.1 port 8021
rdr pass on $EXTIF proto tcp from any to ($EXTIF) port - 192.168.28.80
##filter rules
antispoof for xl2
block log all
pass on lo0 all
pass in inet proto icmp all icmp-type echoreq keep state
pass in on $INTIF from $INTIF:network to any keep state queue def_q
pass out on $INTIF from any to $INTIF:network keep state
pass in quick on $EXTIF proto tcp from any to $EXTIF flags S/SA keep state
queue
pri_q
pass out quick on $EXTIF proto tcp from $EXTIF to any flags S/SA keep state
queu
e pri_q
pass in on $DMZIF from $DORMS to any keep state
pass out on $DMZIF from any to $DORMS keep state queue dorms_ssh_q
pass in on $DMZIF proto tcp from $DORMS to any port $HTTP_PORTS keep state
pass out on $DMZIF proto tcp from any to $DORMS port $HTTP_PORTS keep state
queu
e dorms_http_q
pass in on $DMZIF proto tcp from $DORMS to any port $MAIL_PORTS keep state
pass out on $DMZIF proto tcp from any to $DORMS port $MAIL_PORTS keep state
queu
e dorms_mail_q
pass in on $DMZIF proto tcp from $DORMS to any port 22 keep state
pass out on $DMZIF proto tcp from any to $DORMS port 22 keep state queue
dorms_p
ri_q
pass in on $EXTIF inet proto tcp from any to $DORMSEXT keep state queue dorms
pass in on $EXTIF inet proto tcp from port 22 to ($DORMSEXT) keep state
pass in on $DMZIF from $DAVINCI to any keep state
pass out on $DMZIF from any to $DAVINCI keep state queue misc
pass in on $EXTIF inet proto tcp from port 22 to ($DAVINCIEXT) keep state
pass in on $EXTIF proto tcp from any to $COOLIDGE port keep state
pass in on $EXTIF proto tcp from any to $COOLIDGE port 3306 keep state
pass in on $EXTIF proto icmp from any to $COOLIDGE keep state
#pass in on $INTIF proto tcp from any to $COOLIDGE port keep state
#pass in on $INTIF proto tcp from any to $COOLIDGE port 3306 keep state
pass out on $INTIF from $COOLIDGE to any keep state
pass out on $EXTIF proto tcp all modulate state flags S/SA
pass out on $EXTIF proto { udp, icmp } all keep state
pass in on $EXTIF inet proto tcp from port 20 to ($EXTIF) user proxy flags S/SA
keep state
pass out on $EXTIF inet proto { udp, icmp } all keep state queue misc
---end pf.conf
--
Florian Mosleh
Network Admin. Support Manager
Capitol College
301.369.2800 ext.2040
800.950.1992 ext.2040
Quoting M Raju [EMAIL PROTECTED]:
No pf.conf == No Answer. Sanitize and post your pf.conf.
_Raju
On Fri, 25 Mar 2005 13:03:38 -0500, florian mosleh
[EMAIL PROTECTED] wrote:
Hello,
I have a new firewall in development for the college i work at. I have
tried
extensively googling this issue in various ways and have not managed to
find
anything that seems pertinent.
Essentially, the problem I'm having is that a client that connects to the
internet through the new firewall (pf on openbsd 3.6) has problems
establishing
a connection to AIM (login.oscar.aol.com). I have performed severl
ethereal
packet sniffing sessions and can confirm that there is a successful
connection
established between the server
Anchors with tables
Looking at pf.conf (5), it claims that anchors can hold rules, address
tables, and other anchors. Unfortunately, neither the man page nor
the PF User's Guide give an example of using an anchor to hold address
tables. I've tried this on 3.6 -release, and it does not appear to
work:
snip /etc/pf.conf
ext_if=fxp1
int_if=fxp0
pfsync_if=xl0
anchor pf_labels_tables
load anchor pf_labels_tables from /etc/pf_labels_tables.anchor
/snip
# cat /etc/pf_labels_tables.anchor
table site1_in { 10.0.0.101 }
table site2_in { 10.0.0.102 }
table site3_in { 10.0.0.103 }
table site4_in { 10.0.0.104 }
table site5_in { 10.0.0.105 }
table site1_out { 192.168.0.31 }
table site2_out { 192.168.0.32 }
table site3_out { 192.168.0.33 }
table site4_out { 192.168.0.34 }
table site5_out { 192.168.0.35 }
# pfctl -nf /etc/pf.conf
/etc/pf.conf:17: Rules must be in order: options, normalization,
queueing, translation, filtering
/etc/pf.conf:18: Rules must be in order: options, normalization,
queueing, translation, filtering
/etc/pf.conf:20: Rules must be in order: options, normalization,
queueing, translation, filtering
/etc/pf.conf:22: Rules must be in order: options, normalization,
queueing, translation, filtering
/etc/pf.conf:23: Rules must be in order: options, normalization,
queueing, translation, filtering
/etc/pf.conf:24: Rules must be in order: options, normalization,
queueing, translation, filtering
/etc/pf.conf:25: Rules must be in order: options, normalization,
queueing, translation, filtering
/etc/pf.conf:26: Rules must be in order: options, normalization,
queueing, translation, filtering
It appears that pfctl assumes that anchors only contain filter rules.
Have I stumbled over a bug in either pf.conf (5) or pfctl, or am I
doing/assuming something wrong?
Thanks,
--
Jason Dixon
DixonGroup Consulting
http://www.dixongroup.net
