TOPIC: PIX 501 - NAT Problem

Hi All!

Am kinda new to PIX configs. Am trying to work out why a pix config which has worked for a long time has suddenly started to fail! This is being used to connect an internal lan 192.168.1.x to a dsl line with a public range ( /28). the pix is doing nat and dhcp. DHCP is working fine but users cannot get out to the internet. Am racking my brains to work out why? Any ideas??? Seems that there are some helpful tips handed out on this forum ! ) Am running 6.3.4

All i want to do is set up is DHCP with NAT. Do I need to specify ACL for this to work by default possibly???


PIX Version 6.3(4)
interface ethernet0 10baset
interface ethernet1 100full
nameif ethernet0 outside security0
nameif ethernet1 inside security100
enable password xxxxxx encrypted
passwd xxxxxxxxxxxxxx encrypted
hostname xxxxxxxpix
domain-name xxxxxxxx.com
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 ils 389
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
pager lines 24
mtu outside 1500
mtu inside 1500
ip address outside 217.206.x.x 255.255.255.240
ip address inside 192.168.1.1 255.255.255.0
ip audit info action alarm
ip audit attack action alarm
pdm location 192.168.1.1 255.255.255.255 inside
pdm logging informational 100
pdm history enable
arp timeout 14400
global (outside) 1 217.206.x.x-217.206.x.x
global (outside) 1 interface
nat (inside) 1 0.0.0.0 0.0.0.0 0 0
route outside 0.0.0.0 0.0.0.0 217.206.x.x 1
timeout xlate 0:05: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 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
http server enable
http 192.168.1.0 255.255.255.0 inside
http 192.168.1.1 255.255.255.255 inside
no snmp-server location
no snmp-server contact
snmp-server community public
no snmp-server enable traps
floodguard enable
telnet 192.168.1.0 255.255.255.0 inside
telnet timeout 5
ssh timeout 5
console timeout 0
dhcpd address 192.168.1.6-192.168.1.33 inside
dhcpd dns 195.x.x.x 212.13x.x.x
dhcpd lease 3600
dhcpd ping_timeout 750
dhcpd auto_config outside
dhcpd enable inside
vpnclient server 217.206.x.x
vpnclient mode client-mode
vpnclient vpngroup xxxxxxx password ********
vpnclient username xxxxx password ********
vpnclient enable
terminal width 80
Cryptochecksum:xxxxxxxxxxxxxxxxxxxx
: end

TheeGreatCornholio - you seemd to have a lot of useful tips up your sleeve

many thanks

IP-bod,

Well, I'll try to help you out. What's interesting to me is that you say this config has worked for a long time, and now suddenly it isn't working. Looking at you config (which is missing ACL's, but that's ok), it seems just fine - nothing in there shouting 'bad' to me. That being said, and based on what you've said so far, it really is sounding like an ISP related issue - perhaps something has changed on their side?

You mentioned that your connection is DSL. Can you describe more about it? Also, it appears in your config that you have a /28 external network. Tell me more about the next-hop internet router you have - is it functioning properly? Have you placed a PC on the external network (outside interface side) and tested internet connectivity - taking the PIX out of the loop?

Any info about how far along in the trouble shooting process would be greatly helpful with your issue.

It appears as though you have VPN configured too - is that part working (looks like some VPN related config is either missing or has been stripped from your message)?

One other thing you may try to check... see if your problem is DNS related, and not just the Internet... from an internal PC, try opening a browser and surfing to an IP address instead of a hostname. For example, you could surf to: 66.102.7.147

It's one of the IP addresses for www.google.com.

If you get to google, then your firewall is OK, and the problem is the IP addresses you have setup for DNS in the DHCP config on the PIX. If this is the problem, you should contact your ISP and ask them for updated DNS servers to use.

If that doesn't work, then I'd like to get more information about where you are with things...

If you are uncomfortable with posting any more details about your config, feel free to send it to me in a private message. I will try to help you out.

tGc

Thanks for that TGC!

Yep tried those things as well. Put my pc direct on the dsl router in the / 28 range and its goes out fine to the internet, also tried browsing via ip instead ( incase this is DNS related) no luck

Am not running any vpn config if its there its not doing anything. I can ping the dsl router from the pix ok. I could try running some debugs but this should be a real basic config - right????

show log gives the following output (1.7 is my laptop the other being a url on the net :

109023: User from 192.168.1.7/4034 to 212.58.240.44/80 on interface inside using
tcp must authenticate before using this service

The above appears alot for any service icmp .tcp etc...

Also the below this is between the dsl router and pix ip's:

702204: ISAKMP Phase 1 retransmission (local x.x.188.130 (initiator), remote
x.x.188.128)
402106: Rec'd packet not an IPSEC packet. (ip) dest_addr= x.x.188.130, s


402106: Rec'd packet not an IPSEC packet. (ip) dest_addr= x.x.188.130, src_a
ddr= x.x.188.129, prot= icmp


Thanks a lot!

IP-Bod,

Interesting messages being logged. The first one is a standard user-authentication required message. However, the config you pasted into this post must be missing some lines, because that message can only be generated if AAA user-authentication is enabled at some level. Do you have the command 'aaa authentication include...' or 'aaa authentication match ...'? That could be the cause of it...

In case you're curious, the PIX has the ability to authenticate users before they are permitted to browse the internet. It's a function called Uauth. It's been around for quite a while (version 5.x). I see that you've altered one default setting - the timeout uauth setting... you have your absolute value set at 5 minutes, which is not very good... this would force a user to reauthenticate to the PIX every 5 minutes to continue to browse the internet. There are two uauth timers - an idle timer, and an absolute timer. Idle = user stops browsing the internet, if user is idle for the timeout value or longer, and user tries to use web again, the PIX will force reauthentication. The absolute timer does not reset to zero. Once a user logs in for the morning, the absolute timer starts If it is set for, say, 2 hours, then the user will be forced to reauthenticate again after the timer expires - regardless of their internet usage during that two hour timeframe.

Here is an explanation of that error message from the Cisco Error Message Decoder tool on CCO:

%PIX-3-109023: User from src_IP_Adress/src_port to dest_IP_Address/dest_port on interface outside must authenticate before using this service.
This is a AAA message. Based on the configured policies, you need to be authenticated before you can use this service (port).

Recommended Action: Have the user authenticate using Telnet, FTP or HTTP before attempting to use the above service (port).

(Gotta love their recommended actions... good ole Cisco...)

Ok, so one thing the decoder didn't mention is that users can authenticate via HTTPS now too, starting in 6.3(1), I believe (but there were some killer bugs in that function, that were fixed in 6.3(4)... But that's a whole other story.

One last thing - the Uauth function requires some type of Radius or TACACS server to authenticate users against... Cisco ACS, or some other generic Radius server that is either referring to an NT Domain, LDAP directory or some other user database is needed. If one is either a) not defined, or b) not online, this could be part of the problem too.


Anyway - yep - your config definitely has some VPN related items in it, possibly beyond what you have shown us thusfar - that's why you are seeing those ISAKMP Phase 1 initiator messages... Your pasted config is missing your isakmp policies, crypto maps and any related ACL's defined in those maps. Having this info would be greatly helpful in troubleshooting your issue.

Again, if you are comfortable, please feel free to send me your entire config privately. I will be able to assist if I have all of the details... You can take out all of the sensitive stuff.

Keep us posted on your findings! Good luck.

tGc

Sorry for the delayed response.

Managed to crack this by removing the 'VPN config' on the PIX. ( no idea why it was there in the beginnning) I kinda figured it was looking for some auth mechanism , though since we are not using one, (or having been told we aren't) disabled it, and users are now connecting fine!


TheeGreatCornholio - Thanks for all the advice/tips.

IP-bod