Cisco NAT Query

Associate
Joined
5 Oct 2004
Posts
1,647
I have a bit of a NAT puzzle and hoping someone can help me out

I have a vpn between SiteA and SiteB, SiteA is on 192.168.0.0/24 and SiteB is on 172.16.0.0/22

I need to send traffic on a specific port through the VPN tunnel and have the oruter at the other end forward it to another IP address

So SiteA sends a packet destined for 172.16.0.1 on Port 123 for example, when the router receives that I want it to forward traffic for Port 123 to 172.16.0.2:123. Is it feasible to achieve this

I am using Cisco 877 routers

Thanks in advance
 
I'm a bit confused as to why you would want this.... Off the top of my head i don't think it's possible, but there may be other ways to achieve the same goal if you explain the issue more.

Most people would ask why you can't just connect to 172.16.0.2:123.
 
Because of the way our bespoke application works.

There is a reciever at the remote site 172.16.0.2 with 5 adsl pipes at each site. The application has been written with the view of using each pipe in turn to send data thereby load balancing. The way the developer wrote it he assumed that the data would get sent to a router and then port forwarded which would be fine if we sent it over the net and used external IP's but we're not doing that at this stage, the application has a list of 5 IP addresses to send to but there is only 1 reciever at the remote site.

I can let the reciever have 5 IP's but I'd like to avoid that if I can

It's confusing I know
 
You should be able to do this - just use port forwarding? I can do it on a lowly Netgear, so would presume the Cisco can do it. We just set up a PIX firewall to do just this sort of thing - port forwarding RDP (Port 3389) onto a particular server...
 
You should be able to do this - just use port forwarding? I can do it on a lowly Netgear, so would presume the Cisco can do it. We just set up a PIX firewall to do just this sort of thing - port forwarding RDP (Port 3389) onto a particular server...

There is no port forwarding as there is no NATing. It's an IPSEC VPN, so the traffic is not translated. I'm trying hard to think how it can be done, but no having any luck yet (useless brain :()
 
Why not just policy route on router B, to forward all traffic from 192.168.0.0/24 on port 123, to 172.16.0.2?

Or on router B, traffic with a destination of 172.16.0.1 on port 123, gets policy routed to 172.16.0.2

This way, all traffic on port 123 from the remote subnet gets forwarded to your receiver..
 
Last edited:
Option A:

on Router B, make an access list..

access-list 101 permit tcp any host 172.16.0.1 eq 123

then a route-map to do the policy routing

route-map PBR permit 10
match ip address 101
set ip next-hop 172.16.0.2


Then apply this to the interface where the traffic is coming from, in your case it might be dialer1 or a serial interface:

interface serial 0
ip policy route-map PBR




If the VPN is encrypted with IPSEC, you may have issues with the PBR, as i'm not sure whether the route-map will examine the traffic as it hits the inbound interface, before or after its decrypted by the crypto map.
 
thanks for that V-Spec, the bit that confuses me is that the original packet will be sent to 172.16.0.1:123 by setting that next root hop will that change the packets destination ip address header to .2?
 
thanks for that V-Spec, the bit that confuses me is that the original packet will be sent to 172.16.0.1:123 by setting that next root hop will that change the packets destination ip address header to .2?

The router will simply force the packet to wherever 172.16.0.2, it won't alter any source or destination addresses, the router is simply interfering with normal routing/switching, and is sending it to the address specified in the route-map, which is your receiver..
We used to do something similar years ago for Wireless traffic, we used to PBR all wireless traffic to a different box <wan optimiser> on the same subnet, it worked fine.
 
The router will simply force the packet to wherever 172.16.0.2, it won't alter any source or destination addresses, the router is simply interfering with normal routing/switching, and is sending it to the address specified in the route-map, which is your receiver..
We used to do something similar years ago for Wireless traffic, we used to PBR all wireless traffic to a different box <wan optimiser> on the same subnet, it worked fine.

The only problem is, the packet will still have the same destiantion address. Even if the packet is "forced" to the server, the server will reject it as it does not have that destination IP address, in fact nothing does. The actual destination address in the packet needs to be changed.
 
Back
Top Bottom