outbound NAT on a 3640

I am trying to setup outbound nat on a 3640 with 2 interfaces. I have
followed Cisco's reccomended config as closely as possible for my
situation...
http://www.cisco.com/en/US/products/sw/secursw/ps1018/products_config...


I have also used the CCNA handbook to assist in my config. Alas still
no success.
Below is my latest attempt at a config as vanilla as i can get it just
to get outboug www traffic going. I can ping the external upstream DNS
server but http requests timeout.


Any help would be greatly apprecaited!


----


version 12.3
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname Router
!
boot-start-marker
boot-end-marker
!
logging buffered 4096 debugging
!
no aaa new-model
ip subnet-zero
!
!
ip cef
!
ip inspect name ethernetin cuseeme timeout 3600
ip inspect name ethernetin ftp timeout 3600
ip inspect name ethernetin h323 timeout 3600
ip inspect name ethernetin http timeout 3600
ip inspect name ethernetin rcmd timeout 3600
ip inspect name ethernetin realaudio timeout 3600
ip inspect name ethernetin smtp timeout 3600
ip inspect name ethernetin sqlnet timeout 3600
ip inspect name ethernetin streamworks timeout 3600
ip inspect name ethernetin tcp timeout 3600
ip inspect name ethernetin tftp timeout 3600
ip inspect name ethernetin udp timeout 3600
ip inspect name ethernetin vdolive timeout 3600
ip audit po max-events 100
!
!
!
!
interface Ethernet0/0
mac-address xxxx.xxxx.xxxx
ip address dhcp
ip access-group 112 in
no ip redirects
no ip unreachables
ip nat outside
full-duplex
!
interface Ethernet0/1
ip address 192.168.2.1 255.255.255.0
ip access-group 101 in
ip nat inside
ip inspect ethernetin in
full-duplex
!
interface Ethernet0/2
no ip address
shutdown
half-duplex
!
interface Ethernet0/3
no ip address
shutdown
half-duplex
!
ip nat inside source list 1 interface Ethernet0/0 overload
ip http server
ip classless
ip route 0.0.0.0 0.0.0.0 Ethernet0/0
!
!
access-list 1 permit 192.168.2.0 0.0.0.255
access-list 101 permit tcp any any
access-list 101 permit udp any any
access-list 101 permit icmp any any
access-list 101 deny ip any any log
access-list 112 permit icmp any any unreachable
access-list 112 permit icmp any any echo-reply
access-list 112 permit icmp any any packet-too-big
access-list 112 permit icmp any any time-exceeded
access-list 112 permit icmp any any traceroute
access-list 112 permit icmp any any administratively-prohibited
access-list 112 permit icmp any any echo
access-list 112 deny ip any any log
!
line con 0
logging synchronous
line aux 0
line vty 0 4
!
!
end

 

remove the acl 112 on e0/0 and try it again
conf t
int e0/0
no ip access-group 112 in

Not sure why you are using an acl on your inside interface as you are
permiting everything. Doesn't gain you anything by having it there, loose it

int e0/1
no ip access-group 101 in

 

I did this and still nothing. I get a DHCP address on my outside
interface, but I cannot get to anything. I cannot ping dns servers or
anything.

 

From the router can you ping? Try pinging 4.2.2.2

 

No. I tried pinging the external from my ISP as well with bad results.

 

Unplug your cable modem for 2 minutes. Then plug it back in. Most cable
modems/systems only allow a single IP to go thru it. It will pass out as
many IP's as needed, simply won't get thru. Your original IP/MAC is being
cached by the modem.

 

I will try this, but I am actually presenting the same MAC as my
linksys was and getting the same IP from DHCP

 

This is for all out there who may need the help on this same situation.
I found out what the issue was.
A friend of mine is an CCIE and I got him to come around and help with
this. He found that he had seen this before when using DHCP on the
outside interface. If you put in a static route for the interface ( ip
route 0.0.0.0 0.0.0.0 Ethernet0/0) in this configuration it may not
work. We took out the static route and let the route be configured by
the DHCP on the interface, and it imidiately started working as
expected. there was nothing wrong with the access-lists or anything
like that. It was strictly that the route was not working properly.


And there you have it.