Allow Cisco vpn client pool down a site to site VPN

Hi there,

I was wondering if the following is possible?

I am terminating a vpn client ( pool 10.10.10.0 /24 ) onto router A and allowing access to 192.168.100.0 /24 , this is router A's local lan. Router A also has a site to site VPN to router B. This is from net 192.168.100.0 /24 to 192.168.200.0 /24 This is as follows.....

Remote Client 10.10.10.0 /24 | | 192.168.100.0 /24>>Router A>>

Reply to
tweety
Loading thread data ...

Hi there,

I was wondering if the following is possible?

I am terminating a vpn client ( pool 10.10.10.0 /24 ) onto router A and allowing access to 192.168.100.0 /24 , this is router A's local lan. Router A also has a site to site VPN to router B. This is from net 192.168.100.0 /24 to 192.168.200.0 /24 This is as follows.....

Remote Client 10.10.10.0 /24 | | 192.168.100.0 /24 | | | Router A | | | Router B | | | 192.168.200.0 /24

Is there anyway that the remote client would be able to go down the Site to site VPN and see Router B's lan?

I am looking fo the remote clients to be able to access resources on Router B's lan.

Thanks for any help or pointers anyone can provide.

Andrew

Reply to
tweety

From router A:

ip route 192.168.200.0/24 ?

Reply to
Artie Lange

Should be

ip route 192.168.200.0/24

In that scenario, the VPN client would forward the packet to the router A that in turn would have a route to router B....

Reply to
Artie Lange

Hi guys i appreciate the quick answers :)

However i would then need to make sure the client pool would not nat going from router A to router B?

Reply to
tweety

It sounds like the RAVPN and site-to-site VPN are terminated on the same interface of Router A.

Since traffic between the RAVPN Client and Router B's internal network is not transiting from an "ip nat inside" to an " ip nat outside" interface on Router A, I don't see NAT as a concern on Router A.

However, traffic returning from Router B's internal network to the RAVPN Client would need to be exempted from NAT on Router B.

This traffic would also have to be included in the crypto ACLs of both routers.

Best Regards, News Reader

Reply to
News Reader

Yes it is a remote access vpn to one router, then i want that pool to be able to see a device at the other end of a site to site.

Ahhh im beginning to follow you, thanks for the help, so do the static routes still apply?

Is there any docs you could suggest, been trying to get some but my eyes are sore looking :)

All the help is appreciated.

Reply to
tweety

That is a great point, pushing the traffic down the tunnel may not be a problem, it is the returning traffic back to site A that would be a concern... Great catch....

Reply to
Artie Lange

Not sure they are necessary (in your scenario), given that you wouldn't have default routes pointing further into your LAN at either end. Some admins configure RAVPN Clients without split-tunneling, and successfully route client traffic to/from the Internet via the tunnel-termination interface.

I would expect the traffic to match the crypto ACL as it is forwarded back out the external interface (due to your default route), and be forwarded to the crypto peer.

However, I have not verified this.

I've not looked.

You'd need to be sure that:

- The external interface ACLs on the routers permits the correct encapsulated IP addresses (i.e.: include RAVPN pool addresses).

e.g.:

RAVPN pool addresses --> LAN B address space, on Router B RAVPN pool addresses

Reply to
News Reader

tweety schrieb:

On Router B there must be a route to 10.10.10.0/24 via the tunnel to

192.168.100.1 (or better use the ip of the tunnel interface of Router A facing to Router B), so traffic from LAN B back to the VPN client is finding it's way.

Perhaps you may consider the tunnel between Router A and Router B a GRE over IPsec tunnel instead of pure IPsec which cannot use a routing protocol. With the old crypto map syntax and static routes it is also possible but config will soon become quite ugly. Beware the execution order of NAT, Firewall and IPsec encryption.

Reply to
Uli Link

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.