cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
512
Views
3
Helpful
5
Replies

Help! Routing based on source and destination addresses

arriejones
Level 1
Level 1

This isn't a VPN question, just routing.

OK here's my situation, this is a good one...

My company is a group of banks. Endusers at these different banks access a federal banking website (171.203.0.2). They access the Internet through the centralized datacenter, not locally.

To access the website, the federal bank requires that each bank go through a seperate VPN device that sets up a secure IPSec tunnel to the website. The INTERNAL IP addresses of those VPN devices are as follows:

VPN_BankA: 172.16.5.215

VPN_BankB: 172.16.5.216

VPN_BankC: 172.16.5.217

VPN_BankD: 172.16.5.218

VPN_BankE: 172.16.5.219

VPN_BankF: 172.16.5.220

VPN_BankG: 172.16.5.221

Each bank has it's own subnet, like so:

BankA: 10.32.0.0/16

BankB: 10.33.0.0/16

BankC: 10.34.0.0/16

BankD: 10.35.0.0/16

BankE: 10.36.0.0/16

BankF: 10.37.0.0/16

BankG: 10.38.0.0/16

SO....the goal is to route the packets going to the website (171.203.0.2) to the right VPN device based on the subnet the packet is coming from. I also need to perserve the source and destination IPs in the packet (no NATing).

This can probably get done with some policy based routing but I'm not that smart, you guys are. Help a brother!

Thanks,

Arrie

5 Replies 5

kerek
Level 4
Level 4

Hi,

Yes it seems that PBR can be the solution indeed. All you have to do is to configure the inside interface (facing to the banks) with PBR.

Assuming that this interface is f0/0:

interface fastethernet0/0

ip address whatever

ip policy route-map vpn

!

route-map vpn 10

match address 101

set ip next-hop 172.16.5.215

!

route-map vpn 20

match address 102

set ip next-hop 172.16.5.216

.

.

.

access-list 101 permit ip 10.32.0.0 0.0.255.255 host 171.203.0.2

access-list 102 permit ip 10.33.0.0 0.0.255.255 host 171.203.0.2

.

.

.

You have to create the remaining route-maps and acls by analogy with aboves (i.e. to match the bank's subnet and set the next hop accordingly).

Hope it helps, rate if does

Krisztian

Thanks Krisztian for your reply.

Yes I did consider puting PBR on each interface facing each bank, the problem is there are many many interfaces on this router facing the different banks. Some come in on an ATM interface with about 30 subinterfaces, some are PTP on Serial interfaces, and others come in on the LAN through the Gig interface. I really don't want all that PBR out there as this can be CPU intensive and a management nightmare as you can imagine!

So the goal is to do this with one centralized PBR. An idea I had (that doesn't work) is to create a Loopback interface, route all traffic going to 171.203.0.2 to the Loopback, then put a PBR on the Loopback to set next-hops based on the source subnet. This doesn't work for whatever reason, but maybe this can give someone else a better idea.

Thanks again, Arrie

Not a nice idea, but i think this could work

Use 2 tunnel interfaces on the same router.

Shove all traffic down one and apply the pbr as it comes out the other. Points you will need to note,

1)the IP address assignment will conflict on the tunnel interfaces. Use different subnets, IP addresses dont really matter on tunnels, what matters is the source & destination being opposite at the other end of tunnel.

2) Are the packets destined to 171.203.0.2? If , so you will have a slight problem. Because, you need to apply a static route pushing all 171.203.0.2 traffic out to tunnel1 but when it comes out via tunnel2 any traffic not matching your pbr may loop. In such a case apply a default pbr policy pushing it to null0 or a default gateway where you woild like it to go.

Let me know if it works out .

pls rate post if useful

Wow thanks lugman! Now we're getting closer.

I am not experienced at all using tunnel interfaces. Could you take a sec and throw together a little sample config? Yes all traffic going to 171.203.0.2 will match something in the PBR, no need for catch-all going to null I don't think.

int lo1

ip address 1.1.1.1 255.255.255.255

int lo2

ip address 2.2.2.2 255.255.255.255

int tunnel 1

description route packets to this tunnel

ip address 3.3.3.3 255.255.255.255

tunnel source 1.1.1.1

tunnel destination 2.2.2.2

int tunnel2

ip address 4.4.4.4 255.255.255.255

tunnel source 2.2.2.2

tunnel destination 1.1.1.1

ip policy PBR

ip route 171.203.0.2 255.255.255.255 tunnel 1

I am a bit sceptical about my own solution now. Its to do with the static route for 171.203.0.2 pointing down the tunnel. Im hoping it works,

If this fails, you will need a spare router and then terminate the tunnel on this spare router and also move the link for the 171.203.0.2 network onto this new router and apply all pbr over there.

Let me know how you get on. Ill try to find a solution for u

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: