Cannot access site-to-site through ra vpn

I have a site to site vpn connection to a remote office that works fine, using the pix

but whenever clients go home and connect via remote access vpn using pptp to the pix they cannot access resources on the other site

in other words they cannot reach the remote office but they can access local network resources fine

how can i allow the pix to send traffic from remote access users to the remote network on the end of the site to site vpn?

Find more posts tagged with

Comments

powerfool

This is by design. Previously, there was absolutely no way that this could work, but when I tried it TAC informed me that they may be making it possible in the future (this was in 2004). I have yet to see any feature that supports this, however. Basically, you cannot go out the same interface that you came in on.

What I did to get around this was to create two VLANs on my perimeter switch and then connect the screening router and the PIX up to each VLAN. Now, the PIX will only support one default gateway, so I had the site-to-site VPN terminate on the new VLAN and created a static route to the other side. This creates sub-interfaces and you can remote access into one sub-interface and go out the site-to-site VPN on the other sub-interface.

Your other option would be to use a DMZ interface for the site-to-site, or to use separate devices.

powerfool

If you reconfigure the remote access VPN to use IPSec instead of PPTP, you can use the "same-security-traffic permit intra-interface" command to allow this to work on just one interface.

same-security-traffic is a command that is used with the ASA algorithm. Essentially, traffic from a more secure interface can flow to a less secure interface, by default. The algorithm blocks traffic between interfaces that have the same security level, by default. The same-security-traffic command allows traffic to pass between interfaces with the same security level. The "intra-interface" option is specific to IPSec connections terminating on the same interface for the purposes of a "hub and spoke" VPN topology.

That is probably your best option.