Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
New Member

Strange PIX behavior - can't access all protocols from high to low security

I have a 515 with four active interfaces (three hardware and one VLAN). I have a DMZ interface with security level set to 6. From the inside network (security 100) I can only access hosts on the DMZ using the HTTP protocol. Ping and telnet do not work while they do work when I am connected directly to the DMZ network. The DMZ network is flat and all hosts have the PIX as their DGW. Below is a copy of the current config. Am I missing something? This should not be that hard!

Thanks

PIX Version 6.3(4)

interface ethernet0 auto

interface ethernet1 100full

interface ethernet1 vlan11 logical

interface ethernet2 100full

nameif ethernet0 outside security0

nameif ethernet1 inside security100

nameif ethernet2 grandhome security6

nameif vlan11 guest security99

hostname DBADAPIX

clock timezone EST -5

clock summer-time EDT recurring

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

name xx.xx.167.101 QualityAirPC_OUTSIDE

name 192.168.100.90 QualityAirPC

access-list rdvvpn permit ip 172.18.34.0 255.255.255.0 192.168.1.0 255.255.255.0

access-list nonat permit ip 172.18.34.0 255.255.255.0 192.168.1.0 255.255.255.0

access-list outside_access_in permit tcp any host QualityAirPC_OUTSIDE eq https

pager lines 24

logging on

logging timestamp

logging buffered debugging

logging trap errors

icmp permit any outside

icmp permit any inside

mtu outside 1500

mtu inside 1500

mtu grandhome 1500

ip address outside xx.xx.167.97 255.255.255.248

ip address inside 172.18.34.1 255.255.255.0

ip address grandhome 192.168.100.1 255.255.255.0

ip address guest 192.168.10.1 255.255.255.0

ip audit info action alarm

ip audit attack action alarm

arp timeout 14400

global (outside) 1 interface

global (grandhome) 1 interface

nat (inside) 0 access-list nonat

nat (inside) 1 172.18.34.0 255.255.255.0 0 0

nat (grandhome) 1 192.168.100.0 255.255.255.0 0 0

nat (guest) 1 192.168.10.0 255.255.255.0 0 0

static (grandhome,outside) QualityAirPC_OUTSIDE QualityAirPC netmask 255.255.255.255 0 0

access-group outside_access_in in interface outside

route outside 0.0.0.0 0.0.0.0 xx.xx.167.102 1

floodguard enable

sysopt connection permit-ipsec

crypto ipsec transform-set rdvvpnset esp-des esp-md5-hmac

crypto ipsec transform-set ESP-DES-SHA esp-des esp-sha-hmac

crypto map rdvvpnmap 10 ipsec-isakmp

crypto map rdvvpnmap 10 match address rdvvpn

crypto map rdvvpnmap 10 set peer xx.xx.71.66

crypto map rdvvpnmap 10 set transform-set ESP-DES-SHA

crypto map rdvvpnmap 10 set security-association lifetime seconds 43200 kilobytes 4608000

crypto map rdvvpnmap interface outside

isakmp enable outside

isakmp key ******** address xx.xx.71.66 netmask 255.255.255.255

isakmp identity address

isakmp policy 10 authentication pre-share

isakmp policy 10 encryption des

isakmp policy 10 hash md5

isakmp policy 10 group 1

isakmp policy 10 lifetime 86400

dhcpd address 172.18.34.100-172.18.34.199 inside

dhcpd address 192.168.100.100-192.168.100.109 grandhome

dhcpd address 192.168.10.100-192.168.10.199 guest

dhcpd dns 64.x.37.x.39.140.42

dhcpd lease 3600

dhcpd ping_timeout 750

dhcpd auto_config outside

dhcpd enable inside

dhcpd enable grandhome

dhcpd enable guest

1 ACCEPTED SOLUTION

Accepted Solutions
Silver

Re: Strange PIX behavior - can't access all protocols from high

to allow the pings to come back you need to allow the traffic. it is not allowed by default.

apply this acl to the dmz interface in.

access-list dmz->in permit icmp any any echo-reply

access-list dmz->in permit icmp any any time-exceeded

access-list dmz->in permit icmp any any unreachable

If your trying to ping the dmz interface from the inside you can't. Telneting to that interface isn't allowed either unless through an ipsec tunnel. You should be able to telnet to a server in the dmz with no problem.

5 REPLIES
Silver

Re: Strange PIX behavior - can't access all protocols from high

to allow the pings to come back you need to allow the traffic. it is not allowed by default.

apply this acl to the dmz interface in.

access-list dmz->in permit icmp any any echo-reply

access-list dmz->in permit icmp any any time-exceeded

access-list dmz->in permit icmp any any unreachable

If your trying to ping the dmz interface from the inside you can't. Telneting to that interface isn't allowed either unless through an ipsec tunnel. You should be able to telnet to a server in the dmz with no problem.

Re: Strange PIX behavior - can't access all protocols from high

Is this a typo?

access-list nonat permit ip 172.18.34.0 255.255.255.0 192.168.1.0 255.255.255.0 --> shouldn't it be 192.168.100.0 instead of 192.168.1.0

I assume you want to do nonat for traffic from inside to DMZ and if it is, then correct the ACL and let us know if it helps.

HTH

Sundar

New Member

Re: Strange PIX behavior - can't access all protocols from high

No, that access list is for a VPN that I have on this PIX that is not included in the config I posted because I ran out of space! I just left the relavant parts.

mb

Re: Strange PIX behavior - can't access all protocols from high

Can you add this static command to the configuration. This would cause the inside hosts to access the DMZ with their own addresses.

static (inside,grandhome) 172.18.34.0 172.18.34.0 netmask 255.255.255.0

New Member

Re: Strange PIX behavior - can't access all protocols from high

This was it. I didn't think this was needed but obviously it is.

Thanks for your help.

115
Views
0
Helpful
5
Replies
CreatePlease to create content