asked on

PIX 515 and OWA

I have been thown into a situation where I am clueless any help would be GREATLY appriaciated. (There is a long story, and we will keep it at that.) Second I am 100% PIX stupid. Please make sure to give step by step instructions. I have tried to sift through the other posts on this and every setup seems uniqe, I was only able to print the PIX config (using sh run) that follows by following another example posted on this site.

We have a PIX Version 6.3(1) (I know that another post mentioned to update this but I don't think we have support agreement for the PIX, will be checking into that.) We had our Exchange 2003 server on an internal IP of 192.168.0.15, exhange was removed from this server and moved to 192.168.0.10 (All part of the long story.) Since the move OWA is now broken, we cannot access it from the external IP. Internal is working at http://192.168.0.10/Exchange/. I was told the external IP login was this: http://x.y.163.2/exchange. Hopefully from this info and the sh run post that follows someone can make sense of it all. Thanks again for the help!!

sh run
PIX Version 6.3(1)
interface ethernet0 100full
interface ethernet1 100full
interface ethernet2 auto
interface ethernet3 100full
interface ethernet4 auto shutdown
interface ethernet5 auto shutdown
nameif ethernet0 outside security0
nameif ethernet1 inside security100
nameif ethernet2 dmz1 security10
nameif ethernet3 CERTEGY security15
nameif ethernet4 intf4 security20
nameif ethernet5 intf5 security99
enable password P5FIXocFpRQoHto6 encrypted
passwd rNl.20x9JprhuNWV encrypted
hostname mydomain-PIX
domain-name mydomain.com
fixup protocol ftp 21
fixup protocol h323 h225 1720
fixup protocol h323 ras 1718-1719
fixup protocol http 80
fixup protocol ils 389
fixup protocol pptp 1723
fixup protocol sip 5060
fixup protocol sip udp 5060
fixup protocol skinny 2000
no fixup protocol smtp 25
fixup protocol sqlnet 1521
no names
access-list certegy-dmz permit icmp any host 192.168.250.2 echo-reply
access-list certegy-dmz permit icmp any host 192.168.250.2 unreachable
access-list certegy-dmz permit icmp any host 192.168.250.2 source-quench
access-list certegy-dmz permit icmp any host 192.168.250.2 redirect
access-list certegy-dmz permit icmp any host 192.168.250.100 echo-reply
access-list certegy-dmz permit icmp any host 192.168.250.100 unreachable
access-list certegy-dmz permit icmp any host 192.168.250.100 source-quench
access-list certegy-dmz permit icmp any host 192.168.250.100 redirect
access-list certegy-dmz permit tcp host 216.189.226.23 host 192.168.250.2 eq 122
10
access-list certegy-dmz permit icmp any host 192.168.0.2 echo-reply
access-list INET permit tcp any host x.y.163.10 eq https
access-list INET permit tcp any host x.y.163.10 eq www
access-list INET permit icmp any any echo-reply
access-list INET permit icmp any any source-quench
access-list INET permit icmp any any unreachable
access-list INET permit gre host x.y.23.98 any
access-list INET permit tcp any host x.y.163.15 eq www
access-list INET permit tcp any host x.y.163.15 eq https
access-list DMZ permit tcp host 192.168.10.2 host 192.168.10.102 eq 7500
access-list DMZ permit udp host 192.168.10.2 host 192.168.10.102 eq 7500
access-list DMZ permit tcp host 192.168.10.2 host 192.168.10.102 eq 7501
access-list DMZ permit udp host 192.168.10.2 host 192.168.10.102 eq 7501
access-list 101 permit ip 192.168.0.0 255.255.255.0 172.16.0.0 255.255.255.0
access-list 101 permit ip 192.168.50.0 255.255.255.0 172.16.0.0 255.255.255.0
access-list 101 permit ip 192.168.100.0 255.255.255.0 172.16.0.0 255.255.255.0
access-list 102 permit ip 192.168.10.0 255.255.255.0 172.16.0.0 255.255.255.0
pager lines 25
logging on
logging timestamp
logging trap informational
logging history informational
logging host inside 192.168.0.62
icmp permit any echo-reply outside
icmp permit any unreachable outside
icmp permit any alternate-address outside
icmp permit any time-exceeded outside
mtu outside 1500
mtu inside 1500
mtu dmz1 1500
mtu CERTEGY 1500
mtu intf4 1500
ip address outside x.y.163.2 255.255.255.224
ip address inside 192.168.0.254 255.255.255.0
ip address dmz1 192.168.10.1 255.255.255.0
ip address CERTEGY 192.168.250.254 255.255.255.0
ip address intf4 127.0.0.1 255.255.255.255
no ip address intf5
ip verify reverse-path interface outside
ip audit info action alarm
ip audit attack action alarm
ip local pool VPN 172.16.0.1-172.16.0.254
no failover
failover timeout 0:00:00
failover poll 15
no failover ip address outside
no failover ip address inside
no failover ip address dmz1
no failover ip address CERTEGY
no failover ip address intf4
no failover ip address intf5
pdm location 192.168.0.2 255.255.255.255 inside
pdm location 192.168.50.0 255.255.255.0 inside
pdm location 192.168.10.2 255.255.255.255 dmz1
pdm location 192.168.0.73 255.255.255.255 inside
pdm location 192.168.250.0 255.255.255.0 inside
pdm location 192.168.0.2 255.255.255.255 CERTEGY
pdm location 192.168.0.99 255.255.255.255 inside
pdm logging informational 100
pdm history enable
arp timeout 14400
global (outside) 1 x.y.163.3 netmask 255.255.255.224
global (outside) 2 x.y.163.4 netmask 255.255.255.224
global (outside) 3 x.y.163.5 netmask 255.255.255.224
global (dmz1) 1 192.168.10.100
global (CERTEGY) 1 192.168.250.100
nat (inside) 0 access-list 101
nat (inside) 1 192.168.0.0 255.255.255.0 0 0
nat (inside) 2 192.168.50.0 255.255.255.0 0 0
nat (inside) 3 192.168.100.0 255.255.255.0 0 0
nat (dmz1) 0 access-list 102
static (inside,dmz1) 192.168.10.102 192.168.0.2 netmask 255.255.255.255 0 0
static (inside,CERTEGY) 192.168.250.2 192.168.0.2 netmask 255.255.255.255 0 0
static (inside,CERTEGY) 192.168.250.99 192.168.0.99 netmask 255.255.255.255 0 0
static (inside,outside) x.y.163.15 192.168.0.15 netmask 255.255.255.255 0 0
static (dmz1,outside) x.y.163.10 192.168.10.2 netmask 255.255.255.255 0 0
access-group INET in interface outside
access-group DMZ in interface dmz1
access-group certegy-dmz in interface CERTEGY
route outside 0.0.0.0 0.0.0.0 x.y.163.1 1
route inside 192.168.100.0 255.255.255.0 192.168.0.1 1
route CERTEGY 216.189.224.0 255.255.240.0 192.168.250.1 1
timeout xlate 3:00:00
timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 rpc 0:10:00 h225 1:00:00
timeout h323 0:05:00 mgcp 0:05:00 sip 0:30:00 sip_media 0:02:00
timeout uauth 0:05:00 absolute
aaa-server TACACS+ protocol tacacs+
aaa-server RADIUS protocol radius
aaa-server LOCAL protocol local
http server enable
http 192.168.250.0 255.255.255.0 inside
http 192.168.0.73 255.255.255.255 inside
http 192.168.0.0 255.255.0.0 inside
no snmp-server location
no snmp-server contact
snmp-server community public
no snmp-server enable traps
floodguard enable
sysopt connection permit-ipsec
crypto ipsec transform-set VPN esp-des esp-md5-hmac
crypto dynamic-map dynvpn 10 set transform-set VPN
crypto map VPNCLIENT 10 ipsec-isakmp dynamic dynvpn
crypto map VPNCLIENT interface outside
isakmp enable outside
crypto dynamic-map dynvpn 10 set transform-set VPN
crypto map VPNCLIENT 10 ipsec-isakmp dynamic dynvpn
crypto map VPNCLIENT interface outside
isakmp enable outside
isakmp identity address
isakmp policy 10 authentication pre-share
isakmp policy 10 encryption des
isakmp policy 10 hash md5
isakmp policy 10 group 2
isakmp policy 10 lifetime 86400
vpngroup MYVPN address-pool VPN
vpngroup MYVPN dns-server 192.168.0.15
vpngroup MYVPN wins-server 192.168.0.15
vpngroup MYVPN default-domain mydomain.com
vpngroup MYVPN idle-time 1800
vpngroup MYVPN password ********
telnet 192.168.250.0 255.255.255.0 inside
telnet 192.168.0.0 255.255.255.0 inside
telnet 192.168.0.0 255.255.0.0 inside
telnet timeout 30
ssh timeout 5
console timeout 0
terminal width 80
Cryptochecksum:c7a037e7c212e45a47f00180e5e7d7bd
: end

ASKER CERTIFIED SOLUTION

billwharton

membership

This solution is only available to members.

To access this solution, you must be a member of Experts Exchange.

Start Free Trial

batry_boy

I agree that the missing static translation statement is the source of this problem, but I would go a bit further and make a couple of suggestions:

1) From the problem description, it looks like you are using http (i.e. unencrypted) traffic to allow external users to hit the Exchange server for OWA access. I suggest you use https since this traffic is coming from the world and you can't filter this type of traffic by source IP address since you don't know where one of your users will be when they try to access their e-mail. If you are able to use https either from a self-signed certificate generated on the Exchange server itself or by purchasing a third party digital certificate from a place like Verisign, then you only need the following line in your ACL applied to the outside interface:

access-list INET permit tcp any host x.y.163.2 eq https

I really, really, really recommend that you do this since using only http for OWA means that your users will be sending their login credentials in clear text across the Internet when they access their e-mail! Not good...

2) Since your Exchange server is on your internal network (i.e. your most protected network segment), you are opening up a pinhole in your firewall that can potentially lead to a compromise of a server on your most protected network. It's considered industry best security practice to set up a DMZ network if you want to advertise public services to the world. I know that this is more of a long term proposition, but I thought that I would mention it. Just consider it for now.

A classic deployment of OWA is to have two servers, one in a DMZ network to act as a front-end server and one on your internal network to act as the back-end server. The front-end server would have access opened up to it through the firewall for Internet user access. This server would not have any mailboxes loaded on it...it would only be a proxying requests inbound to the real back-end Exchange server that does contain the user mailboxes. You would only open up https to the front-end server from the Internet, and then a few other ports from the front-end server to the back-end server for authentication, directory services, etc. In this way, if someone on the Internet compromises the front-end server, any traffic coming from that server trying to compromise internal devices still has to pass through the firewall again. In your existing configuration, someone could compromise your Exchange server and they will then have access to a box on your internal network!

Anyway, I know this is getting off topic, but I thought I would recommend a tighter security posture for your firewall configuration.

3) I also noticed that you have the following two lines in your inbound ACL:

access-list INET permit tcp any host x.y.163.10 eq https
access-list INET permit tcp any host x.y.163.10 eq www

If we can assume this is meant to allow OWA traffic inbound, then you need to use the following static statement to make those two ACL statements function properly:

static (inside,outside) x.y.163.10 192.168.0.10 netmask 255.255.255.255 0 0

However, as I mentioned above, you don't really need both ACL statements. Just one or the other, and I would recommend you use https for reasons stated above.

If there is a single point I would like for you to get from this response, it's this: Never allow unencrypted traffic from anywhere on the Internet (without you being able to filter on source IP addressing) to an internal network resource.

Hope this helps!

mooreshelby

ASKER

After reviewing this I have to agree with billwharton that the information I was given was incorrect and that the ouside address I want is the x.y.163.15 not x.y.163.2 as I was told, it looks to me as if the x.y.163.2 is now configured for our VPN. But I digress, back to the problem.

So as I said being PIX stupid I logged in typed enable and my password, tried to type:

no static (inside,outside) x.y.163.15 192.168.0.15 netmask 255.255.255.255 0 0

It returns:

PIX# no static (inside,outside) x.y.163.15 192.168.0.15 netmask 255.255$
Type help or '?' for a list of available commands.

