How to route internet traffic over a site-to-site vpn

IM-Design · ‎02-23-2009

Greetings,

I would like to route some selected traffic from our lan to the internet over a site-to-site VPN.

The 2 ends of the site-t0-site VPN are an 1811 router and a 2811 router.

What do I need to do to configure each end of the tunnel so that this selected internet traffic is routed through the VPN before getting to the internet and then back through the VPN?

TIA

Richard Burts · ‎02-23-2009

Charles

There are some aspects of your environment which you have not told us about, especially to be specific about whether each router has its own path to the Internet. Also it would be helpful to know what kind of traffic you want to send through the VPN - is it based on certain destination addresses or is it based on some other classification such as all HTTP traffic?

But in general the answer is that one of the things that you do in configuring site to site VPN on IOS routers is that you configure access lists which identify what traffic should be protected by IPSec. As traffic goes out the outside interface any traffic that matches the access list will be processed by IPSec and sent through the VPN. So if the access list were to match certain destination addresses or if it were to match all HTTP traffic, then that traffic would go over the VPN instead of going the normal path to the Internet.

A slightly different appraoch might be to set up a GRE tunnel in conjunction with the IPSec VPN. Then you could route certain traffic over the GRE tunnel (might involve Policy Based Routing if you wanted to send all HTTP traffic) and that traffic would go through the VPN. If you wanted to send traffic based on destination address you might have static routes for those destination addresses or you could run a dynamic routing protocol over the GRE tunnel and let it advertise the destinations that you want reached through the VPN. I have implemented this concept of a routing protocol over the GRE tunnel for some customers and it works pretty well. In this kind of approach any traffic going through the GRE tunnel is encrypted and sent to the peer and all traffic not going through the GRE tunnel would just be sent out the outside interface to the Internet.

HTH

Rick

HTH

Rick

IM-Design · ‎02-23-2009

Thanks for the reply.

Yes each router has its own path to the internet. The traffic that I want to send through the VPN would be based on certain destination addresses (24.34.159.167 is one I could use as an example).

As you can see from the attached show runs, I have configured access lists on both SiteA (1811) and SiteB (2811) routers to identify which traffic.

I am not certain if either of these routers is using a GRE tunnel but I believe the tunnel is ipsec.

Would you be able to suggest the commands I should make to accomplish this change in both routers? Please assume that the traffic would be initiated at SiteA (1811).

TIA

PS having problems attaching the files. Will try in a 2nd post

Giuseppe Larosa · ‎02-23-2009

Hello Charlie,

if use GRE transported in IPsec packets

and if you mean specific IP address destination you need

static routes pointing to the GRE tunnel

if the criteria is a combination of other factors including protocol type and source address you can use PBR

policy based routing to divert traffic to the VPN tunnel.

If you have only IPsec without GRE I would move to GRE + IPsec to achieve the desired flexibility.

the tunnel GRE can be addressed as an outgoing interface, a crypto map cannot and you would some trick to do this and also you need to modify the ACLs that define traffic to be encrypted

Hope to help

Giuseppe

Richard Burts · ‎02-23-2009

Charles

Thanks for the additional information. It is helpful to know that each router does have its own path to the Internet and that traffic will be identified by destination address. Without seeing the configs it is difficult to suggest what you should do. There may be advantages to implementing the GRE tunnel as Giuseppe suggests. But it should be possible to implement this without the GRE tunnel.

The main thing that you need to do is to make sure that the access list that you have configuerd to identify the traffic to be protected by IPSec does have a permit for those destination addresses that you want to send via VPN. And you want to be sure that the traffic to these destinations exits the router on the interface where the crypto map is assigned. (I tend to assume that in situations like this that there is a single exit interface, but without the configs we can not be sure)

If the traffic going out the exit interface matches the access list then it should be processed by IPSec and forwarded to the peer rather than being sent out to the Internet.

HTH

Rick

HTH

Rick

IM-Design · ‎02-23-2009

I thought I had succeeded earlier in posting the configs, but here they are now.

Richard Burts · ‎02-23-2009

Charles

I have looked at the configs and I have these comments:

- there are fewer issues with the config of the 1811 so I will start there.

- the 1811 uses access list 102 to identify traffic to be protected by IPSec. If you add permit statements for the additional destinations whose traffic should go through the VPN then traffic to those destinations should go through the VPN tunnel and not directly to the Internet.

- I am not sure why you want to send traffic for those destinations through the VPN. I do not see anything on the peer router that will do anything except route them to the Internet. But perhaps this is part of some policy that is not evident to us.

- the router has 6 subnets on inside interfaces (VLANs). Only 3 of these will be protected by the VPN. Perhaps there is some reason why only 3 of 6 subnets will be protected by the VPN which has not been made known to us.

- on the 2811 the situation is more complex.

- I can not find any entry in the crypto keys or in the crypto map whose address matches the address used on the 1811. From working through the logic of the access lists I assume that it must be this entry:

crypto map SDM_CMAP_1 1 ipsec-isakmp

description Tunnel to 80.152.178.152

set peer 80.152.178.152

but the mismatch of address is an issue and I do not understand how the VPN will work.

