10-09-2007 03:23 PM - edited 03-05-2019 06:59 PM
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
10-10-2007 02:44 AM
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
10-10-2007 05:35 AM
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
10-10-2007 05:54 AM
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
10-10-2007 06:11 AM
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.
10-10-2007 06:27 AM
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
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: