Learn how to a build a cloud-first strategyRegister Now

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 5074
  • Last Modified:

Can't ping valid IP's even though they work

I cannot ping our public IP's even though they work. In other words our web server is serving web pages ok even though I cannot ping it's public address.

ISP router           57.57.57.101

Our Router (S0)   57.57.57.102

WWW server       63.63.63.130

There is no icmp blocking on the router or web server.  I think that this tracert shows an odd result as well.  I have never seen this.  Notice how the most of the entries bounce between the ISP's router and ours without reaching address 63.63.63.130

Here's the tracert result:

C:\Documents and Settings\Administrator>tracert 63.63.63.130

Tracing route to 63.63.63.130  over a maximum of 30 hops

  1     *        *        *     Request timed out.
  2    16 ms    22 ms    30 ms  10.33.160.1
  3    14 ms    11 ms    11 ms  24.30.161.110
  4    14 ms     9 ms    10 ms  66.75.161.190
  5    16 ms    13 ms    14 ms  66.75.161.17
  6    29 ms    15 ms    15 ms  66.75.161.26
  7    23 ms    23 ms    24 ms  66.185.143.5
  8    14 ms    16 ms    23 ms  151.164.248.61
  9    16 ms    15 ms    12 ms  151.164.41.30
 10    21 ms    13 ms    13 ms  151.164.40.89
 11    29 ms    15 ms    18 ms  151.164.241.213
 12    17 ms    15 ms    15 ms  151.164.191.30
 13    24 ms    32 ms    23 ms  57.57.57.102
 14    19 ms    19 ms    20 ms  57.57.57.101
 15    26 ms    27 ms    25 ms  57.57.57.102
 16    23 ms    23 ms    32 ms  57.57.57.101
 17    48 ms    38 ms    30 ms  57.57.57.102
 18    31 ms    42 ms    31 ms  57.57.57.101
 19    50 ms    36 ms    37 ms  57.57.57.102
 20    36 ms    36 ms    50 ms  57.57.57.101
 21    40 ms    43 ms    52 ms  57.57.57.102
 22    40 ms    46 ms    55 ms  57.57.57.101
 23    53 ms    51 ms    70 ms  57.57.57.102
 24    43 ms    44 ms    42 ms  57.57.57.101
 25    50 ms    52 ms    61 ms  57.57.57.102
 26    51 ms    49 ms    50 ms  57.57.57.101
 27    66 ms    58 ms    61 ms  57.57.57.102
 28    57 ms    56 ms    55 ms  57.57.57.101
 29    77 ms    62 ms    72 ms  57.57.57.102
 30    61 ms    60 ms    67 ms  57.57.57.101

Does anyone know what might be causing this and how to correct it?

NOTE: this is a frame-relay network using a cisco 2620 on our end.  Routing for the 63.x.x.x network is done on the ISP's side meaning that there are only nat translations on the 2620.  All routing to the 63.x.x.x network is directed to our router via the ISP's routers.



Thanks in advance!
0
zenportafino
Asked:
zenportafino
  • 3
  • 3
  • 2
  • +3
1 Solution
 
cagriCommented:
A number of things may cause the problem;

1. NAT, are you doing static NAT or overloading + PAT for the web server ? If you use the second option, your ping packets are naturally does not cross router. If you use overloading, you use the same external address for all (or more than one) internal addresses. So, if someone tries to connect from the outside, you make a special setting to route www request (port 80) to the specific server on the inside. In general there is no such setting for ICMP (if it is possible at all).

2. Where is this traceroute initiated from ? From the outside ?

3. Are you sure, there is no firewall open on the web server (Microsoft defaut firewall ?)

Hope those helps, please feel free to ask for further explanation.
0
 
Firmin FrederickSenior IT ConsultantCommented:
Is the www server on the public domain - like the internet?  is it in your own domian internally?

presumably you use a firewall - is your www server on the DMZ of the firewall?

I ask because I'm trying to paint a picture in my head...

