cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3785
Views
5
Helpful
9
Replies

Force ALL traffic through VPN tunnel

networking
Level 1
Level 1

Hi All,

I've got 3 offices linked together with IPSec tunnels running on 2811 Routers.

I need to configure this so that from the two branches, the default route is down the VPN tunnel to the Main site, rather than out to the internet.

I traied configuring the Access-lists for the VPN traffic to be:

ip access list branchA_2_Main

permit ip <branchnetworks> any

and

ip access list Main_2_BranchA

permit ip any <branchnetworks>

But if I do this the isakmp fails.

We have this working for our remote VPN users who connect to a VPN3005, but the site-site is eluding me...

Can anyone please advise how I can achieve this?

9 Replies 9

Jon Marshall
Hall of Fame
Hall of Fame

Hi

Did the VPN tunnels work before and you have just updated the crypto access-lists or are these new VPN tunnels.

Is it definitely failing on Phase 1 (ISAKMP) ? If it is then it suggests it is not the access-list as the remote and local networks only come into play on Phase 2 (IPSEC).

Jon

The tunnels work absolutely fine if I don't have an 'any' in the access list.

They definately fail during phase 1.

e.g. if my access list from the main site is

permit ip

permit ip

permit ip

permit ip

permit ip

permit ip

permit ip

permit ip

permit ip

With the access-lists mirrored at the other end, then it works fine, but if I change it to

permit ip any

permit ip any

permit ip any

Then isakmp fails.

I spent about 2 days on and off trying to get this to work, and eventually had a brainwave.

If you use an 'any' entry anywhere in your VPN access-list, the tunnel just refuses to come up.

However, I managed to get it working by splitting 0.0.0.0/0 in two.

i.e. 0.0.0.0/1 & 128.0.0.0/1

So:

(Branch = 192.168.1.0/24)

ip access-list extended ACL_Main2Branch

permit ip 0.0.0.0 127.255.255.255 192.168.1.0 0.0.0.255

permit ip 128.0.0.0 127.255.255.255 192.168.1.0 0.0.0.255

ip access-list extended ACL_Branch2Main

permit ip 192.168.1.0 0.0.0.255 0.0.0.0 127.255.255.255

permit ip 192.168.1.0 0.0.0.255 128.0.0.0 127.255.255.255

Yay! I did it myself!

Someone rate me please, I can't do it myself :-)

Just wondering since you are sending all traffic through the tunnel are you finding the remote sites complaining of latency when browsing the internet?

Hi, They don't go on the Internet at this time, so no way of knowing, but when our remote users connect, all their traffic is forced in this manner and their Internet access is fine.

We also push all internet traffic through a web caching server, so this tends to speed things up.

Hi,

Congratulatiosns mate, you found out an interesting workaround. It seems a bit creepy but hey, if it works, who cares.

By the way, I think a better way to write your above access lists would be:

ip access-list extended testacl_main2branch

permit ip

ip access-list extended testacl_remote2branch

permit ip

E.G. : Consider you have 192.168.1.0/24 on Remote branch and 192.168.2.0/24 on Main branch. The ACL would be:

ip access-list extended testacl_main2branch

permit ip 192.168.2.0 0.0.0.255 192.168.1.0 0.0.0.255

ip access-list extended testacl_remote2branch

permit ip 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255

I think it is always a good idea to explicitly configure the networks protected by IPSEC. They are a lot neater to understand and troubleshoot.

Tell me what you think?

Good Luck,

* Please rate this post if you find it helpful.

Hello,

This would be unsuitable for us as we want ALL traffic from the branch to go down the tunnel to the main.

haroon.shaikh
Level 1
Level 1

Greetings Mate,

Check out your crypto isakmp configurations, especially the transform sets.

If your phase 1 has failed, something's must be wrong there. Also, make sure you have same crypto isakmp configurations on both ends (on your branch and main site).

Also, check out for ACL's. Sometimes I have come up on devices where ACL's are the culprit when everything is correct. A good idea would be to remove ACL from the interface for a while and check your VPN configurations.

Also, yes you can use 'any' word in ACL, but make sure you have the opposite ACL on the other end.

Good Luck,

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

PLEASE RATE THIS POST IF YOU FIND IT HELPFUL

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

Hi, Nothing wrong with the crypto setup, or transform sets or anything, the culprit was definately the 'any' entry in the access-lists.

i.e. if access list was:

ip access-list extended ACL_Main2Branch

permit ip any 192.168.1.0 0.0.0.255

ip access-list extended ACL_Branch2Main

permit ip 192.168.1.0 0.0.0.255 any

Then this does not work.

Replace any with 0.0.0.0 128.255.255.255 & 128.0.0.0 128.255.255.255 and it comes straight up.

'any' is definately the culprit.

After further testing it may not be the isakmp that was causing the issue, as after a config wipe and reload, I was getting the same symptom (Tunnel would not come up if there was an any in the ACL) but this time I wasn't getting any isakmp debug errors.

PIXs,ASAs & FWSMs may be different but on the 2811's I'm using, 'any' in the access-list just doesn't work.

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: