Cisco Pix 506 allow inbound www, pop3 and imap from specific hosts

Let's say that the Exchange server has an inside address of 192.168.1.100 and an external address of eip.eip.eip.eip netmask of 255.255.255.0; and the web server has an inside address of 192.168.1.200 and an external address of wip.wip.wip.wip netmask of 255.255.255.0.  You would need the following statements

! The following let's everyone send email to your Exchange server
access-list outside-acl permit tcp any host eip.eip.eip.eip eq smtp

! Do the following 3 statements for each external ip address (sip.sip.sip.sip) you want to restrict
access-list outside-acl permit tcp host sip.sip.sip.sip host eip.eip.eip.eip eq pop3
access-list outside-acl permit tcp host sip.sip.sip.sip host eip.eip.eip.eip eq imap
access-list outside-acl permit tcp host sip.sip.sip.sip host wip.wip.wip.wip eq www

! The following 2 statements map the outside addressess to the inside addresses
static (inside,outside) eip.eip.eip.eip 192.168.1.100 255.255.255.255 0 0
static (inside,outside) wip.wip.wip.wip 192.168.1.200 255.255.255.255 0 0

! The following enables the access-list
access-group outside-acl in interface outside

There is another variant of the static statement that does port forwarding, but if the above scenario fits your situation, I think it's cleaner that port forwarding.

Just to keep you informed, I have tried the above without any joy.
td_miles:  Tried, but no different.
Quetzal:  Pretty much what I have (I think)

I would still like the static bit explained.  What does the external address refer to.  In my config I have:
static (inside,outside) 192.168.10.10 192.168.0.1 netmask 255.255.255.255 0 0

Obviously 192.168.10.10 isn't my public IP Address, it isnt the default route either as later on in the config I have:
route outside 0.0.0.0 0.0.0.0 192.168.10.254 1

It isn't either of the interface ips:
ip address outside 192.168.10.1 255.255.255.0
ip address inside 192.168.0.254 255.255.255.0

I can't ping it from the pix using
ping ethernet0 192.168.10.10

I am missing the point here.  Should the external apply to my public IP or the ethernet0 address or the default route

There is another router in the way that isnt under my control, so I am checking that it isnt blocking the ports.

Thank-you

Increased points to 500

Bit of a cliche, but instructions are here !

http://www.cisco.com/en/US/products/hw/vpndevc/ps2030/products_tech_note09186a0080094aad.shtml

If you get stuck, post up your config - just use x.x.x.x for external, i.i.i.i for internal etc etc.  Using made up IP addresses will only to serve to confuse us further !

Thanks for posting the article.  I find the Cisco site a pig to navigate.
You'll probably spit at me but I'm more of an Microsoft man and normally do ISA Server.  But I've had to tackle this box for a client.

I'll have a read and test it out, but I'm leaning towards the fact that I did it right in the first place but the router behind me is blocking.

Thanks
Mark

It doesn't take long to verify the config - post it up and we'll tell you if there's a problem with it.  Should help point you in the right direction if indeed you think the router is at fault ?

Tim,
Config of router prior to me doing anything, with no replacement of IP Addresses:

PIX Version 6.1(2)
nameif ethernet0 outside security0
nameif ethernet1 inside security100
enable password xxxxxxxxxxxxxxxx encrypted
passwd xxxxxxxxxxxxxxxx encrypted
hostname xxxxxx
fixup protocol ftp 21
fixup protocol http 80
fixup protocol h323 1720
fixup protocol rsh 514
fixup protocol rtsp 554
fixup protocol smtp 25
fixup protocol sqlnet 1521
fixup protocol sip 5060
fixup protocol skinny 2000
names
access-list outside_acl permit tcp any host 192.168.10.10 eq smtp
access-list insidenet permit tcp 192.168.0.0 255.255.255.0 any eq www
access-list insidenet permit tcp 192.168.0.0 255.255.255.0 any eq 443
access-list insidenet permit tcp 192.168.0.0 255.255.255.0 any eq domain
access-list insidenet permit udp 192.168.0.0 255.255.255.0 any eq domain
access-list insidenet permit tcp 192.168.0.0 255.255.255.0 any eq ftp-data
access-list insidenet permit tcp 192.168.0.0 255.255.255.0 any eq ftp
access-list insidenet permit tcp 192.168.0.0 255.255.255.0 any eq smtp
access-list insidenet permit tcp 192.168.0.0 255.255.255.0 any eq pop3
access-list insidenet permit tcp 192.168.0.0 255.255.255.0 any eq 554
access-list insidenet permit tcp 192.168.0.0 255.255.255.0 any eq 2517
access-list insidenet permit tcp 192.168.0.0 255.255.255.0 any eq nntp
access-list insidenet permit tcp 192.168.0.0 255.255.255.0 any eq telnet
access-list insidenet permit tcp 192.168.0.0 255.255.255.0 any eq 904
pager lines 24
logging on
logging timestamp
logging buffered debugging
logging trap debugging
interface ethernet0 10baset
interface ethernet1 10baset
mtu outside 1500
mtu inside 1500
ip address outside 192.168.10.1 255.255.255.0
ip address inside 192.168.0.254 255.255.255.0
ip audit info action alarm
ip audit attack action alarm
pdm history enable
arp timeout 14400
global (outside) 1 192.168.10.2
nat (inside) 1 192.168.0.0 255.255.255.0 0 0
static (inside,outside) 192.168.10.10 192.168.0.1 netmask 255.255.255.255 0 0
access-group outside_acl in interface outside
access-group insidenet in interface inside
route outside 0.0.0.0 0.0.0.0 192.168.10.254 1
timeout xlate 3:00:00
timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 rpc 0:10:00 h323 0:05:00 si
p 0:30:00 sip_media 0:02:00
timeout uauth 0:05:00 absolute
aaa-server TACACS+ protocol tacacs+
aaa-server RADIUS protocol radius
no snmp-server location
no snmp-server contact
snmp-server community public
no snmp-server enable traps
floodguard enable
no sysopt route dnat
telnet 192.168.0.1 255.255.255.255 inside
telnet 192.168.0.2 255.255.255.255 inside
telnet 192.168.0.3 255.255.255.255 inside
telnet timeout 5
ssh timeout 5
terminal width 80

All looks fine...  I would double check your interfaces are up properly though - do a 'sh int'
If necessary, set to auto, eg:

interface ethernet0 auto

Tim,
I have still to add the explicit rules for allowing inbound access from certain IP addresses to functions as mentioned I would have added:
access-list outside_acl permit tcp host x.x.x.x host 192.168.10.10 eq www
access-list outside_acl permit tcp host x.x.x.x host 192.168.10.10 eq pop3
access-list outside_acl permit tcp host x.x.x.x host 192.168.10.10 eq imap

Where x.x.x.x is the IP Address I wanted to explicitly allow in on specific ports.
As mentioned I have tried this without success.  Although one quick question (As I know f all about Cisco) is that I make the changes, then I do a:
write mem
Is this all I need to do, to make sure its an active config?

Config is active with immediate effect.  Write mem just saves it to flash, so that you don't lose changes when you reboot.

Yes - you do need to allow explicit rules to allow inbound access.

What sort of access are you giving these clients to Exchange ?
If you need to use the full-blown Outlook 2000 client, then you're going to need to open more ports to enable full functionality.  A full list of the ports Exchange 2000 will use:

http://support.microsoft.com/?scid=kb;en-us;Q278339

hopefully you don't need to use all these features... !

A couple of comments/questions:

WRT the upstream router:  Is it NATing the public ip addresses for your Exchange and web servers?  Or is it simply routing the public ip's to the Pix?  This will make a significant difference in configuration.  Personally, if I have the choice, I prefer to have the public ip's routed as the Pix can be somewhat picky in handling NATed addresses, particularly with VPNs.

WRT the insidenet ACLs: I'm not sure that I see the point in doing this.  Could you briefly elaborate on what you are trying to achieve?  If you Exchange and web servers are  on the inside network, these are not needed.  As configured, no one on the outside network (or beyond) can do pop3 or imap on your Exchange server or access your web server.  The default state of the Pix is to allow inside users to do whatever they want to the outside network and to block everything coming from the outside network to the inside.

WRT the ACLs for ftp-data and ftp:  If you have set up an ftp server to which you want to allow external access, you only need to do an ftp ACL (would also have to create the ACL for the outside network) as stateful packet inspection should permit the rest of the ftp protocol as needed.

WRT the ACLs for domain:  Unless you're trying to publish your internal DNS, these are not necessary.

WRT the ACL for 443: Are you trying to use OWA?

WRT the ACsL for 904 and 2517:  Can you say what these are for?

WRT the ACsL for 554, nntp, smtp, telnet: If you are tyring to allow streaming, usenet news, access to outside email servers, and the aiblity to telnet  from the inside network, these are  not necessary.


Let me recap my understanding of the original question in case it is incorrect:  You have an Exchange server and a web server on your internal network (i.e. on the inside address of the Pix or beyond).  You want a couple specific addresses (not sure if specific addresses or subnets) to be able to do pop3 and imap to the Exchange server and to access your web server; all others should be blocked.  You also want your Exchange server to be able to receive mail from anyone.

If that understanding is correct, then I think your config needs to be modified.  Specifically, dump the insidenet ACLs and do something along the lines as what I originally suggested.  I know you ran into problems trying this before, but perhaps we can review the revised config here to make sure I communicated the original suggestion correctly.

WRT the static command.  The variant I've suggested using simply maps an outside address to an address on your inside network.  In your case, the fact that your outside address for the Exchange server is a non-routable ip address suggests that the upstream router is NATing the actual public ip address.  If so, that's okay, we can make that work.  Your current static command says that (from the viewpoint of the Pix) anything directed toward 192.168.10.10 should be routed to 192.168.0.1.

WRT being able to ping the server:  By default the Pix blocks all outside traffic coming in, including ICMP.  In your config, you've complicated the situation a little by the ACLs on the side network, in effect blocking all traffic from the inside network except what you have permitted.  Try this:

Get rid of the insidenet ACLs and remove the access-group to the inside.  Add the following

access-list outside_acl permit icmp any any

Then put a machine on the 192.168.10.0 network (on the outside of the Pix) and see if you can ping 192.168.10.10.  If that is successful, then try to ping the (real) public ip address of the server from outside of the upstream router.  If that works, we are well on the way to solving your problem; if not, then the upstream router is definitely complicating the problem

One last thing about your Exchange server.  Once your Pix config is working, you will need to run a test to verify what public ip address Exchange appears to be using.  Then you will need to make sure that a reverse DNS address exists to resolve that address to the name your Exchange server is advertising.

The upstream router is a Cisco ADSL Router provided by my ISP.  This has a static public IP Address which is NAT'd through.

All I want to do in addition is for certain external IP Address to be able to get to the Exchange server for email, either by POP3, IMAP or Outlook Web Access.

I didn't write the initial config. I've just inherited the issue, so I wouldnt want to play with the config too much.
I thought that the insidenet ACLs were specifying what clients on the internal network could do.

I can currently ping the public IP Address and get through to the Exchange Server on SMTP

As mentioned before I am waiting on someone else to get me access to the upstream router so I can verify if its blocking everything but ICMP and SMTP

If the upstream router is provided by your ISP, they don't usually block any traffic of any kind unless you specfically ask them to do so.  If they are blocking, then you will need to ask them to pass pop3, imap, and ports for OWA (see below).  I doubt that the ISP will let you have access to the upstream router unless you own it.

If you can ping the public ip address, that's good.  You should have needed to add the ACL for icmp to do this, was that the case?

OWA presents another set of issues.  Am I right to assume that you've not had this deployed before?  I *highly* recommend that you consider *not* opening the HTTP ports and only allow HTTPS access.  By opening HTTP you could be asking for a host of IIS issues that you don't want.

WRT the insidenet ACLs:  If they are working the way you want, then let sleeping dogs lie.  But I would at least ask the question, "what are inside users not allowed to do".

One other q: For OWA, are you running IIS on the Exchange server or another server?

The person who owns the Pix is asking for ownership of the router from the ISP.
Once they have that I will be able to look at it to see if its blocking or not.  No-one remembers if they had asked the ISP to put blocking in place.

As far as the OWA is concerned this is just for a couple of fixed IP addresses to be able to check there mail.  Its not going to be open to anyone.  IIS is on the Exchange server and OWA is up and running.  I don't really want to seperate off on to a different front-end server as this is meant to be a simple solution for two people to be able to check their mail remotely.  I do see your point about secure access but the person who I am doing this for is happy to have it limited to just two IP addresses and they have been made aware of the security issues.

Here is the issue with our OWA situation as I see it.  Unless the 2 people who want to check remotely are doing so from fixed public ip addresses (or fixed ip subnets), you're going to have to allow access to OWA from any outside address.  It is this open access that can get you into trouble with IIS.  Setting OWA up for HTTPS access only is not all that hard, but it's not trivial either.  Your users would only need to remember to type https://<webmail address>.

Yeah they will be fixed IP addresses, thats why I'm not too bothered.
From my limited knowledge of https doesnt the company have to buy a certificate?

If my assertion about your remote users is correct then I think that all you need to add to your config are the following:

access-list outside_acl permit tcp any host 192.168.10.10 eq www
access-list outside_acl permit tcp any host 192.168.10.10 eq pop3
access-list outside_acl permit tcp any host 192.168.10.10 eq imap

Wouldn't that allow any host in?
As mentioned in the question I have already tried

access-list outside_acl permit tcp host x.x.x.x host 192.168.10.10 eq www
access-list outside_acl permit tcp host x.x.x.x host 192.168.10.10 eq pop3
access-list outside_acl permit tcp host x.x.x.x host 192.168.10.10 eq imap

But it didn't work.  Thats why I'm getting the details for the upstream router so I can check its configuration.

If one of your users were coming from a fixed ip address of 68.221.49.8 (as an example), you could allow that specifc address to access Exchange and OWA with the following:

access-list outside_acl permit tcp host 68.221.49.8 host 192.168.10.10 eq www
access-list outside_acl permit tcp host 68.221.49.8 host 192.168.10.10 eq pop3
access-list outside_acl permit tcp host 68.221.49.8 host 192.168.10.10 eq imap

And you could make such entries for each user who is coming from a fixed ip address.

However, if your users are using dhcp to connect to the Internet (such as through dialup or home computers), then you have to use the keyword 'any' in place of 'host 68.221.49.8'.

One last thought....if these users are trying to connect from home or other fixed locations, you could consider using a VPN router on the other end and setting up a VPN tunnel with your pix.  This would allow your remote users to appear as though they were on the local LAN.  I use a Linksys BEFVP41 between my home office and my workplace in just this fashion.

As mentioned earlier they are fixed ip addresses.
I had thought about the VPN tunnel, but I was on the understanding that Cisco VPN wasn't free and that you had to pay for the licensing.  Unlike Microsoft VPN which is free.  So we decided on just restricting to the fixed ip addressing as the most cost effective solution without compromising security too much.

As per the question and several comments since I have already tried:
access-list outside_acl permit tcp host x.x.x.x host 192.168.10.10 eq www
access-list outside_acl permit tcp host x.x.x.x host 192.168.10.10 eq pop3

Where x.x.x.x represents the specific host I want through, and yes, they are using a public fixed IP Address.

I believe the fault lies with the upstream router, but until I can get into it, I can't verify that.  As soon as I know wether that is the source of the problem I will post back.

Thanks
Mark

As mentioned on my first reply to td_miles I did try the any on the www, it didn't change anything, so I took it off quickly.
Thanks
Mark