Solved: Secure routing between a LAN interface and mGRE tunnel

mike.rootvik · ‎02-25-2009

I have a remote site router that provides access for both employee general network access to internal resources and the Internet and provides access for student systems access to other training systems and the Internet via our main office site.

Currently the student network access is issolated by ACL's applied at the inbound LAN interface.

I would like to modify this configuration by extended an mGRE tunnel from our central student network to the remote site router and then force traffic from the remote student network and the central student network (as well as Internet traffic) to have to traverse the tunnel - and traffic from the central student network arriving vi the tunnel to only be sent out the Student network LAN interface.

I can see using Policy based routing applied to both the LAN interface and the tunnel to accomplish this, but would like to see if there are better methods to accomplish this.

My main concern is that traffic to\from the tunnel and student LAN interface can not manage to access any other network(s) then the Studeent network.

I can provide psuedo confings if necessary, but would mostly like ideas on how to correctly design the access process.

Thanks

Laurent Aubert · ‎02-26-2009

Mike,

This link is the closest information I found on CCO but I admit it's not the best one..

http://www.cisco.com/en/US/docs/ios/12_2sb/12_2sba/feature/guide/vrflite.html

We are talking here about one VRF for student network and keep the default routing table for employees network so there is no scalability issue with your current hw.

So the implementation should look like this:

- Create a VRF on the remote RTR and the main-office routers

- Split your WAN into two different sub-interfaces

- On the remote RTR, add one of the WAN sub-interface and G0/1 into the configured VRF

- On the main-office router, add the same WAN sub-interface and the interface connected to the main-student RTR into the VRF

- Make EIGRP VRF aware so you will have EIGRP adj on both sub-interfaces

- Nothing to change on the main-student

AT the end, EIGRP running in the default routing table will announce only the employees network and EIGRP running in the VRF only the student network. This way employees and student are not sharing the same routing table anymore so you don't need the inbound ACL as the default routing table will not have any route to join the student network and the VRF will not have any route to join the employee network.

HTH

Laurent.

View solution in original post

Laurent Aubert · ‎02-25-2009

Hi Mike,

A diagram about your current design and the target one would be very useful to better understand what you want to accomplish.

Thanks

Laurent.

mike.rootvik · ‎02-25-2009

I've addtached a before and after diagram. The config I'm looking ofr is for the Remote-RTR router to support forcing access between the remote Student network and Main student network to have to travel accross the Tunnel. Traffic emerging from the tunnel at Remote-RTR would also have to be forced out the Student network interface on Remote-RTR.

Thanks

Laurent Aubert · ‎02-26-2009

Thanks Mike for the diagram, it helps a lot for the understanding !!!

If I understand correctly, you want complete isolation between student and employees traffic. Also Employee traffic should never reach Main-Student RTR.

If you want to rely on your existing Tunnel0, its tunnel source address must be reachable from the remote RTR. Same thing with the tunnel source you want to use on the remote RTR. Then run EIGRP inside the tunnel and stop announcing student network in EIGRP XX. If EIGRP YY is already running on Tu0, you can also remove EIGRP YY on the main-office RTR

If remote-RTR learn 172.18.x.y only from the tunnel and if Main-student RTR learn 172.16.x.y only from the tunnel, you are sure the student traffic will use this tunnel. The point is you are still sharing the same routing table on the remote RTR with the employees network so you still need the ACL to avoid any traffic leaking.

If you are looking for complete isolation, I would go with VRF-lite on the Remote and main-office RTR (not needed on the main-student RTR) but it will require to create sub-interfaces on the WAN via FR encapsulation.

The VRF-lite feature allows you to create virtual-routers on the same physical box.

HTH

Laurent.

mike.rootvik · ‎02-26-2009

Thanks laaubert,

Can you recommend a good white paper on VRF-lite? Can you give any rule of thumb information with regard to memory\proc overhead for running VRF-lite on a router? fyi: I have 2821 w\256Mb routers at the remote sites and 7206 w\512Mb routers in the main office.

Thanks

Laurent Aubert · ‎02-26-2009

Mike,

This link is the closest information I found on CCO but I admit it's not the best one..

http://www.cisco.com/en/US/docs/ios/12_2sb/12_2sba/feature/guide/vrflite.html

We are talking here about one VRF for student network and keep the default routing table for employees network so there is no scalability issue with your current hw.

So the implementation should look like this:

- Create a VRF on the remote RTR and the main-office routers

- Split your WAN into two different sub-interfaces

- On the remote RTR, add one of the WAN sub-interface and G0/1 into the configured VRF

- On the main-office router, add the same WAN sub-interface and the interface connected to the main-student RTR into the VRF

- Make EIGRP VRF aware so you will have EIGRP adj on both sub-interfaces

- Nothing to change on the main-student

AT the end, EIGRP running in the default routing table will announce only the employees network and EIGRP running in the VRF only the student network. This way employees and student are not sharing the same routing table anymore so you don't need the inbound ACL as the default routing table will not have any route to join the student network and the VRF will not have any route to join the employee network.

HTH

Laurent.