Re: AIM connection issues
fixed.
the issue was that i had additional addresses aliased onto the external
interface and did not have an address explicitly defined for NAT between the lan
and the internet:
nat pass on $EXTIF from $INTIF:network to any - ($EXTIF)
it would seem that pf doesn't always pick the primary interface address in cases
like these. changing it to
nat pass on $EXTIF from $INTIF:network to any - xxx.xxx.xxx.xxx
has resolved the issue. thanks for your help!
--
Florian Mosleh
Network Admin. Support Manager
Capitol College
301.369.2800 ext.2040
800.950.1992 ext.2040
Quoting florian mosleh [EMAIL PROTECTED]:
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
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
