cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3523
Views
0
Helpful
6
Replies

Site to Site ipsec Routing help

Road_Warrior
Level 1
Level 1

Hello,

I have a requirement to provide site to site connectivity as a backup solution. I have this working perfectly fine. The routers Default Gateway points outward towards the internet.

 

My 2nd requirement is to allow internet access for these remote users, but it needs to go through a corporate firewall and not out the directly attached internet interface. 

 

My thought was to point the DG inward towards the internal production network and use the corporate firewall, and create a static route for the the remote peer outward towards the internet.

 

This appears to not work as I get a ttl expired going to the remote site's client segments.Although the tunnel stays connected, there is no passing of traffic. If I take out the static route for the remote peer and point the DG outwards towards the internet, everything starts working.

 

Am I missing something here? Is there a way to accomplish this in a way that eludes me?

 

Cisco IOS Software, C2900 Software (C2900-UNIVERSALK9-M), Version 15.2(4)M7, RELEASE SOFTWARE (fc2)

 

Thanks!

 

1 Accepted Solution

Accepted Solutions

Okay, So, this kind of makes no sense to me, but I did get it to work.

 

- there needs to be a static route for each network behind the peer address. (old school)

- never needed that before, I just had the DG pointing out. and it all worked bacsed on the cryptomap tied to the peer tied to the acl.

- data flows from peer to peer IP and is encapsulated within ipsec.

 

When I change the DG to point inward towards production where the internet firewall is (for user internet traffic) and add a staic route to the Peer's internet IP, it does not pass traffic to any networks behind that peer.

 

I had to add static routes for all networks and put the internet IP of the peer that houses those networks as the destination.

 

Shouldn't the static route to the peer take care of that, since the networks are defined in the cryptomap?

 

Thanks

View solution in original post

6 Replies 6

I am not sure I am following 100% but I'll attempt to assist.

 

You defined a static route on the remote router, routing 0.0.0.0 via the tunnel interface? Previously the default route for the remote router was via the internet? ....but the router itself needs a default route to establish the tunnel over the internet.

 

I assume you have a static route for the remote site subnets on the main site router, pointing to the tunnel interface?

Do you also have a static route on the main site firewall for the remote site subnets, pointing to the inside network? As the firewall needs to know how to route back to the remote site network.

 

A suggestion would be to use a fVRF on the remote site router and place the external interface into the vrf, with it's own routing table. You can then use the global routing table for the inside network (the users/computers) pointing via the tunnel.

<You defined a static route on the remote router, routing 0.0.0.0 via the tunnel interface? Previously the default route for the remote router was via the internet? ....but the router itself needs a default route to establish the tunnel over the internet.>

 

I defined a static route at the Main Site where all tunnels come into to point to a remote site's external IP, then changed the DG on that same router (main Site) to point inward for internet access for the remote sites internet connectivity via the main site.

 

<Remote>

All data goes throught the tunnel. Period. No changes Made and it currently works before attempting to make the changes at the main site

 

<Main Site>

crypto isakmp policy 10
encr 3des
hash md5
authentication pre-share
group 2

!

crypto isakmp key 6 <PSK> address R.R.R.R

!
crypto ipsec transform-set hhset esp-3des esp-md5-hmac
mode tunnel
!

crypto map hhmap 124 ipsec-isakmp
set peer R.R.R.R
set transform-set hhset
match address Test

!

interface GigabitEthernet0/0
description Inside 
ip address IP MASK
ip flow ingress
ip flow egress
duplex auto
speed auto

!

interface GigabitEthernet0/1
description Outside Internet LAN
ip address <Main Site IP/Mask>
duplex auto
speed auto
crypto map hhmap redundancy outside stateful

 

ip route 0.0.0.0 0.0.0.0 <Internet Gateway> (this is the way it is normally When working)

IP route 0.0.0.0 0.0.0.0 (Inward IP of the next Routed Interface) (THIS was added after deleting the DG above

ip route R.R.R.R <MASK> <Internet Gateway> (New Static route to gain access to the remote site's external IP)

 

ip access-list extended Test
permit ip any 192.168.154.0 0.0.0.255
permit ip any 192.168.1.0 0.0.0.255

 

That is all that was changed to test the connectivity. 

 

<Do you also have a static route on the main site firewall for the remote site subnets, pointing to the inside network? As the firewall needs to know how to route back to the remote site network.>

 

Yes. I don't get that far really, because when pinging the client at the remote site from a computer at the main site, I get TTL expiration from the inside interface of the main sites router. The one in the configuration above.

 

I appreciate all your help.

When I first read the post I assumed you were running a VTI and just routing over the tunnel interface. It makes things so much easier, imho. I've not used a crypto map for years, but do you even need to specify a route to the destination vpn subnets if it's defined in the crypto map?...therefore what subnets are defined in the remote site router's crypto map? 0.0.0.0?

It is my understanding that all routes defined in the ACL attached with the cryptomap peer address are permitted through that tunnel. There are no routes to route it down a tunnel. 

 

It is also my understanding that the tunnel is created via the external interface and all data is forwarded out that interface encapsulated down the respective tunnel.

 

It appears that the tunnel is indeed created, when the DG at the Main site points inside and the static route to the remote sites internet IP points towards the internet to make the connection. Something else happens after that connection is made that does not forward traffic down the tunnel, when the 2900 recieves the packet. At that point, the tunnel is up, but data does not flow.

 

I have to be missing something... I'm not sure what it it.

Okay, So, this kind of makes no sense to me, but I did get it to work.

 

- there needs to be a static route for each network behind the peer address. (old school)

- never needed that before, I just had the DG pointing out. and it all worked bacsed on the cryptomap tied to the peer tied to the acl.

- data flows from peer to peer IP and is encapsulated within ipsec.

 

When I change the DG to point inward towards production where the internet firewall is (for user internet traffic) and add a staic route to the Peer's internet IP, it does not pass traffic to any networks behind that peer.

 

I had to add static routes for all networks and put the internet IP of the peer that houses those networks as the destination.

 

Shouldn't the static route to the peer take care of that, since the networks are defined in the cryptomap?

 

Thanks

Sorry for the long delay. This is exactly the solution. Static routes pointing to the peer address of the destination. the data will go down the tunnel.

Thanks so much for your reply.