GRE Tunnel problem with one endpoint in NAT

GRE Tunnel problem with one endpoint in NAT

NewsGroups | Search | Tools
 comp.dcom.sys.cisco  Post an article  get this group's latest topics as an RSS feed add this group's latest topics to your My MSN content add this group's latest topics to your My Yahoo content  add this group's latest topics to your Google content  YahooMyWeb Yahoo!  Google Google  Windows Live Favorites Windows Live  del.icio.us del.icio.us  digg digg  Add to Netscape Netscape
Subject Author Date
GRE Tunnel problem with one endpoint in NAT Elia Spadoni 05-01-2008
Posted by Elia Spadoni on May 1, 2008, 10:52 am
If you were  Registered and logged in, you could reply and use other advanced thread options
Hello
I have this situation:

Branch office:

C2611 router - atm0/0.1 public wan
eth0/0 lan



HQ:

C2650 - edge router - has on it a /29 IP Range
atm0/0.1 wan
fast0/0 dmz net 172.16.0.*
loopback0 /29 range of IP

one of the /29 range is statically natted (nat 1-1) on 172.16.0.10 (Cisco
3620)

I am not able to put the gre tunnel up. I am sure that the problem is in the
HQ because the 3620 is natted.

There are not ACL or firewalls that blocks the communications. Other
services on the 172.16.0.10 works fine from the internet side (everyone need
to connect to the /29 address of the range natted to it)

What can I check?



Pure Networks
Posted by News Reader on May 1, 2008, 12:35 pm
If you were  Registered and logged in, you could reply and use other advanced thread options
Elia Spadoni wrote:
> Hello
> I have this situation:
>
> Branch office:
>
> C2611 router - atm0/0.1 public wan
> eth0/0 lan
>
>
>
> HQ:
>
> C2650 - edge router - has on it a /29 IP Range
> atm0/0.1 wan
> fast0/0 dmz net 172.16.0.*
> loopback0 /29 range of IP
>
> one of the /29 range is statically natted (nat 1-1) on 172.16.0.10 (Cisco
> 3620)
>
> I am not able to put the gre tunnel up. I am sure that the problem is in the
> HQ because the 3620 is natted.
>
> There are not ACL or firewalls that blocks the communications. Other
> services on the 172.16.0.10 works fine from the internet side (everyone need
> to connect to the /29 address of the range natted to it)
>
> What can I check?
>
>

There is no mention of tunnel endpoints or dynamic routing protocols.

Perhaps your issue is "recursive routing".

The routers know of the tunnel endpoints, but see the path to the
far-side tunnel endpoint as being via the tunnel itself (recursive routing).

You would want a static route on each side telling the routers to reach
the far-side tunnel endpoints by way of a "physical interface".

e.g.:        reach the far-side tunnel endpoint (often the external far side
interface) by way of your router's default gateway (next hop, Internet
side).

ip route <far-side-tunnel-endpoint-ip> 255.255.255.255
<router's-Internet-next-hop-ip> 2

There are other methods of dealing with recursive routing, but the
static route method is what I have used.

Best Regards,
News Reader

Posted by Elia Spadoni on May 1, 2008, 8:16 pm
If you were  Registered and logged in, you could reply and use other advanced thread options
>
> e.g.: reach the far-side tunnel endpoint (often the external far side
> interface) by way of your router's default gateway (next hop, Internet
> side).
>
> ip route <far-side-tunnel-endpoint-ip> 255.255.255.255
> <router's-Internet-next-hop-ip> 2
>
> There are other methods of dealing with recursive routing, but the static
> route method is what I have used.
>
> Best Regards,
> News Reader

Hello


I was not able to let it work.
the packet get unreachable not on my edge router, but on first ISP side
router.

any suggestions?..

I didnt have any problems when both of the endopoint were directly connected
public IP..




Posted by News Reader on May 1, 2008, 10:40 pm
If you were  Registered and logged in, you could reply and use other advanced thread options
Elia Spadoni wrote:
>> e.g.: reach the far-side tunnel endpoint (often the external far side
>> interface) by way of your router's default gateway (next hop, Internet
>> side).
>>
>> ip route <far-side-tunnel-endpoint-ip> 255.255.255.255
>> <router's-Internet-next-hop-ip> 2
>>
>> There are other methods of dealing with recursive routing, but the static
>> route method is what I have used.
>>
>> Best Regards,
>> News Reader
>
> Hello
>
>
> I was not able to let it work.
> the packet get unreachable not on my edge router, but on first ISP side
> router.
>
> any suggestions?..
>
> I didnt have any problems when both of the endopoint were directly connected
> public IP..
>

You haven't given us much info to work with. Clarification would be
beneficial.

Which interfaces are used as tunnel endpoints at each site?

Which interfaces are "ip NAT inside" and "ip NAT outside" at each site?

        Don't think you want a tunnel endpoint being an "ip NAT inside" interface.


On which interfaces are the crypto maps applied at each site?

Have the crypto ACLs been changed to reflect the new tunnel endpoint(s)?

Are you using ESP transport mode or tunnel mode?

        Think you probably want to be using ESP Tunnel mode.


Is the tunnel endpoint networks included in your dynamic routing?

May need to revisit the recursive static route based on your answers.

It would be helpful if you shared some addressing info, even if you had
to modify them somewhat for privacy.


When we were using loopback interfaces as tunnel endpoints on our NAT
edge routers:

* We created loopback interfaces to specifically handle this traffic.
They were NOT configured as "ip NAT inside" interfaces.
* We advertised the loopback networks via our dynamic routing protocol.
* We created static routes to the far side loopback networks via the
edge routers next-hop-routers (ISP gateway).
* We amended our crypto maps to reflect the new tunnel endpoint addresses.
* We applied the crypto maps to the edge router's external interfaces.
* We used an ESP Tunnel mode IPSec tranform.

Best Regards,
News Reader

Posted by News Reader on May 1, 2008, 11:32 pm
If you were  Registered and logged in, you could reply and use other advanced thread options
News Reader wrote:
> Elia Spadoni wrote:
>>> e.g.: reach the far-side tunnel endpoint (often the external far side
>>> interface) by way of your router's default gateway (next hop,
>>> Internet side).
>>>
>>> ip route <far-side-tunnel-endpoint-ip> 255.255.255.255
<router's-Internet-next-hop-ip> 2

The above was true for an external interface as the tunnel endpoint.

For the side(s) that use(s) an internal interface (e.g.: loopback) as
the tunnel endpoint, the static route would be:

ip route <far-side-tunnel-endpoint-ip> 255.255.255.255
<far-side-external-interface-ip> 2

Sorry Elia.

>>>
>>> There are other methods of dealing with recursive routing, but the
>>> static route method is what I have used.
>>>
>>> Best Regards,
>>> News Reader
>>
>> Hello
>>
>>
>> I was not able to let it work.
>> the packet get unreachable not on my edge router, but on first ISP
>> side router.
>>
>> any suggestions?..
>>
>> I didnt have any problems when both of the endopoint were directly
>> connected public IP..
>>
>
> You haven't given us much info to work with. Clarification would be
> beneficial.
>
> Which interfaces are used as tunnel endpoints at each site?
>
> Which interfaces are "ip NAT inside" and "ip NAT outside" at each site?
>
> Don't think you want a tunnel endpoint being an "ip NAT inside"
> interface.
>
>
> On which interfaces are the crypto maps applied at each site?
>
> Have the crypto ACLs been changed to reflect the new tunnel endpoint(s)?
>
> Are you using ESP transport mode or tunnel mode?
>
> Think you probably want to be using ESP Tunnel mode.
>
>
> Is the tunnel endpoint networks included in your dynamic routing?
>
> May need to revisit the recursive static route based on your answers.
>
> It would be helpful if you shared some addressing info, even if you had
> to modify them somewhat for privacy.
>
>
> When we were using loopback interfaces as tunnel endpoints on our NAT
> edge routers:
>
> * We created loopback interfaces to specifically handle this traffic.
> They were NOT configured as "ip NAT inside" interfaces.
> * We advertised the loopback networks via our dynamic routing protocol.
> * We created static routes to the far side loopback networks via the
> edge routers next-hop-routers (ISP gateway).
> * We amended our crypto maps to reflect the new tunnel endpoint addresses.
> * We applied the crypto maps to the edge router's external interfaces.
> * We used an ESP Tunnel mode IPSec tranform.
>
> Best Regards,
> News Reader

Best Regards,
News Reader

Similar ThreadsPosted
ASA as VPN Endpoint April 11, 2008, 10:03 am
Pix as ipsec endpoint only? April 27, 2005, 4:40 pm
IPSec/PAT through PIX 6.3(3) to remote endpoint February 23, 2005, 4:50 pm
tunnel, ospf problem November 15, 2004, 5:53 am
IPSec Tunnel Problem December 21, 2004, 3:23 pm
SAP R/3 login problem through tunnel February 22, 2006, 11:19 am
IPSec Tunnel problem, need help !! January 2, 2007, 4:54 am
L2TP tunnel problem July 9, 2007, 12:40 pm
Problem with GRE tunnel not coming up January 20, 2008, 2:54 am
opsf over ipsec tunnel problem January 24, 2008, 6:31 am

other useful resources:
The Federal Communications Commission (FCC)
Telecommunications Industry Association
Electronic and Software Security Products and Services
International Telecommunication Union

Custom CGI Perl and PHP programming by 1-Script.com

Contact Us | Privacy Policy
The site map in XML format XML site map