to resolve www address your workstations must be told where to find internet DNS resolution which would likely be:

gateway: 57.57.57.102 your Router (S0)
your router gateway : 57.57.57.101 -------------> leased line i take it?

or you would use a proxy server

in any event www=63.63.63.130 would be resolved like this:

www? -----> primary DNS server (workstation NIC) (internal address=yes, take to 63.63.63.130, = NO, go to seconday)
          -----> secondary server (ISP DNS address maybe?)
          -----> gateway
          -----> your router
          -----> ISP router
          -----> ISP DNS Primary
          -----> ISP DNS secondary (take request to internet)

Looks to me like your setup is pretty bad if you are losing the first line in a traceroute
and the variations in the address indicates that no one machine (DNS/WINS etc.) knows what to do or who is responsible

1     *        *        *     Request timed out.   -----------> hey who's doing DNS resolution?
  2    16 ms    22 ms    30 ms  10.33.160.1   -----------> this isn't internal nor your ISP's router
  3    14 ms    11 ms    11 ms  24.30.161.110 ---------->
  4    14 ms     9 ms    10 ms  66.75.161.190  ---------->
  5    16 ms    13 ms    14 ms  66.75.161.17   ----------> token ring?
  6    29 ms    15 ms    15 ms  66.75.161.26
  7    23 ms    23 ms    24 ms  66.185.143.5
  8    14 ms    16 ms    23 ms  151.164.248.61
0
 
tmcguinessCommented:
Your site is dead as a doornail, dude. I think you have some routing issues. Your router may be belly up. I'd check that first.

Your tracert problem is because your ISP doesn't have any routing protocol to prevent routing loops. 101 sees the next hop down but 102 says it can still get their so 101 say ok the next hop is to 102 and 102 says great I just need to go through 101 and so on and so forth.
0
Technology Partners: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

 
PennGwynCommented:
> Your tracert problem is because your ISP doesn't have any routing protocol to prevent routing loops. 101 sees the next hop down but 102 says it can still get their so
> 101 say ok the next hop is to 102 and 102 says great I just need to go through 101 and so on and so forth.

Your ISP knows that this address is yours, and is sending it to your router.  Your router is not recognizing it as something it knows what to do with, and is sending it to its default route -- the ISP's router, which knows that it's yours....

A "routing protocol" is probably not being used to set these entries, but such protocols do not participate in the handling of individual packets.

0
 
marcin79Commented:
missconfiguration of Your routrer or link from Your router to Your machine is down.
Read tmcguiness post - great description of a problem

regards
Marcin
0
 
tmcguinessCommented:

Remember, RIPv2 isn't the smartest protocol around. I'm banking on that being the protocol used here. And if you remember how tracert works, it sends a series of ICMP echo requests with a TTL of 1. When it sees a response back from the first device, it says ok, here's the first hop and how long it takes to get there. It then incrementst the ttl so it sends a series of  echo requests to the second hop and so on.

RIPV2 only talks to it's neighbors. It doesn't know what is happening two doors down. So if a router fails, all of its neighbors know but the neighbor's neighbors don't. This can cause routing loop problems like we see here. Follow me:

Tracert  sends echo requests to router 102 and 102 replies. Tracert then sends echo requests to 101 which replies. Tracert then sends echo requests to the next hop so here it comes, router 102 says just go to 101 it's only two hops away, requests get to 101 and it says hmm... I've got two entries here for the next hop. One has a hop count of 16 that means you can't get there from here and the other says a hop count of three going through router 102 (the hop to the router and the two hops that router 102 thinks it will take to get there). So router 102 goes ahead and replies to the echo requests and tracert sends out more echo requests which this time land at router 101 which replies. Then tracert sends out more echo requests and router 102 says sure just two more hops right through 101 and 101 says hmmm... I've got two entries here for the next hop. One has a hop count of 16 that means you can't get there from here and the other says a hop count of three going through router 102 (the hop to the router and the two hops that router 102 thinks it will take to get there). So router 102 goes ahead and replies to the echo requests and tracert sends out more echo requests.....  

Of course in this case the routing loop isn't really a problem, the problem is that there is a dead router.
0
 
zenportafinoAuthor Commented:
Sorry as it looks like I left too much info out obviously.  The web site actually does work fine.  You are not seeing it and think it's dead beacause the site address above is a placecard and not the real site address.  

Yes there is NAT involved.

ISP router           57.57.57.101

Our Router (S0)   57.57.57.102

WWW server       63.63.63.130
!
!
!
!
clock timezone PST -8
ip subnet-zero
no ip finger
no ip domain-lookup
!
!
interface FastEthernet0/0
 description Inside Lan Connection
 ip address 10.0.0.1 255.255.255.0 secondary
 ip address 192.168.1.1 255.255.255.0
 ip nat inside
 speed 100
 full-duplex
!
interface Serial0/0
 description SBC WAN
 bandwidth 1536
 no ip address
 encapsulation frame-relay IETF
 no fair-queue
 service-module t1 timeslots 1-24
 frame-relay lmi-type ansi
!
interface Serial0/0.1 point-to-point
 bandwidth 1536
 ip address 57.57.57.102 255.255.255.252
 ip nat outside
 frame-relay interface-dlci 15 IETF
!
ip nat inside source list 100 interface Serial0/0.1 overload
ip nat inside source static tcp 192.168.1.201 80 63.63.63.130 80 extendable

ip route 0.0.0.0 0.0.0.0 Serial0/0.1
no ip http server
!
access-list 100 permit ip 192.168.1.0 0.0.0.255 any

line con 0
 exec-timeout 0 0
 password 7 15435C5B526061023A3630261C0A
 transport input none
 speed 19200
line aux 0
 password 7 040A5C51596B06681B1C00131D06
line vty 0 4
 password 7 101F5E4E535D582D1E012F2F2B25
 login
!
end

Let me know if you want more info.  I don't think I'm using a routing protocol on this config.  Which one should I use? I submitted the config to an SBC engineer who said the config looked fine.  Thanks for the continued help.






0
 
zenportafinoAuthor Commented:
Note: Tracert is being done from my home machine outside of the network.  There are no PTR or A records registered yet for this site.  The tracert above was done using the IP and not the FQDN.  If I take a port scanner and point it at 63.63.63.130 I can see port 80 is open.
0
 
cagriCommented:
From your router config, my initial answer seems to be true.

ip nat inside source list 100 interface Serial0/0.1 overload

You are doing overloading. This meains your all of the members of access-list 100 can access outside happily but outsiders can not access individual internal hosts. This needs a static definition and here is yours:

ip nat inside source static tcp 192.168.1.201 80 63.63.63.130 80 extendable

Bingo, you are static natting port 80s (as in my first post) two let your web service running. ICMP is simply not translated at all. Traceroute also uses icmp (icmp unreachable messages) for draw the path.

What you are experiencing is normal. If you want the host 192.168.1.201 act as a fully real host under the ip of 63.63.63.130, you have to define a static line without tcp restrictions (you should static nat ALL of your protocols). In terms of security conserns on the other hand, existing config is preferable.

Hope this helps,
0
 
tmcguinessCommented:
cagri is the man (or woman?)
0
 
zenportafinoAuthor Commented:
Thanks to all that posted.  I apologize for not putting in the router config earlier.  From now on with all router questions I'll post the config at the start.  Thanks again.
0

Featured Post

New Tabletop Appliances Blow Competitors Away!

WatchGuard’s new T15, T35 and T55 tabletop UTMs provide the highest-performing security inspection in their class, allowing users at small offices, home offices and distributed enterprises to experience blazing-fast Internet speeds without sacrificing enterprise-grade security.

  • 3
  • 3
  • 2
  • +3
Tackle projects and never again get stuck behind a technical roadblock.
Join Now