Problem Configuring Cisco 1921 Router - Can't reach external ip addresses, websites, etc
So I'm figuring another Cisco 1921 Router (and have done a couple of these before) and have put together my "test" config (see below), based on my other working configurations and notes.
Now when connected to the Router (via Teraterm), I can ping pretty much anything I want! Both interfaces, my gateway, google, laptop connect to router, so basically anything inside or outside of the Router.....but On my Laptop, connected to the 1921, I can reach (ping) anything on the inside, Gi 0/0 and the actual Gi 0/1 side.....BUT nothing external like the GW address or beyond to the net. I once had a similar problem once before and I think just adding the route to the GW cleared things up. But not this time, perhaps someone with a fresh set of eyes can see my problem??
Thanks in Advance!
so My "outside" addressing is x.yy.zzz.149 where the GW is at x.yy.zzz.190
and "inside" I testing with 10.10.10.1 and using DHCP to assign device IP (which is working)
here's my current config (with some sensitive items removed, thx)
! version 15.4 service timestamps debug datetime msec service timestamps log datetime msec no service password-encryption ! hostname Router ! boot-start-marker boot-end-marker ! ! ! no aaa new-model !
! ip dhcp excluded-address 10.10.10.1 10.10.10.5 ! ip dhcp pool poolz import all network 10.10.10.0 255.255.255.0 default-router 10.10.10.1 dns-server 18.104.22.168 22.214.171.124 lease 0 2 !
! ip domain name yourdomain.com ip name-server 126.96.36.199 ip name-server 188.8.131.52 ip cef no ipv6 cef multilink bundle-name authenticated ! cts logging verbose ! <crypto stuff deleted here......>
redundancy ! ! interface Embedded-Service-Engine0/0 no ip address shutdown ! interface GigabitEthernet0/0 description $INSIDE ip address 10.10.10.1 255.255.255.0 ip virtual-reassembly in duplex auto speed auto no mop enabled ! interface GigabitEthernet0/1 description $outside ip address x.yy.zzz.149 255.255.255.192 ip virtual-reassembly in duplex auto speed auto ! ip forward-protocol nd ! ip http server ip http authentication local ip http secure-server ip http timeout-policy idle 60 life 86400 requests 10000 ! ip route 0.0.0.0 0.0.0.0 x.yy.zzz.190 ! access-list 199 permit ip any any ! control-plane ! line con 0 line aux 0 line 2 no activation-character no exec transport preferred none transport output pad telnet rlogin lapb-ta mop udptn v120 ssh stopbits 1 line vty 0 4 login transport input none ! scheduler allocate 20000 1000 ! end
Success! Great Thank You. That did the trick, but while were on the topic.....
About an year ago I had a similar problem (pretty sure), with basic same setup (router etc) for another installation (but was still setup and tested on my bench)
....and back then I was told to take out (remove) these very same calls you suggested I include and that solved my problem then.....adding them solved my problem this time.
Do you have any thoughts as to why that is?? What are the rules here, and why I have at least 2 similar locations running without these, yet this time I needed the "NAT" items for it work. I've done some basic research and get the principle (and have also been told NAT & overload calls can effect performance)...so do you have any tips on this??
And Thanks so much for your help!. I don't think I would have added those commands back without you suggestion...gb
I was thinking more about this afterwards, and yes that makes perfect sense now. When I had first setup my other units (last year) I had the NAT calls in there to make things work (on the bench). But once I moved into production at client site, they worked locally but I couldn't access them remotely (using they public ip's on the cable fiber)....so I had to take all the NAT items out and them was working fine. Thanks again...as they say....sometimes "you can't see the forest through the trees!"
What we do as a group.
The SVCUG hosts Saturday Labs at the Cisco campus where members have:
Access to racks of Cisco equipment
A study environment filled with like-minded & Cisco knowledgeable peers
The opportunity to network with o...
SVCUG Saturday Labs fall into three categories:
Open Labs - No specific agenda; work on what you like (i.e., equipment open use).
Event Lab - The Saturday Lab "time" is being used for a specific event (i.e., presentations, designed lab, etc...
The SVCUG Mailing List is a great way to stay connected between SVCUG meetings and a great place to post network related questions. Anyone that's been on the list for a while knows that this list is a great place to solve problems, se...