I apologize in advance for the lengthy description, but I wanted to give an accurate picture of this scenario.
OK, here we go?
In order to address company?s need for faster and better connections we are upgrading our WAN infrastructure with some minor changes to the design. I will try to explain what I am trying to accomplish:
First, what we have today are 5 offices connected through a PIP Any-to-Any network. A central Head Quarter and 4 branch offices. At the HQ office we have a 3640 router considered our WAN router which connects to the other 4 offices (Sub-interfaces connecting to 2600 XMs at branch offices). The WAN router?s Ethernet interface is in the user LAN at HQ. This interface is the default gateway for all users stations and servers in the HQ office. The Internet connection for all offices is also located at the headquarters, so all Internet traffic from all offices goes through the headquarters. Other things to mention is a PIX 515 which sits right behind our border/Internet routers (2600XM), also 3550 L3 switches with VLANs configured on the HQ LAN.
We also have a large number of VPN users who connect to a VPN server located on the inside LAN at the HQ office. L3 switches are running EIGRP with a static route to the internal interface of the PIX. The PIX obviously has a static outbound route to the internal interface of the border routers. L3 switches redistribute static routes and advertise VLAN subnets (connected). The WAN router (the router at HQ that interconnects offices) runs both EIGRP and BGP redistributing EIGRP into BGP and BGP into EIGRP. Branch offices routers run BGP, and redistribute connected and static (static to the ISPs BGP neighbor). Each branch office router is in its own BGP AS neighboring to the ISPs AS. In this way all branch offices are aware of all subnets through BGP and the central WAN router learns routes through external EIGRP because of redistribution mentioned earlier.
OK ? Now the upgrade: The project consists of switching to another ISP, upgrading the Internet connection with a bigger pipe and adding a separate T1 just for VPN. This is where my question comes in:
Since the VPN pipe will be physically a separate line, I have to figure out a way to make sure that when a VPN user connects to the VPN server, its outbound traffic uses the same link from which it came from (the VPN-T1 and not the Internet-T1). This is, in order to avoid the so called asynchronous connection problems. I have to add that the VPN users use a wide variety of tools and apps when connected, including RDP, NetBios, third party VPN clients (yes they VPN in and then they VPN out!). So, in brief I have to make sure both inbound and outbound VPN traffic enters and leaves from the same T1 line. Obviously the VPN ? T1 line will have its own router and most likely separate PIX, because of obvious security issues. Putting the VPN server in DMZ is out of question because of Windows authentication required.
Yes - A route-map on L3 switches was my first approach too - Obviously this requires that the VPN users be assigned to a separate subnet, which is not a problem, although there are still some challenges. For example some VPN users may connect to servers in the server VLAN using RDP. Some of these servers are Toolkits - These Toolkits are then used for outbound connection to remote clients for support purposes. I'm trying to understand if this is going to work at all or do we need to make some changes before implementing.
We are still several weeks away from the implementation so I have time to brainstorm (daily workload permitting).
Even though it seems like PBR is the way to go, any other options mentioned is greatly appreciated.
I agreed w/ Edison to use PBR is a better and simple solution. Seems there is separated router for VPN but this router will still connect to the production router (WAN router), so the PBR should be configured at the WAN router because this the GW for all local users & server. Then control the routes at VPN router that will not affect the routing at WAN router. i.e. VPN router simple carry forwarding if there is traffic from VPN server to the VPN-T1.
Once the application are tunnelled in the VPN then it should work because the PBR will based on the VPN server to forward the traffic to VPN connected router.
We are pleased to announce availability of Beta software for 16.6.3.
16.6.3 will be the second rebuild on the 16.6 release train targeted
towards Catalyst 9500/9400/9300/3850/3650 switching platforms. We are
looking for early feedback from customers befor...
Introduction Featured Speakers Luis Espejel is the Telecommunications
Manager of IENova, an Oil & Gas company. Currently he works with Cisco
IOS® and Cisco IOS XE platforms, and NX to some extent. He has also
worked as a Senior Engineer with the Routing P...
In this session you can learn more about Layer 3 multicast and the best
practices to identify possible threats and take security measures. It
provides an overview of basic multicast, the best security practices for
use of this technology, and recommendati...