Site to site VPN with IOS Router

[Peter.D.Brown]

I want to create a site to site VPN over the Internet. At the remote site, apart from the VPN to head office there should be no traffic allowed in from the Internet to the Internal network and there should be no traffic from the Internal network allowed to the Internet. The internal network will be running a private 192.168.x.x address range.

I'm going to use a Cisco 2811 integrated services router at the remote site and this will run an IPSec VPN which will terminate on a concentrator at head office. I understand that this router has an IOS firewall and IPS built in.

Would I be right in thinking that because I don't want to have any access to or from the Internet (apart from the VPN) that I don't need to configure any of the IOS firewall features on the router? And there'd be no point in configuring any IPS features would there?

My thinking is that just a single access list entry of deny ip any any applied inbound to the interface that connects to the Internet would be the best strategy. I believe the command 'sysopt connection permit-ipsec' should allow the VPN to form even with the deny ip any any ACL (or is this just a Pix command? If so then I'd have to permit ESP and UDP 500 (ISAKMP) from the public address of the concentrator at head office to allow the VPN to form wouldn't I?).

Thinking about it I'll probably expand the access list slighty to allow icmp, ssh and https traffic from the head office external firewall IP address so that I can monitor the remote site and get to it securely should the VPN fail.

And I wouldn't need an access list on the interface connected to the internal network would I because the address range would be non routable so they wouldn't be able to initiate connections to the Internet (all trffic at the remote site would be specified as interesting traffic to bring up the VPN)

Using any of the IOS firewall inspect commands or the IPS would be pointless and have no effect in this situation wouldn't it?

I really just need to know if the deny ip any any ACL on the outside interface at the remote site is the best option (and simplest), and if it will be secure.

We used to use Pix fiewalls for remote site to site VPNs, awhich deny inbound connections on the outside interface by default but now I've been told that these 2800 series routers will be used from now on so I'd like to get my thinking straight and be able to build them securely to do the same job as all the existing Pixs are currently doing (they're all installed for just the VPN connection to head office as in the first paragraph).

I'd appreciate any advice or thoughts on the subject. I'm sure there must be a ton of people who have set routers up for the same purpose.

Thanks in anticipation.

Pete.

[Richard Burts · Accepted solution]

Pete

I have done a lot of site to site VPN implementations using IOS routers. They work very well. Based on my experience I offer these comments and hope that they will help you:

- you do want an access list inbound on the outside interface, but you want more in it than just deny ip any any. There is no sysopt connection permit-ipsec in IOS so you will certainly want to permit ISAKMP and IPSec/ESP. I suggest that you also want to allow SSH. I like to allow ICMP but only from the address space of the head end network. I do not allow HTTPS since I usually do not enable the http server on the router. If you want HTTPS then certainly allow it. To facilitate ping and traceroute from the remote I frequently allow icmp echo-reply, time-exceeded, and port unreachable from any source.

- I like to put an access list on the inside interface. There are certain types of traffic which I may not want to send from the remote LAN. I usually deny any SNMP or snmp trap from LAN devices and deny icmp redirects coming off the LAN. I also frequently configure RPF checking on the inside interface to catch any device that is misconfigured.

- if you are going to allow SSH when the VPN is not active (and I highly recommend that you do) then you probably need to configure at least 1 (and perhaps several) users ID and password on the router. And you want to configure authentication on the vty to use local authentication if the authentication server at the head end is not available.

- I am not clear from your description whether you plan to run a dynamic routing protocol over the VPN. I like to have a dynamic routing protocol because I use it to advertise a default route to the remote over the VPN. I do not locally configure a default route on the remote router. That way if the VPN tunnel is up there is a default route pointing over the tunnel and if the VPN tunnel is not up then there is no local default route and users at the remote can not access the Internet. This is a simple and highly effective method of assuring that all user traffic must go through the central site.

- in terms of routes defined on the remote router, my approach is that I define a static route to the tunnel end point to allow the tunnel to establish and I configure static routes to the subnet at the head end from which I may SSH. And I do not configure other local static routes on the remote router.

- you probably want to disable cdp on the outside interface and also to disable proxy-arp (and I like to do no ip unreachables).

- there is frequently an issue when using VPN site to site with fragmentation. If a device on the LAN sends a maximum size frame, and then the router needs to add the extra headers for IPSec then the frame is too large and requires fragmentation. I like to use ip tcp adjust-mss to control segment size for TCP traffic and avoid any issues with fragmentation.

- I do not think that you want to implement any of the firewall or IPS features of the IOS on the 2811.

I hope your implementation goes well and that my suggestions may have been helpful.

[edit] after posting my response I read through your post again and realize that you are doing VPN to a concentrator. The approach I that suggested about running a routing protocol works for me because I usually have an IOS router at the head end. It would not work for connecting to a concentrator.

HTH

Rick

[Peter.D.Brown]

Hello Rick,

thanks for the advice, it was extremely helpful. I won't be running a routing protocol. Previously we'd had a default route on the remote site but like you say, there would be extra security to be had by just putting a host route to the head end and a route to the head office networks, then no traffic could get out that wasn't destined for these. I've just read a Cisco document (IPSec VPN WAN Design Overview) which talks about fragmentation and various issues to deal with it and it seems that on newer IOSs that a feature called Look Ahead Fragmentation is enabled by default which deals with VPN fragmentation issues. Have you heard of this? Would there be any need for the tcp mss if LAF is enabled? Here's a link to the document, it has a large section on fragmentation.

Cheers

Pete.

[Peter.D.Brown]

..it might help if I actually paste the link in!

http://www.cisco.com/application/pdf/en/us/guest/netsol/ns130/c649/ccmigration_09186a0080685ce6.pdf

[Richard Burts]

Pete

I found the document to be pretty interesting and with good explanations for many aspects of running VPNs. I also did some checking on Look Ahead Fragmentation and one source indicated that it worked on IPSec in tunnel mode but not for transport mode. Since a lot of my tunnels use transport mode (good for IPSec with GRE and reduces the overhead a bit) it would be less useful in some of my situations.

From another perspective I like tcp adjust-mss a bit more than Look Ahead Fragmentation. With LAF the encrypting router must detect the need for fragmentation and must do the fragmenting (before encryption). With adjust-mss it eliminates the need for fragmentation since the end stations will not send large packets that would require fragmentation. I like the alternative more of avoiding fragmentation than I do the alternative of shifting who does the re-assembly.

HTH

Rick

[glenn-mchenry]

I would like some advice if you have the time. I have been tasked with setting up a connection from a main office and a remote office. It is within the same domain but separate geographical areas. I went and purchased the Ciscopress SSL Remote Access VPN book but don't think this is what they are looking for. They (the remote site) wants to access a sub-network within our corporate area via vpn due to security issues. They also want a bastion host on each end. The only connectivity desired would be between the two bastions on each side. It would look something like:

Main ntwk ---- switch ----- bastion host---------2811 vpn rtr ---------- company infrastructure/backbone --------2811 vpn rtr ---bastion host B ------- switch B ------- geographically separate network

Would the 2811s work in this situation and are there any tips or redirects you can provide to aid in this? Would it be best to use IPSec or SSL VPN. The end site just wants to work as if it is a part of the larger network.

Thanks for your time.

Glenn McHenry

[Richard Burts]

Glenn

Given the present explanation of the requirements I would think that an IPSec site to site VPN would be more satisfactory than an SSL VPN. If there are no extra requirements beyond what you have described so far then the 2811 should work fine.

I think perhaps there needs to be some examination of what the end site really wants. You say: "The end site just wants to work as if it is a part of the larger network" but I am not sure exactly what that means (especially since the need to run through a VPN pretty clearly makes them different from the rest of the network. Is there a dynamic routing protocol for the enterprise network? If so will the end site participate in the routing protocol? Will the end site access resources in other parts of the enterprise network than the main network? Should other parts of the enterprise network access the end site? Knowing some of these things would allow you to determine whether just a plain IPSec VPN is what you want or whether IPSec VPN with GRE would be better.

HTH

Rick

[glenn-mchenry]

Basically there are currently two stand-alone networks right now, geographically separated. At each site, there is also a WAN connection to the corporate infrastructure. What they want to do is create come up with a vpn solution that can utilize the pre-existing WAN connection. They want the standalone networks to be able to share data but just between the two previous standalone networks. They also don't want anybody within the corp infrastructure to be able to access the previous standalone networks. If you could email me at glenn.mchenry@gmail.com I could go into more detail about it.

[Richard Burts]

Glenn

If there are 2 stand alone networks who want to communicate with each other over the corporate infrastructure but do not want to be open to the rest of the corporate infrastructure, then I would suggest setting up a GRE tunnel between the 2 stand alone networks (using the corporate infrastructure to carry the tunnel). I would configure a static route at each stand alone pointing to the other stand alone over the GRE tunnel (which would keep them separate from the rest of the corporate network). And then I would use IPSec VPN to encrypt the GRE traffic and provide privary and security for the traffic.

If you want to communicate more detail then my Email address is in my NetPro profile.

HTH

Rick

[glenn-mchenry]

I tried sending to your profile address but it was rejected. I will try again.