cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1844
Views
0
Helpful
15
Replies

Simple tunneling not working - whats wrong?

amarranca
Level 1
Level 1

Well, I'm trying to make a tunnel between a WiFi hotspot ADSL router and another cisco router. I try to open the tunnel but I receive "% Connection refused by remote host"

Below is my config, where have I gone wrong?

-------------------------------------

*** WiFi ADSL Cisco 827 Router ***

interface Tunnel99

description *** tunnel to 831 router ***

no ip address

tunnel source BVI1

tunnel destination X.X.17.103

!

interface Ethernet0

description outbound for WiFi users

ip address 10.0.10.1 255.255.255.0

ip nat inside

no cdp enable

hold-queue 100 out

!

interface BVI1

ip address X.X.19.130 255.255.255.224

ip nat outside

!

ip nat inside source list 102 interface BVI1 overload

ip nat inside source static tcp 10.0.10.5 80 interface BVI1 80

ip classless

ip route 0.0.0.0 0.0.0.0 BVI1

no ip http server

-----------------------------------------

*** End Cisco 831 Router ***

interface Tunnel99

description *** Tunnel to 827 Router ***

no ip address

keepalive 10 3

tunnel source Ethernet1

tunnel destination X.X.19.130

!

!

interface Ethernet1

ip address X.X.17.103 255.255.255.0

duplex auto

no cdp enable

!

ip classless

ip route 0.0.0.0 0.0.0.0 X.X.17.1

ip route X.X.19.128 255.255.255.224 Tunnel99

15 Replies 15

pkhatri
Level 11
Level 11

Hi,

I presume you get that error when you try to telnet to that router.l Have you configured an access-class under the 'line vty 0 4' on the destination router ? You may have an access-class that is denying the incoming telnet connection.

Hope that helps - pls rate the post if it does.

Paresh

Adding to Paresh's comments, you may also need a 'transport input all' on your vty lines.

Please rate all helpful posts.

Regards,

Brad

Actually I think that there is a fundamental problem in the tunnel configuration. From the 831 router there is this in the configuration:

tunnel destination X.X.19.130

ip route X.X.19.128 255.255.255.224 Tunnel99

what this shows is that the router will attempt to reach the end point of the tunnel by going through the tunnel. This problem of recursion will prevent the tunnel from working.

For a tunnel to work the router must have a route to the tunnel end point that does not go through the tunnel.

HTH

Rick

HTH

Rick

I can telnet to both routers perfectly fine. I can ping out to the world from both routers.

I'm receving my mentioned error when I attempt to open a tunnel from one router to the other. For example: From the 831 router I issue the command "tunnel X.X.19.130" to try and connect to the other router and it shows "connection refused by remote host" right away.

For what it's worth, when I do a show int tunnel99 on the 831 router the interface show up, down.

When I show int tunnel99 from the 827 router the interface shows up, up

The comamnd "tunnel x.x.x.x" in CLI command mode is not related to GRE tunneling but rather to a different feature called asynchronous host mobility. So it is normal that you get the "connection refused by remote host" message since the other router is not configured for it.

For more information on asynchronous host mobility, refer to the following URL:

http://www.cisco.com/en/US/products/sw/iosswrel/ps1828/products_configuration_guide_chapter09186a00800872fd.html#3652

Hope this helps,

Harold Ritter
Sr Technical Leader
CCIE 4168 (R&S, SP)
harold@cisco.com
México móvil: +52 1 55 8312 4915
Cisco México
Paseo de la Reforma 222
Piso 19
Cuauhtémoc, Juárez
Ciudad de México, 06600
México

You are getting the tunnel interface up, down on the 831 because you configured tunnel keepalives on that router and there is no connectivity over the tunnel. You are getting up, up on the 827 because it does not have tunnel keepalive configured.

I would suggest that you remove the static route to the tunnel end point

ip route X.X.19.128 255.255.255.224 Tunnel99

and let us know what happens.

HTH

Rick

HTH

Rick

I removed this statement from the 831. Produced no change.

The IOS on the 827 must not support the 'keepalive statment" as I try to add that to the tunnel interface and its not showing up as a valid command

One interesting thing about GRE tunnel keepalives is that they work ok if configured only on one end (very different from keepalives on most interfaces which must match on both ends). You could remove the keepalives on the router where it is configured, but I do not believe that this would change your problem.

Can you do an extended ping, in the extended ping specify the ping destination as the tunnel destination and specify the ping source as the tunnel source? Can you do this on both routers and let us know the results?

HTH

Rick

HTH

Rick

What would you recommend for ip route statements, I think this is where the problem is.

My connection to the world is X.X.17.1 so I think a route needs to be taken that way and also a statement to push the traffic through the tunnel correct?

Any help is GREATLY appreciated

Guys,

Am I missing something obvious here? There is no passenger protocol (in this case IP) specified on the tunnel interfaces. How is this going to work?

Have you tried configuring an IP address at each end of the tunnel? Use the same network as if it was a point-to-point link

Rgds

E.

The original problem description centered on the error connection refused by remote host, which Harold explained as being related to a protocol different from GRE. Then there was another description which gave this:

For what it's worth, when I do a show int tunnel99 on the 831 router the interface show up, down.

When I show int tunnel99 from the 827 router the interface shows up, up

I believe this situation reflects failure of the keepalive configured on the 831. I believe that the keepalive should function even with no passenger protocol. But it would be worth it for the original poster to add IP as the passenger protocol and see if it makes a difference.

HTH

Rick

HTH

Rick

When I first created the tunnel I did include an IP for each end of the tunnel. Once things were not working the IP was removed as part of the "trial and error" process.

Now,

I have assigned an IP of 192.168.200.10 255.255.255.252 to the Cisco831

Also, assigned an IP of 192.168.200.9 255.255.255.252 to the Cisco 827

now that the tunnels have an IP and I re-added the command "tunnel mode gre ip" to each tunnel they are showing up and up when I query the interfaces now.

Tunneling is still new to me, how do I test this to make sure its working?

EDIT: I take that back they WERE both up, not anymore the 831 went back to showing up, down

LOL, now they are both down, down. I cant win!

I spoke to soon, sorry

Anthony

One of the primary requirements for this kind of tunnel is that the source address of the tunnel must have IP connectivity to the destination of the tunnel (without using the tunnel to get there). So I will repeat the question that I asked earlier. Can you use extended ping and test connectivity for the tunnel. To be specific: on the 827 router can you do an extended ping which specifies X.X.17.103 as the destination and specifies X.X.19.130 as the source?

And on the 831 router can you use extended ping specifying X.X.19.130 as the destination and specifying X.X.17.103 as the source?

As a side note, while I understand your desire to protect your environment, the more you hide information such as the first 2 octets of these addresses, the more difficult it is to understand the problem. I am assuming that the first 2 octets are the same in these addresses. But it might significantly change the problem if they were different.

I believe that this is the first major step in determining what is the problem.

HTH

Rick

HTH

Rick
Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: