Cisco PIX 506E - A config that seems to be wrong somewhere 3

[CertifiedNut]

Hi All,

I'm back with another problem with the PIX. I have moved my 506e from our live environment to our development network. Seemed simple enough, but having made the necessary changes (IP Ways) to the config, it's given up. I can ping the lan side from any network PC, and from the pix i can ping both interfaces and their up, but can it get internet access??? NO, the traffic just won't flow.

Please see the config below, can any one see what I can't...the error that is becoming the bain of my life!!!

PIX Version 6.3(3)

interface ethernet0 auto

interface ethernet1 auto

nameif ethernet0 outside security0

nameif ethernet1 inside security100

enable password XXXXXXXXXXXXXXXXXX encrypted

passwd XXXXXXXXXXXXXXX encrypted

hostname XXXXXW

domain-name XXXXXXXXXXXXX

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 no_nat permit ip 192.168.10.0 255.255.255.0 192.168.253.0 255.255.255.0

access-list no_nat permit ip 10.0.11.0 255.255.255.0 192.168.253.0 255.255.255.0

access-list l2lvpn permit ip 192.168.10.0 255.255.255.0 192.168.253.0 255.255.255.0

access-list l2lvpn permit ip 10.0.11.0 255.255.255.0 192.168.253.0 255.255.255.0

access-list outside_access_in deny icmp any any

pager lines 24

mtu outside 1500

mtu inside 1500

ip address outside 86.54.xxx.xxx 255.255.255.240

ip address inside 10.0.11.254 255.255.255.0

ip audit info action alarm

ip audit attack action alarm

ip local pool VPNPool 192.168.253.1-192.168.253.254

no pdm history enable

arp timeout 14400

global (outside) 1 interface

nat (inside) 0 access-list no_nat

nat (inside) 1 0.0.0.0 0.0.0.0 0 0

access-group outside_access_in in interface outside

route outside 0.0.0.0 0.0.0.0 86.54.xxx.xxx 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 10.0.11.0 255.255.255.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 3DES esp-3des esp-sha-hmac

crypto dynamic-map map2 10 set transform-set 3DES

crypto map map1 40 ipsec-isakmp dynamic map2

crypto map map1 client authentication LOCAL

crypto map map1 interface outside

isakmp enable outside

isakmp identity address

isakmp nat-traversal 20

isakmp policy 10 authentication pre-share

isakmp policy 10 encryption 3des

isakmp policy 10 hash sha

isakmp policy 10 group 2

isakmp policy 10 lifetime 86400

vpngroup XXXXXXXXXX address-pool VPNPool

vpngroup XXXXXXXXXX dns-server 10.0.11.11

vpngroup XXXXXXXXXX wins-server 10.0.11.11

vpngroup XXXXXXXXXX default-domain xxxxxxxxxxxxxx

vpngroup XXXXXXXXXX idle-time 1800

vpngroup XXXXXXXXXX password ********

telnet 10.0.11.0 255.255.255.255 inside

telnet timeout 5

ssh timeout 5

management-access inside

console timeout 0

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

terminal width 80

banner motd You are attempting to log on to a private network - If you are not authorised to do so then disconnect immediately.

 

[octavian10]

Remove this access list from your outside interface,
access-list outside_access_in deny icmp any any

One you do not need to do this the PIX blocks ICMP by default and second there is an explicit deny at the end of this list dropping all packets including returning TCP requests from your internal users.

Hope this helps.

"I hear and I forget. I see and I remember. I do and I understand."
- Confucius (551 BC - 479)

 

[Supergrrover]

AS Octavian said, You don't actually need to specifically deny traffic inbound. That is done by default.
That being said, that ACL is not blocking any appropriate return traffic. The firewall watches traffic to allow what needs to return to return.

The config looks good. I would take a look at the PCs. What is the default gateway on them? Double check the IPs and subnets.

You can add this line to allow the ICMP responses from outside back to the internal IPs.

fixup prot icmp error


Brent
Systems Engineer / Consultant
CCNP, CCSP

 

[ChrisAC]

"by default and second there is an explicit deny at the end of this list dropping all packets including returning TCP requests from your internal users."

This is a Pix, not a router. Reply traffic to outbound connections will not be blocked by an outside access list. The Pix (unlike a router) is stateful.

What logs are you seeing when trying to get internet access? Have you looked at the translation table to see if the Pix is seeing outbound connections and correctly NATing that traffic.

Also, are there any access-lists on the gateway router (the default gw for the Pix)? Are you able to get internet access using that router by taking the Pix out?

Chris.


**********************
Chris A.C, CCNA, CCSA
**********************

 

[CertifiedNut]

Hi all, many thanks for your replies. The PIX in this case is the default gateway. I can connect to and log on to the VPN side of the PIX and see the internal network and ping all the internal devices, but cannot get access to the internet from internally connected clients. The system has a few servers and one or two PC's connected at present and one of the servers acts as the DC and forwards DNS quiries to the firewall. As mentioned in my original post, the PIX was working with the same config previously on a different network and all I did was to move it to this network and change the IP's on the internal side, even the public stayed the same. I'm looking for the log commads to see what I can find out and will post later.

Many thanks

Rick

 

[CertifiedNut]

Hi everyone,

Some news to cloud the issue further. It would seem that the issue is related to DNS resolution. When I give a client the DNS server address of our ISP the client can get out onto the internet without problems. As far as I can see from looking at the config, DNS resolution should not be an issue unless there is a problem that is not visable within the config.

Any clues??

PS still trying to locate how to get log data.

Rick

 

[Supergrrover]

Ahhhhh, The pix does not act as a DNS server. You will need to either have DNS resolved internally via your server or use the ISP's server.


Brent
Systems Engineer / Consultant
CCNP, CCSP

 

[MontrealSoft]

Sorry for interrupting(!) but can someonel look at my thread ? The problem shouln't be very hard for you guys...
My thread :

http://www.tek-tips.com/viewthread.cfm?qid=1415004&page=1

Thank's !

MontrealSoft.com

http://www.montrealsoft.com

 

[octavian10]

Ahhhhha is correcy Brent, on the previous network there most likley was a dhcp server issuing dns information. Does this new network have a dhcp server? If not how are the machines on it getting thier address's, if they are staticly assighned then you will have to do the same with the dns servers of your isp. In a small network like this you can program the the PIX to perform dhcp for you with the dhcpd command, or you can have the pix get its public address via dhcp from the isp, and the use the
(dhcpd auto_config outside) command to get the isp dns servers for you. Either way your config is fine your problem is dhcp. Also sorry about the bonehead post initially, I at times forget I am not behind a router.

"I hear and I forget. I see and I remember. I do and I understand."
- Confucius (551 BC - 479)

 

[CertifiedNut]

Guys, thank you for the wealth of knowledge and I also apologise for not correctly putting over the config of the network. There is a server (AD Controller) that serves as DHCP and DNS for the network on the inboard (LAN), but this currently does not seem to be resolving DNS to the outside world. The PIX has a static IP on the outside i/f from the ISP and forwards to the default gateway of the ISP. If i connect a client PC with a static IP to the LAN i/f of the PIX and give it the ISP's DNS server address then it gets out onto the internet, but when I reconnect the dev LAN with it's Windows 2003 AD Controller doing the DHCP and DNS, I'm back to square one with no traffic getting resolved to the outside world. Is there a way of monitoring DNS requests from the LAN through the PIX to the outside world? The (inbuilt) firewall within the 2003 ADC has not been enabled.

I have checked the DNS setup of the server and it all seems to be as expected with all the forwarders set up and with a default gateway of the PIX as it's way out to the internet.

Your continued help is appreciated.
Rick

 

[CertifiedNut]

All,

The problem has now been resolved and the config was not the issue. The problem truned out to be that the 2003 AD server had the DNS configured before the PIX was put in place, but although the default gateway IP address was added to the DNS settings, it would seem that as it was not physically in place the DNS system did not correctly and fully configure itself and therefore was not forwarding on DNS quires to the DGW.

Thanks again guys for all your help, much apprciated

Rick