Allowing outside subnet through PIX

[Rravelidc27]

Hi,

I currently am trying to setup a 501 PIX 6.3(5) to have it allow any data from subnet 192.168.32.0 255.255.255.0 through from the outside in to any subnet. Is there a way to do that? I've been working on this for a few weeks now and can't seem to figure it out. Any help would be appreciated thanks.

[Richard Burts]

David

Part of the security behavior of the PIX is to not allow devices outside to initiate traffic to devices inside unless that traffic is specifically allowed. So you should have an access list on the outside interface that permits the traffic from outside to inside.

Another thing that can impact traffic being initiated from outside to inside is the question of address translation. Does your network environment use private addressing on the inside subnet as is usually the case? If so what are you doing for address translation on the PIX? The fundamental question here is what address does the outside device use to try to get to the inside device and does the PIX have a translation configured for that address?

If you would post the config from the PIX it would help us to figure out these things.

HTH

Rick

[lamav]

You also want to check if the routing is in place on the PIX. These are the 3 things you should check when you have a suspected FW problem: NATing, ACLs and routing.

[Rravelidc27]

PIX Version 6.3(5)
interface ethernet0 auto
interface ethernet1 100full
nameif ethernet0 outside security0
nameif ethernet1 inside security100
enable password xxxencrypted
passwd xxx encrypted
hostname Firewall

domain-name domain.name

fixup protocol dns maximum-length 512
fixup protocol ftp 21
fixup protocol h323 h225 1720
fixup protocol h323 ras 1718-1719
fixup protocol http 80
fixup protocol rsh 514
fixup protocol rtsp 554
fixup protocol sip 5060
fixup protocol sip udp 5060
fixup protocol skinny 2000
fixup protocol smtp 25
fixup protocol sqlnet 1521
fixup protocol tftp 69
names
access-list outside-acl permit icmp any any
access-list outside-acl permit tcp 192.168.1.0 255.255.255.0 192.168.2.0 255.255.255.0
access-list outside-acl permit tcp any any eq ssh
access-list no_nat permit ip 192.168.1.0 255.255.255.0 192.168.2.0 255.255.255.0
access-list no_nat permit ip 192.168.2.0 255.255.255.0 192.168.1.0 255.255.255.0
pager lines 24
mtu outside 1467
mtu inside 1467
ip address outside dhcp setroute
ip address inside 192.168.1.1 255.255.255.0
ip audit info action alarm
ip audit attack action alarm
ip local pool testpool 192.168.2.60-192.168.2.69 mask 255.255.255.0
pdm history enable
arp timeout 14400
global (outside) 1 interface
nat (inside) 0 access-list no_nat
nat (inside) 1 192.168.1.0 255.255.255.0 0 0
access-group outside-acl in interface outside
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 sip-disconnect 0:02:00 sip-invite 0:03:00
timeout uauth 0:05:00 absolute
aaa-server TACACS+ protocol tacacs+
aaa-server TACACS+ max-failed-attempts 3
aaa-server TACACS+ deadtime 10
aaa-server RADIUS protocol radius
aaa-server RADIUS max-failed-attempts 3
aaa-server RADIUS deadtime 10
aaa-server LOCAL protocol local
aaa authentication ssh console LOCAL
aaa authentication telnet console LOCAL
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 myset esp-3des esp-md5-hmac
crypto dynamic-map dynmap 1 set transform-set myset
crypto map mymap 10 ipsec-isakmp dynamic dynmap
crypto map mymap interface outside
isakmp enable outside
isakmp identity address
isakmp policy 10 authentication pre-share
isakmp policy 10 encryption 3des
isakmp policy 10 hash md5
isakmp policy 10 group 2
isakmp policy 10 lifetime 86400
vpngroup test address-pool testpool

vpngroup test default-domain domain.name

vpngroup test split-tunnel no_nat
vpngroup test idle-time 1800
vpngroup test password ********
telnet timeout 5
ssh 0.0.0.0 0.0.0.0 outside
ssh 192.168.0.0 255.255.255.0 inside
ssh timeout 60
console timeout 0
dhcpd address 192.168.1.60-192.168.1.69 inside
dhcpd lease 3600
dhcpd ping_timeout 750
dhcpd auto_config outside
dhcpd enable inside
username test password xxx encrypted privilege 15
terminal width 80
Cryptochecksum:xxx