- there is a mismatch in access lists between the routers. On the 1811 there are 3 subnets permitted in the access list but on the 2811 there are only 2 subnets permitted. The mismatch in access lists will impact performance of the VPN.

- as you add entries in the access list of the 1811 for traffic going through the VPN you need to make corresponding entries in the access list on the 2811.

- the static default route is somewhere between not optimum and a problem. It is:

ip route 0.0.0.0 0.0.0.0 FastEthernet0/0

the issue is that any static route specifying the outbound interface and where the outbound interface is Ethernet then the router must ARP for each individual destination address. And it will only work if the next hop router (probably the ISP) enables proxy arp. If proxy arp is not enabled then the router will not be able to route outside. It would be much better to specify the next hop address (as you do on the 8111).

HTH

Rick

HTH

Rick

IM-Design · ‎02-24-2009

Thanks for the response Rick,

I made the change to the 1811 access lists as follows:

10 permit ip 10.2.100.0 0.0.0.255 192.168.0.0 0.0.0.255 (10997190 matches)

13 permit ip 10.2.100.0 0.0.0.255 host 24.34.159.187

20 permit ip 10.2.130.0 0.0.0.255 192.168.0.0 0.0.0.255 (1250758 matches)

30 permit ip 10.2.150.0 0.0.0.255 192.168.0.0 0.0.0.255 (44 matches)

Extended IP access list 103

10 deny ip 10.2.100.0 0.0.0.255 192.168.0.0 0.0.0.255 (9273408 matches)

13 deny ip 10.2.100.0 0.0.0.255 host 24.34.159.187 (77 matches)

20 permit ip 10.2.100.0 0.0.0.255 any (7725612 matches)

30 deny ip 10.2.130.0 0.0.0.255 192.168.0.0 0.0.0.255 (589369 matches)

40 permit ip 10.2.130.0 0.0.0.255 any (2817181 matches)

50 deny ip 10.2.150.0 0.0.0.255 192.168.0.0 0.0.0.255 (44 matches)

60 permit ip 10.2.150.0 0.0.0.255 any (540122 matches)

On the 2811 I made what I thought was the correct corresponding change:

Extended IP access list 103

10 permit ip 192.168.0.0 0.0.0.255 10.2.100.0 0.0.0.255 (15366234 matches)

13 permit ip host 24.34.159.187 10.2.100.0 0.0.0.255

20 permit ip 192.168.0.0 0.0.0.255 10.2.130.0 0.0.0.255 (7385857 matches)

Extended IP access list 104

10 deny ip 192.168.0.0 0.0.0.255 192.168.4.0 0.0.0.255

20 deny ip 192.168.0.0 0.0.0.255 10.1.10.0 0.0.0.255 (4262075 matches)

30 deny ip 192.168.0.0 0.0.0.255 10.1.60.0 0.0.0.255 (1898381 matches)

40 deny ip 192.168.0.0 0.0.0.255 192.168.1.0 0.0.0.255 (888 matches)

50 deny ip 192.168.0.0 0.0.0.255 10.1.20.0 0.0.0.255

60 deny ip 192.168.0.0 0.0.0.255 10.2.100.0 0.0.0.255 (8376355 matches)

63 deny ip host 24.34.159.187 10.2.100.0 0.0.0.255

70 deny ip 192.168.0.0 0.0.0.255 10.2.130.0 0.0.0.255 (4492392 matches)

80 deny ip 192.168.0.0 0.0.0.255 10.2.200.0 0.0.0.255 (9084996 matches)

85 deny ip 192.168.0.0 0.0.0.255 192.168.5.0 0.0.0.255 (61260821 matches)

90 permit ip 192.168.0.0 0.0.0.255 any (1361605 matches)

Now I am no longer able to ping the 24.34.159.187 address from a machine on the 10.1.200.0 network.

What am I missing?

Richard Burts · ‎02-24-2009

Charles

The changes that you describe are for traffic from 10.2.100.0. The problem you describe is for 10.1.200.0. I do not see how that would be related to the changes that you made.

HTH

Rick

HTH

Rick

IM-Design · ‎02-25-2009

Hi Rick,

My mistake (typo) in the earlier response.

I am not able to ping that address from a machine on the 10.2.100.0 network, NOT the 10.1.200.0 network.

Can you confirm that I have made the correct changes to the acl on the 2811? I made these entries as 'corresponding entries' to the changes made on the acls on the 1811, but I am not clear on how the traffic is flowing and whether the entries on the 2811 acl cause the traffic originated at the 1811 for that specific ip address to be returned to the 1811 via the tunnel?

Also, do I need to make any changes to the default routes on either router?

TIA

Richard Burts · ‎02-25-2009

Charles

I can not tell much when you talk about corresponding entries. If you will post the access lists from the running config then we will know what we are dealing with. And it might be easier if you just post both running configs so it will be easier to see the context that the access list is working in.

In a previous post I suggested changing the static default route on the 2811. A static route specifying only the outbound interface, when the outbound interface is Ethernet, may work or it may not work. And that is dependent on whether the next hop router has enabled proxy arp. And if it does work it will make the router work harder since the router will need to ARP for every unique destination address which uses lots more CPU cycles and results in much larger ARP tables. It is better when a static route specifies the next hop address. So change the static default route and specify the next hop address.

HTH

Rick

HTH

Rick