Using PIX 501 inside to isolate segment & still allow them Internet??

[ixleplix]

This is the network layout
10.40.1.0/24 <-------> Switch <------->(outside interface) PIX 501 (inside interface) <-------> 172.21.0.0/16 <-------> Switch <-------> Router <-------> (inside interface) PIX 515 (outside interface) <-------> Internet.

What we are trying to do is allow only WWW, FTP, DNS, SMTP, & POP3 traffic through from the 10.40.1.0/24 network. This traffic then will then go to the internet or the mail server and back.

If I set the Default Gateway of the machines on the 10.40.1.0/24 network to 10.40.1.1 (PIX 501 Outside Interface), open the appropriate ports with an ACL, & set a static route so anything comming in on 10.40.1.1 goes to the DG of the 172.21.0.0/16 network, then it (I thought) should work. However, I can ping the PIX 501 from the 10.40.1.0/24 network but nothing seems to be comming through the PIX.

Is this scenario even possible?

I can turn the PIX 501 around and block the outbound traffic with an ACL, but this makes remote management of the device a pain and just doesn't feel as secure. Also the segment we are trying to isolate is a seperate company (renting space from us) so I really want them on the outside of the firewall.

I know my routes are correct because I can ping the PIX 515 from the command line of the PIX 501 & all of the PC's on the 172.21.0.0/16 network can access the Internet.

Here is the config.

nameif ethernet0 outside security0
nameif ethernet1 inside security100
enable password **************** encrypted
passwd **************** encrypted
hostname PIX-CON
domain-name my.domain.name
fixup protocol ftp 21
fixup protocol http 80
fixup protocol h323 h225 1720
fixup protocol h323 ras 1718-1719
fixup protocol ils 389
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 100 permit icmp any any echo-reply
access-list 100 permit icmp any any time-exceeded
access-list 100 permit icmp any any unreachable
access-list 100 permit tcp any host 10.40.1.1 eq www
access-list 100 permit tcp any host 10.40.1.1 eq smtp
access-list 100 permit tcp any host 10.40.1.1 eq pop3
access-list 100 permit tcp any host 10.40.1.1 eq ftp
access-list 100 permit udp any host 10.40.1.1 eq domain
pager lines 24
interface ethernet0 10baset
interface ethernet1 10full
mtu outside 1500
mtu inside 1500
ip address outside 10.40.1.1 255.255.255.0
ip address inside 172.21.2.245 255.255.0.0
ip audit info action alarm
ip audit attack action alarm
pdm logging informational 100
pdm history enable
arp timeout 14400
global (outside) 1 interface
nat (inside) 1 0.0.0.0 0.0.0.0 0 0
static (inside,outside) 10.40.1.1 172.21.1.106 netmask 255.255.255.255 0 0
access-group 100 in interface outside
route inside 0.0.0.0 0.0.0.0 172.21.1.106 1
timeout xlate 0:05: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
aaa-server LOCAL protocol local
no snmp-server location
no snmp-server contact
snmp-server community public
no snmp-server enable traps
floodguard enable
telnet x.x.x.x x.x.x.x inside
telnet timeout 60
ssh timeout 5
terminal width 80
Cryptochecksum:*********************************************
PIX-CON#

 

[themut]

I don´t know if this is too late but here are my two cents...

The scenario you are describing will not work because you would need to statically transalte the whole Internet on the 501 and permit all WWW, FTP, DNS, SMTP, & POP3 traffic from the 10.40.1.0/24 network to any.

A workaround could be installing a proxy server on the 172.21.0.0/16 network and proxy the 10.40.1.0/24 users to the Internet.

If you turn around the 501 then it should work fine. Hope this helps!

 

[ixleplix]

Thanks themut,
I suspected as much, but we wanted to give it a try.
I've been trying to work with Cisco TAC on this one for a week and a half, it's been three days since I've heard anything from them. So for the record, your response was not to late and was more insightful than anything TAC has offered so far.