3640 question

[silverhairb]

I'm setting up a simple config for a 3640. DHCP is working on the LAN side and I'm able to access the router via SDM. On the WAN side, I'm getting a DHCP-assigned address from the downstream 877. But a PC connected to the 3640 cannot access the internet through the 877.

(I suspect ip route - similar to the earlier 877 question, but not sure which interface to apply it to.)

Any help would be appreciated.

TIA,

Bill

Follows is the running config from the 3640:


Current configuration : 2349 bytes
!
version 12.3
no service pad
service timestamps debug uptime
service timestamps log uptime
service password-encryption
!
hostname 3640Router1
!
boot-start-marker
boot-end-marker
!
no logging buffered
!
clock timezone PCTime -6
clock summer-time PCTime date Apr 6 2003 2:00 Oct 26 2003 2:00
no aaa new-model
ip subnet-zero
!
!
ip dhcp excluded-address 10.10.10.1
ip dhcp excluded-address 10.10.10.1 10.10.10.99
ip dhcp excluded-address 10.10.10.155 10.10.10.254
!
ip dhcp pool CLIENT
import all
network 10.10.10.0 255.255.255.0
default-router 10.10.10.1
lease 2 2
!
ip cef
!
!
!
!
!
!
!
!
!
!
!
username silver privilege 15 secret 5 $1$RenU$6XSNMjVSwSISEAKhC./Ot/
!
!
controller T1 0/0
framing sf
linecode ami
!
!
!
interface FastEthernet0/0
ip address 10.10.10.1 255.255.255.0
ip nat inside
duplex auto
speed auto
no cdp enable
hold-queue 32 in
!
interface Ethernet1/0
ip address dhcp client-id Ethernet1/0
ip access-group 111 in
ip nat outside
half-duplex
no cdp enable
!
ip nat inside source list 102 interface Ethernet1/0 overload
ip http server
ip classless
!
!
access-list 23 permit 10.10.10.0 0.0.0.255
access-list 102 permit ip 10.10.10.0 0.0.0.255 any
access-list 111 permit icmp any any administratively-prohibited
access-list 111 permit icmp any any echo
access-list 111 permit icmp any any echo-reply
access-list 111 permit icmp any any packet-too-big
access-list 111 permit icmp any any time-exceeded
access-list 111 permit icmp any any traceroute
access-list 111 permit icmp any any unreachable
access-list 111 permit udp any eq bootps any eq bootpc
access-list 111 permit udp any eq bootps any eq bootps
access-list 111 permit udp any eq domain any
access-list 111 permit esp any any
access-list 111 permit udp any any eq isakmp
access-list 111 permit udp any any eq 10000
access-list 111 permit tcp any any eq 1723
access-list 111 permit tcp any any eq 139
access-list 111 permit udp any any eq netbios-ns
access-list 111 permit udp any any eq netbios-dgm
access-list 111 permit gre any any
access-list 111 deny ip any any
no cdp run
!
!
!
!
!
!
!
!
line con 0
exec-timeout 120 0
transport output all
stopbits 1
line aux 0
transport output all
line vty 0 4
access-class 23 in
exec-timeout 120 0
login local
length 0
transport input all
transport output all
!
scheduler max-task-time 5000
!
end

 

[vipergg]

ip route 0.0.0.0 0.0.0.0 <877 address>

 

[silverhairb]

Just to review, I have a 877 connected to the internet via the ADSL port. A single LAN connection runs into a simple gigabit switch through which several PCs and other swtiches are connected. Also connected to that switch is the ethernet1/0 port from the 3640 running the above config plus the ip route 0.0.0.0 0.0.0.0 [877 address].

I used the SDM connection test to check the 3640's ethernet1/0 after the addition of the ip route statement and it show everything OK.

PC is getting an address from the 3640 and has the correct DNS info that the 3640 got from the 877.

So I have obviously missed something in the config. (I used a config from a 831 as a model.)

Any thoughts?

TIA,

[the other] Bill

 

[Alterac]

you access list is blocking the traffic.


----------------------------------
Bill

 

[Alterac]

err. Wish I could edit my posts.. hah.

Anywhoo, you could either remove the acl, or enable the packet inspection firewall.


----------------------------------
Bill

 

[DallasBPF]

Plus I did not see any DNS for the DHCP

------------------------------------
Dallas, Texas
Telecommunications Tech
CCVP, CCNA, Net+

CCNP in the works

 

[Alterac]

import all on the dhcp should take care of the dns

----------------------------------
Bill

 

[burtsbees]

I'm guessing the 877 is handing the 3640 a private IP address. If this is the case, then you should not have a NAT config in the 3640. Post a sh ip route from both routers, por favor, see voo play, please, etc...

Burt

 

[silverhairb]

Here 'tis. Gracias, merci, thanks in advance.


877 sh ip route

Gateway of last resort is 0.0.0.0 to network 0.0.0.0

70.0.0.0/32 is subnetted, 2 subnets
C 70.225.79.254 is directly connected, Dialer0
C 70.225.78.73 is directly connected, Dialer0
C 192.168.1.0/24 is directly connected, Vlan1
S* 0.0.0.0/0 is directly connected, Dialer0


3640 sh ip route

Gateway of last resort is 192.168.1.1 to network 0.0.0.0

10.0.0.0/24 is subnetted, 1 subnets
C 10.10.10.0 is directly connected, FastEthernet0/0
C 192.168.1.0/24 is directly connected, Ethernet1/0
S* 0.0.0.0/0 [1/0] via 192.168.1.1



IP address of the 877

 

[burtsbees]

So the 871 is the NAT router. Can you ping Google from the 3640? Also, post a sh run from the 871. This seems like a routing problem, and if you're double natting, that could cause this problem as well.

Burt

 

[burtsbees]

OK---now I have to ask...why are you connecting the 3640 to the 877 at all??? Is this the beginning of a lab? Also, acl 111 is not permitting http return traffic---in fact, it denies a LOT that may be necessary. SO, if you still want the 3640 in the picture, remove acl 111 from e1/0, remove ip nat out from it as well, remove the nat statement (no ip nat inside source list blablabla...), remove ip nat in from fa0/0, put in
router(config)#ip route 10.10.10.0 255.255.255.0 192.168.1.1

in the 877, and

ip route 0.0.0.0 0.0.0.0 WAN_interface

if you don't already have it. It does not know how to route to the 3640 LAN. That should fix ya.

Burt

 

[silverhairb]

I'll pull the acl from the 3640 until I get it working. I debated this and just decided to leave the rules to see what happened.

IIRC, the 877 already uses ip route 0.0.0.0 0.0.0.0 atm0 and its working.

The rest of the suggestions will be taken care of tomorrow. (Writing that paper is taking up the free time tonight.)

Good question.

I had originally intended to connect the 3640 to a Motorola DSL modem, but the modem seems to have some problems with carrier detect. As a fallback the 3640 got connected to the 877 to test its functionality and to see if I could create a decent working configuration without (or at least with minimum) help.

 

[burtsbees]

Did you write that acl from what someone had suggested, or were you experimenting?

Burt

 

[silverhairb]

The answer is yes. Most of it came from SDM from a previous running config, a few entries came from me. I was trying to set some filters. Might have gone too far.

 

[burtsbees]

access-list 111 permit icmp any any administratively-prohibited
access-list 111 permit icmp any any echo
access-list 111 permit icmp any any echo-reply
access-list 111 permit icmp any any packet-too-big
access-list 111 permit icmp any any time-exceeded
access-list 111 permit icmp any any traceroute
access-list 111 permit icmp any any unreachable
access-list 111 permit udp any eq bootps any eq bootpc
access-list 111 permit udp any eq bootps any eq bootps
access-list 111 permit udp any eq domain any
access-list 111 permit esp any any
access-list 111 permit udp any any eq isakmp
access-list 111 permit udp any any eq 10000
access-list 111 permit tcp any any eq 1723
access-list 111 permit tcp any any eq 139
access-list 111 permit udp any any eq netbios-ns
access-list 111 permit udp any any eq netbios-dgm
access-list 111 permit gre any any
access-list 111 deny ip any any

Just copying so I don't have to keep scrolling up...lol

You need return traffic to be allowed. Three way to do this...
1)allow tcp any 10.10.10.0 0.0.0.255 eq 80, and any other traffic---can be tedious, and not the best way.

2)allow tcp from mask to mask eq whatever established---this allows traffic from a destination as long as the tcp session (TCP-SYN) has been established on the inside, from the LAN---this takes care of having to worry about return traffic. A better way of doing things, but again, not the best...may be the best option.

3)CBAC---the best option, IF you have "k9" in the IOS code (crypto). CBAC works with the IOS firewall (ip inspect this, that, these and those) to manipulate the acl applied to the same interface the "inspect name" is applied to. The best way to configure this is to have the firewall inspect all traffic going out, and have an acl that allows what traffic you want to allow out, and then deny everything coming in. The acl "deny ip any any" will not actually deny everything---it gets changed for traffic it has already inspected going out. You would allow traffic in that would not generally get initiated on the inside, like ssh for example, and deny everything else. It is a very fancy, specific, and VERY effective way of doing number two---but at the application layer (like FTP) rather than at the Transmission Control Protocol layer (layer 4), and User Datagram Protocol. Like I say, you need k9 in the image to do this.

Burt