3002 hardware client behind a DSL router

[jwbj]

This one has me scratching my head a bit.

Keep in mind I have not laid my hands on any of the gear described here nor have I even been to the site in question.

Here is the scenario...

A dsl router with one public port/IP facing the Internet and two ports on an RFC 1918 subnet

A Cisco 3002 VPN harware client with one interface on the same RFC1918 subnet as the DSL router and a second interface on a seperate internal RFC1918 subnet.

A Linksys FW with one interface on the same RFC1918 subnet with the DSL router and the first interface of the Cisco 3002 and another interface on the internal RFC1918 subnet allong with the second interface of the Cisco 3002.

A VPN tunnel exists between the Cisco 3002 and a Cisco VPN concentrator at another location. Both have the peers defined with routable IP's. The peer IP defined on the far end concentrator would obviously be the public IP assigned to the DSL router at the site in question.

The hosts on the internal private network have a default gateway of the Linksys. The Linksys has a default gateway of the DSL router and a static route pointing to the Cisco 3002 for an IP subnet at the other end of the VPN tunnel.

It is obvious how the client initiated access to the other end of the tunnel works.

Now for the head scratching..

Bear in mind the only routable IP in this entire scenario is assigned to the public interface of the DSL router and it is doing many-to-one NAT and knows nothing about VPN tunnels.

Print jobs are being initiated from the far end location to printers at this site and they are working. Initiated from the far end is key here.

Given that the peer IP as defined on the far end concentrator is the public IP of the DSL router, once a frame gets to the DSL router how is it making it to the Cisco 3002.

 

[Ru55ell]

Is the VPN working?

 

[burtsbees]

The DSL router at your end is translating the address of the public IP into the RFC1918 private IP on the 3002 to the clients via NAT overload (PAT, or many-to-one NAT). The concentrator has a feature called RRI (reverse route injection) so that the far end and your end can route back and forth---the 3002 has RRI also---this is needed for IPSec VPN's, because IPSec and NAT won't cooperate with eachother without it. Is this what you are asking?

Burt

 

[jwbj]

Burt,

Actually, the confusion comes in because the DSL router has two paths into the backend network.
One is the 3002 the other is the Linksys.

Due to the fact that the far end concentrator has the public IP of the DSL router as its peer any connections initiated from the far end office would be new inbound connection attempts rather than an existing flow.

Since the DSL router knows nothing about the tunnel and given the fact that this is a new inbound connection destined to that public IP, how would the DSL router know to forward these frames correctly to the 3002 rather than the Linksys.

 

[burtsbees]

So...you know that the IP being assigned to peers on the far end are NOT IP addresses that have been translated by your near end concentrator? I don't understand why the far end peers, as in computers behind the concentrator, are getting the public IP address of the near end dsl router...

Burt

 

[jwbj]

Burt,
The question has been answered at this point but thanks for your input.

 

[burtsbees]

I'm sorry---I was just a bit confused about the question.

Burt