cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
668
Views
0
Helpful
6
Replies

Route overlap on a public/private split network

network
Level 1
Level 1

I'm going to be deploying a router that will have network interfaces on both our private and public networks. The public side will have N+1 uplinks, and doing ospf on those links for redundancy. This also means the router will have a full route table for our internal public network. The router will be running an ipsec connection to a firewall over the public network. Esentially the router will have the following psuedo route table:

0.0.0.0 0.0.0.0 -> ipsec.tunnel.remote.endpoint

10.10.0.0 255.255.255.0 -> public.uplink.endpoint.1

10.10.0.0 255.255.255.0 -> public.uplink.endpoint.2

192.168.1.0 255.255.255.0 -> private.lan.interface

192.168.0.0 255.255.0.0 -> ipsec.tunnel.remote.endpoint

This works fine and dandy if I want to only access equipment on my network, public or private, without nat. I'd like a bit more security than that, so the router interfaces will be acl'd such that private traffic can only be accepted on the private lan interface or via the ipsec tunnel. Infact, I'd like it so that any private lan traffic to a non private lan ip goes out through my remote universal firewall/nat box. This is how traffic will normally flow with the routes above untill I try to reach one of the public ip's on my network, at which point the routes learned from ospf are more specific than the default entry, and the router will route based on that. Is there any way to force the router to use ipsec.tunnel.remote.endpoint as a nexthop for all non-local traffic on the private lan interface

6 Replies 6

ruwhite
Level 7
Level 7

Okay, I think you have:

private net---router---"public" net---tunnel endpoint

With an ipsec tunnel running from the router, through the public net, to the tunnel endpoing. Is this correct? There are several connections to the public net, and several to the private net.

First point of confusion--is this "public net" the Internet, or connected to or through the Internet, or are we talking about a network which uses public ip addresses?

Second point of confusion: I don't understand when you say that you want all traffic destined to a "public" address to go out through the ipsec tunnel. If you have direct connection to the public network, and are tunnelling across this public network to reach another part of the private network, why would you want to route through the public network to reach the other part of the private network, and then back into the public network?

What you'd need to do is to block all the routing information from the public network on the interfaces that connect to it, other than the route to the other end of the tunnel. Then you would only learn those routes through the tunnel, through the other part of your private network. Of course, I'm not certain why you'd have "several uplinks" to the public network in that case?

Russ.W

First point - The public network is our public, fully routeable, connected to the intenet IP space.

Second point - Yeah, I was afraid my explanation wasn't the best. Kinda hard to put it down on paper sans diagrams. We have a large public IP network, as we're an ISP. We're setting up a second IP network, that is self contained, using private IPs, and on separate, non publically connected equipment for use as a private lan, to put our sensitive information and services on, such as radius/nfs/etc.

We have a remote office that we can very easily extend our public lan infrastructure to, using a couple different links to different NOCs, increasing bandwidth and providing a little redundancy. We'd like to also bring the private lan over to this office.

The normal arrangement would be a router, running OSPF/RIP/iBGP/etc to terminate the uplinks and bring the public lan to the office. You'd then hang a vpn box off that, and behind the vpn box is your private lan. The VPN box handles IPsec tunneling and bridging between the two private lan segments. Put a default route on the vpn box pointing twards a central firewall/nat implimentation at the primary private lan segment, and you now have one point of entry/exit for the private lan, and all your remote connections go through it.

I'm trying to do the same, using just the cisco router, no vpn box.

Hi,

the solution Russ offered looks good (filter out the routes you don´t want) but I am thinking that you could just use policy routing to use the ipsec.tunnel.remote.endpoint as a nexthop for all non-local traffic on the private lan interface ?

Regards,

Georg

It is very possible to do, matching on an address range through an access list, then setting the outbound interface based on that destination address.

The thing I like about route filters is they will be more "dynamic," I'd think, and adding ror removing links is simpler, and load sharing occurs more "naturally," if you will....

:-)

Russ

Okay, this makes much more sense.... Thanks. :-) I really dislike the inability to draw ascii drawings in these forums, too.... I'll have to go ask if there's a way to at least attach gif files, or something, so we can exchange network diagrams.

I'm certain you can terminate the vpn on the router with no problems. The question, then, is getting the right traffic to run across the vpn, and the right traffic to run across the public network. I'd think the easiest thing to do is to run the igp you normally run across both, block routes for the private address space on the normal interface, and then permit only routes to the private address space into the vpn tunnel.

I assume you're running OSPF, but a distribute list in will still block those routes from being placed in the local routing table, so as long as there is only one router at the remote site, then you shouldn't have any problems. You can also set up access lists, to make certain traffic doesn't flow down the wrong links, but the pure destination based routing, with a bit of filtering, should direct traffic just fine....

So, you could do something like this:

!

access-list 10 permit 10.0.0.0 0.255.255.255

!

access-list 20 deny 10.0.0.0 0.255.255.255

access-list 20 permit any

!

router ospf xx

distribute-list 20 in

distribute-list 20 in

distribute-list 10 in

Or something like that....

:-)

Russ.W

Another option just occured to me as well--are you running OSPF? I've been assuming you are.... If you are, and the router at the "core" is an ABR, You should be able to filter the type 3's running down each link, I think, to make certain the remote rotue only receives the right information. This filtering is implemented here:

http://www.cisco.com/cgi-bin/Support/Bugtool/onebug.pl?bugid=CSCdi43518

But, there's no information there on how to use it. :-)

http://www.cisco.com/en/US/products/sw/iosswrel/ps1839/products_feature_guide09186a00800b5d4f.html

Is the information on how to configure and use it. If you're using EIGRP, standard filtering will work fine on either end of the link. IS-IS will also allow you to filter information out in a similar way to OSPF, if you are using that--let me know if you are, and I can point you to the right place for that.

Russ.W

Review Cisco Networking for a $25 gift card