: end

The main use I have for this router is VPN. Right now I have it behind a Linksys router. I basically want it to allow 192.168.1.0 192.168.2.0 192.168.32.0 subnets full access to eachother. I don't think that 192.168.2.0 has access to 192.168.1.0 either, but I can worry about that later I want at least 192.168.32.0 to have access in at this point.Anyway, thank you for the help so far.    

[Richard Burts]

David

Thank you for posting the config. There are a couple of things in it that puzzle me. Perhaps you can clarify them:

- it appears that the PIX is configured to do remote access VPN (individual users with VPN client on their PC) and not to do site to site VPN. Is this correct?

- it the remote access VPN working? (can users connect to the PIX VPN using their client software)

- you say that one objective is to allow access to inside from 192.168.32. Is this a network somewhere outside of the PIX?

- there is no entry in the outside-acl which permits 192.168.32. So as it stands that network would only be able to do icmp and ssh to inside. I believe that you need a statement in the acl to permit its traffic.

- what address will be used by 192.168.32 when they attempt to access addresses on the inside? As currently configured all traffic from 192.168.1 is dynamically translated (unless it is traffic from 192.168.1 to 192.168.2). So 192.168.1 is not visible outside of the PIX. If 192.168.32 is to initiate traffic to inside then there needs to be some static address translation which provides an address that 192.168.32 can use which will get it to the 192.168.1 network.

- I believe that this line in your access list is incorrect:

access-list outside-acl permit tcp 192.168.1.0 255.255.255.0 192.168.2.0 255.255.255.0

Since the 192.168.1 network is the inside network why is it listed as the source address of something coming in on the outside interface?

HTH

Rick

[Rravelidc27]

- it appears that the PIX is configured to do remote access VPN (individual users with VPN client on their PC) and not to do site to site VPN. Is this correct?

I would prefer to have users instead of site to site yes.

- it the remote access VPN working? (can users connect to the PIX VPN using their client software)

I can connect using a vpngroup, although I'd prefer to just use LOCAL authentication. unfortunately I can't remember the aaa authentication command to achieve this.

- you say that one objective is to allow access to inside from 192.168.32. Is this a network somewhere outside of the PIX?

192.168.32 is an ip right outside my PIX. My topology is Internet > Router 192.168.32 > PIX 192.168.1, 192.168.2

I may eventually put the PIX in front, but as for now since I'm not that well versed in IOS and PIX settings, I'll probably wait and have it behind so as to not mess with any applications in my 192.168.32 subnet.

- there is no entry in the outside-acl which permits 192.168.32. So as it stands that network would only be able to do icmp and ssh to inside. I believe that you need a statement in the acl to permit its traffic.

I have had the 192.168.32 in my outside acl, but that tends to shut down the 192.168.1 and 192.168.2 networks so they can't hit anything outside the PIX, although, I may have had it set wrong or missing a setting.

- what address will be used by 192.168.32 when they attempt to access addresses on the inside? As currently configured all traffic from 192.168.1 is dynamically translated (unless it is traffic from 192.168.1 to 192.168.2). So 192.168.1 is not visible outside of the PIX. If 192.168.32 is to initiate traffic to inside then there needs to be some static address translation which provides an address that 192.168.32 can use which will get it to the 192.168.1 network.

well I would, if in any way possible, like to allow all of the 192.168.32 subnet to access the 192.168.1 and 192.168.2 subnets. There will probably be

quite a few IP addresses in 192.168.32 that will need access to 192.168.1 and 192.168.2

- I believe that this line in your access list is incorrect:

access-list outside-acl permit tcp 192.168.1.0 255.255.255.0 192.168.2.0 255.255.255.0

You're probably right, but I thought I'd give that a try to get the 192.168.1 and 192.168.2 subnets to communicate with each other. If you have any idea how i can get that to work too that would be great.

Since the 192.168.1 network is the inside network why is it listed as the source address of something coming in on the outside interface?