08-24-2017 12:11 PM - edited 03-12-2019 04:30 AM
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!
Solved! Go to Solution.
08-25-2017 07:13 AM
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
08-24-2017 12:41 PM
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.
08-24-2017 01:07 PM
<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.
08-24-2017 01:20 PM
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?
08-25-2017 04:52 AM
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.
08-25-2017 07:13 AM
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
02-07-2019 08:34 AM
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide