There are several things that you could tell us that would be very helpful in diagnosing this problem:

- if the web server is plugged directly into the router, can the web server communicate with the router (are there any cable issues, or speed/duplex issues)?

- can the router access Internet resources (ping or traceroute to http://www.cisco.com for example)? (are there any routing issues between the router and the service provider?)

- can the web server access Internet resources (ping or traceroute to http://www.cisco.com for example)? (is the server default-gateway correct? are addresses being translated properly? are there DNS issues?)

It would be helpful if you would post the configuration of the router.

If you can tell us these things we may be able to make progress in solving this issue.

HTH

Rick

Hi Rick, here is the config from my router.

Building configuration...

Current configuration : 3181 bytes

!

version 12.4

no service pad

service timestamps debug datetime msec

service timestamps log datetime msec

service password-encryption

!

hostname Router

!

boot-start-marker

boot-end-marker

!

enable secret *******

enable password *******

!

no aaa new-model

!

resource policy

!

clock timezone EST 10

clock summer-time EDT recurring last Sun Oct 2:00 last Sun Mar 2:00

ip subnet-zero

no ip source-route

ip cef

!

!

ip domain name <> (I also have another domain <> (How can I add this?))

ip name-server <>160.35

ip name-server <>160.36

ip name-server <>56.56

ip name-server <>184.150

ip name-server <>6.134

ip name-server <>219.3

!

!

!

username ******* privilege 15 password *******

!

!

interface ATM0

no ip address

ip nat outside

no ip virtual-reassembly

no atm ilmi-keepalive

pvc 8/35

encapsulation aal5mux ppp dialer

dialer pool-member 1

!

dsl operating-mode auto

!

interface FastEthernet0

spanning-tree portfast

!

interface FastEthernet1

spanning-tree portfast

!

interface FastEthernet2

!

interface FastEthernet3

!

interface Vlan1

ip address 10.7.2.254 255.255.255.224

ip nat inside

ip virtual-reassembly

ip tcp adjust-mss 1420

!

interface Dialer0

bandwidth 1500

ip address negotiated

ip access-group 101 out

ip mtu 1492

ip nat outside

ip virtual-reassembly

encapsulation ppp

dialer pool 1

dialer idle-timeout 0

dialer persistent

dialer-group 1

ppp chap hostname *******@<>

ppp chap password *******

ppp pap sent-username *******@<>password *******

!

ip classless

ip route 0.0.0.0 0.0.0.0 Dialer0

!

no ip http server

no ip http secure-server

ip nat inside source list 1 interface Dialer0 overload

ip nat inside source static tcp 10.7.2.250 80 isp.static.ip 80 extendable

!

access-list 1 permit 10.7.2.0 0.0.0.255

access-list 10 permit 10.7.2.227

access-list 10 deny any

access-list 101 permit tcp any any eq www

access-list 101 permit tcp any any eq 443

access-list 101 permit tcp any any eq smtp

access-list 101 permit udp any any eq domain

access-list 101 permit udp any any eq ntp

access-list 101 deny ip any any

dialer-list 1 protocol ip permit

no cdp run

!

control-plane

!

!

line con 0

login local

no modem enable

line aux 0

login local

line vty 0 4

access-class 10 in

login local

!

scheduler max-task-time 5000

ntp clock-period 17176872

ntp server <>160.2

end

Traceroute results from router:

Translating "<>"...domain server (<>160.35) (<>160.36) (2

08.76.56.56) (<>184.150) (<>6.134) (<>219.3)

% Unrecognized host or address.

Traceroute results from pc:

Tracing route to <> [<>.70]

over a maximum of 30 hops:

1 1 ms <1 ms <1 ms <> [10.7.2.254]

2 <> [10.7.2.254] reports: Destination net unreachable.

Trace complete.

nslookup results from pc:

nslookup <>

Server: <>.<>

Address: 10.7.2.250

Name: <>

Address: <>20.137

nslookup <>

Server: <>.<>

Address: 10.7.2.250

Non-authoritative answer:

Name: <>

Address: <>.70

Alexandros

Thank you for posting the router configuration. That does address my question about whether you were translating addresses. I see an ip nat outside on the ATM interface which I believe does not need to be there (but I do not believe that it hurts anything by being there). There is translation for the inside host addresses and there is a static translation for the server. I am not clear what the server address is translating to, but I assume that it is ok.

I am surprised that apparently the router is returning the error destination network is not available. Can you post the output of show ip route from the router?

HTH

Rick

Rick, Thanks for getting back to me on this. Here is the results for sh ip route

Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP

D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area

N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2

E1 - OSPF external type 1, E2 - OSPF external type 2

i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2

ia - IS-IS inter area, * - candidate default, U - per-user static route

o - ODR, P - periodic downloaded static route

Gateway of last resort is 0.0.0.0 to network 0.0.0.0

203.219.20.0/32 is subnetted, 1 subnets

C 203.219.20.137 is directly connected, Dialer0

10.0.0.0/27 is subnetted, 1 subnets

C 10.7.2.224 is directly connected, Vlan1

202.7.162.0/32 is subnetted, 1 subnets

C 202.7.162.164 is directly connected, Dialer0

S* 0.0.0.0/0 is directly connected, Dialer

I also had the line of ip nat inside source static tcp 10.7.2.250 25 203.219.20.137 25 in the config as well which I had removed at the time of the config dump.

Alexandros

Thanks for posting the additional information. At this point I am wondering if the issue may be the access list 101 which is applied outbound on the dialer interface. It does not permit any traceroute traffic. Would you be able to open up that access list (at least for testing purposes) and see if the behavior changes?

HTH

Rick

Hi Alex,

Warning - I am all new to Cisco, so I may be misleading you more...

I had exactly the same problem but it is now fixed. I fiddled and fiddled and fiddled so not really sure how it got fixed.

My Dialer:

interface Dialer0

description $FW_OUTSIDE$

ip address 78.32.54.113 255.255.255.248

ip access-group 103 in

no ip redirects

no ip unreachables

no ip proxy-arp

ip inspect SDM_LOW out

ip nat outside

ip virtual-reassembly

encapsulation ppp

ip route-cache flow

dialer pool 1

dialer-group 1

no cdp enable

ppp authentication chap callin

ppp chap hostname dsl-login-string

ppp chap password 7 ******

It checks 103 in rather than out. I reasoned that it was traffic into the Dialer interface from the Internet that I wanted to check.

access-list 103 permit tcp any host 78.32.54.118 eq www

access-list 103 permit gre any any

access-list 103 permit ip any host 78.32.54.114

access-list 103 permit udp host 195.74.113.62 eq domain host 78.32.54.113

access-list 103 permit udp host 195.74.113.58 eq domain host 78.32.54.113

access-list 103 deny ip 192.168.7.0 0.0.0.255 any

access-list 103 permit icmp any host 78.32.54.113 echo-reply

access-list 103 permit icmp any host 78.32.54.113 time-exceeded

access-list 103 permit icmp any host 78.32.54.113 unreachable

access-list 103 permit tcp any host 78.32.54.113 eq 443

access-list 103 permit tcp any host 78.32.54.113 eq 22

access-list 103 permit tcp any host 78.32.54.113 eq cmd

access-list 103 deny ip 10.0.0.0 0.255.255.255 any

access-list 103 deny ip 172.16.0.0 0.15.255.255 any

access-list 103 deny ip 192.168.0.0 0.0.255.255 any

access-list 103 deny ip 127.0.0.0 0.255.255.255 any

access-list 103 deny ip host 255.255.255.255 any

access-list 103 deny ip host 0.0.0.0 any

access-list 103 deny ip any any log

and finally

ip nat inside source static tcp 192.168.7.118 80 78.32.54.118 80 extendable

My www is actually available from outside. Trying to get there from inside my network doesn't work. I had to use my mobile to find out if 78.32.54.118 was open on port 80 and it was.

(You should be able to try it for real.)

Any help here?

David

David

Congratulations on getting yours working. And thanks for posting your config. In looking at it I see several differences which I do not believe are especially important (you have an input access list while Alexandros has only an output (and your SDM_LOW out gives you the outbound filtering) is structured differently, you turn off redirects, unreachables, and proxy-arp which he does not).

I do see what I believe is a critical difference. You specify ppp authentication chap callin. While he has several ppp chap parameters specified, he does not actually tell the interface to authenticate with chap. I believe that it is the fundamental problem (and may explain the network not reachable error - even though the routing table has the default route installed, the interface will not transmit traffic if it has not authenticated).

Alexandros I suggest that you add ppp authentication chap callin and see if it fixes your problem.

HTH

Rick

Hi Rick,

I know... it feels like I just scaled Everest :-)

I turned my ppp auth chap callin off and I could still get to the www.

Now the chap bit of my dialer just says:

dialer pool 1

dialer-group 1

no cdp enable

ppp chap hostname dsl-login

ppp chap password 7 ******

Would I need to bounce the line too? (how do I do that without a write mem & power cycling?)

David

David

Once the line is up and authenticated it should continue to work - which is what you are describing. I would guess that a shutdown and a no shutdown would effectively bounce the line and require the initialization process to authenticate. I would probably do the dialer and also the ATM interface.

HTH

Rick

Hi Rick,

I decided to temporarily redirect the phones and did a power cycle...

My Dialer now says:

interface Dialer0

description $FW_OUTSIDE$

ip address 78.32.54.113 255.255.255.248

ip access-group 103 in

no ip redirects

no ip unreachables

no ip proxy-arp

ip inspect SDM_LOW out

ip nat outside

ip virtual-reassembly

encapsulation ppp

ip route-cache flow

dialer pool 1

dialer-group 1

no cdp enable

ppp chap hostname dsl-login

ppp chap password 7 password

And I can still get to live www on 118 and 114 using my mobile internet, so I am guessing in my environment, at least, that the callin line isn't necessary. (I cannot see any difference in functionality at all.)

I am a real novice in IOS, but I read somewhere that if you had no ACL for incoming connections to an interface, there was an implicit 'deny ip any any' applied.

For that reason I have the BVI with an

ip access-group 100 in

access-list 100 deny ip 78.32.54.112 0.0.0.7 any

access-list 100 deny ip host 255.255.255.255 any

access-list 100 deny ip 127.0.0.0 0.255.255.255 any

access-list 100 permit ip any any

Or did I mis-understand.

I will be putting the line back, just in case though...

However, it gave a warning message.

gateway(config-if)#ppp authentication chap callin

AAA: Warning, authentication list "default" is not defined for PPP.

Just added

aaa authentication ppp default local

and the warning seemed to go away ;-)

David

David

Thanks for continuing to experiment and explore this issue.

My first thought is about your comment:

if you had no ACL for incoming connections to an interface, there was an implicit 'deny ip any any' applied.

I am not sure where this is coming from, but in recent versions of IOS I do not believe that it is correct. In some (old) versions of IOS if there was an access-group configured on an interface and if there was no access-list corresponding to the access-group there was an implicit deny ip any any. But for quite a while the behavior has been that if there was an access-group on an interface and if there was no access-list then it effectively was ip permit any any.

My second thought is that you mention BVI. I am not sure if that is a mis-statement or not. There has not been any mention of BVI in this thread until this. If you do have a BVI then perhaps I should ask you to post the complete configuration of your router so that we can understand the complete context better.

HTH

Rick

Hi Rick,

Probably complete rubbish but it does seem to do what Alex wants...

David