So were and how am I suppose to type these commands. Please hold my hand as much as possible. Thanks again, I really think you two are on the right track with this.

billwharton

At the PIX# prompt, you have to first type 'configure t' to get into configuration mode

Once you are done with the configuration, type Ctrl -Z to get back to the PIX# prompt and do a 'write memory' to write the config to flash

mooreshelby

ASKER

billwharton you are fast....ok I was able to make the changes and when I do a sh run or sh config I see them. But it still seems to be routing to the old server. Do I have to reboot the PIX for the changes to take effect? If I do need to reboot, is this something that should be done after hours? I don't want all the users calling saying a messed something up. LOL

Thanks again.

billwharton

A reboot isn't required. How did you test out that it's still routing to the old server?

Did you add the new static and access list changes?

mooreshelby

ASKER

To test I remote desktoped to my home machine, then from it went to the outside ip address, that way I am accessing from an outside pc. When I do this I get the a test webpage I set up that says old server. I did that show I would know what server I was hitting. (My goal is to get the www working first, then go to https like batry suggested.)

I did not change the access list as they were already for the x.y.163.15. So currently it looks like this:

static (inside,outside) x.y.163.15 192.168.0.10 netmask 255.255.255.255 0 0

access-list INET permit tcp any host x.y.163.15 eq www
access-list INET permit tcp any host x.y.163.15 eq https

So what am I missing?

mooreshelby

ASKER

Looks like it may be working now, just took some time.....please allow me a little more time to test, and if all it good you will get those points. Way cool!

mooreshelby

ASKER

OK BIG PROBLEM, soon as the change took effect now it seems our DNS resolution now doesn't work from the inside.....Why would the change effect this? So if I type www.google.com I get nothing, but if I use there IP everything is good. ARUGH! I just love screwing up. THANKS

billwharton

I see two statements set up on your PIX which seem to show that your OWA server was also your DNS server
vpngroup MYVPN dns-server 192.168.0.15
vpngroup MYVPN wins-server 192.168.0.15

Find out what your internal clients are using for their internal server going to network properties

mooreshelby

ASKER

Yes that is correct the the 192.168.0.15 is the DNS server and all internal clients are set to it. So what I don't understand is I thought we were only playing with external routing, why did it break this and how do I fix it. THANKS!!!

billwharton

Because you removed a staticand without a static entry, 192.168.0.15 cannot get to the outside. I presumed 192.168.0.15 is out of production but it seems you are going to continue using it as a DNS server

Now we have to add a static entry for 192.168.0.15. I think your public IP x.x.x.14 is free since it doesn't appear in the configuration. Do this

configure t
static (inside,outside) x.y.163.14 192.168.0.15 netmask 255.255.255.255 0 0

That should help out

mooreshelby

ASKER

Yest 192.168.0.15 is still going to the DNS, we just moved exchange off it. I have made the change, no lets wait and see what happens. What you said makes sense. Will let you know. Thanks,

Shelby

mooreshelby

ASKER

The single entry does not seem have to have fixed it. Do I need to add a:

access-list INET permit tcp any host x.y.163.14 eq www

or is there an entry for DNS traffic?? Thanks,

Shelby

billwharton

Nopes you don't need that. Try using another public IP in the static statement like x.x.x.11
Before that you'll have to remove the static staement you put in before

mooreshelby

ASKER

I tried x.x.x.11 and x.x.x.9 and still no luck. Who new this could be so complicated. ARUGH! Any other ideas?

Thanks.

Keith Alabaster

Can you please repost your configuration so I can see it cleanly?

Thanks
keith

mooreshelby

ASKER

OK I am going to mark this as answered as billwharton's answers are correct, it just messes up a ton of stuff for me, which is not his fault, just my crazy settings. I am then going to try and reconfigure a couple things and if I still have problems I will post another question. Thanks all for who responded I have learned a ton!!!

Thanks,

Shelby

billwharton

Shelby

If you are going to do more of PIX firewall administration, you should read this guide. These are the first pages I read on th e PIX years ago and Peter does a fantastic job of explanining this in a simple manner
http://www.netcraftsmen.net/welcher/papers/pix01.html