Remote Access other Site to Site networks

Hi. I have tested that exact scenario I believe and got it to work. Maybe you are missing that you have to SNAT the traffic from your remote access clients to have their source IP's changed to be something from the network that is allowed in. You could just pick the local IP of the router itself.

Let me explain my test scenario so you can decide if it matched yours.

ASG IPsec VPN with another router (2 instances, 1 was my own Amazon Linux and the other a Cisco router).
ASG itself able to access protected private LAN on remote side.
Windows server 1 "behind the ASG" was also automatically able to access those protected networks too. (very cool)

SSL VPN client to the ASG able to access ASG private network. (naturally)
Added the remote private network into the SSL VPN "Local Network" list. This results in the SSL VPN client PC's routing to get updated which you can see via "route print" in Windows.
Then had to add SNAT rule to make SSL VPN client traffic look like it was coming from the ASG.
SSL VPN client was able to access the protected remote networks in that Amazon Linux instance and also the Cisco router's network.

Since the remote IPSec VPN's had the ASG's private network configured, SSL VPN clients IP addresses are not allowed. So you have to do the SNAT.

Yes, that is exactly how I have mine set up! The only thing missing was the SNAT. It looks like it is working after adding the SNAT rules. Do you know of any way to do a rule for all traffic? It is only letting me do one service at a time. If I try to say Any or use a service group, it gives an error message. "The NAT rule object cannot use service group objects for the source service attribute." or "Cannot create a NAT rule mapping all services into one." Thank you!

EDIT:
After re-reading your comment, I think just one of my points below matters..  when creating the SNAT rule, you leave the Service blank in the bottom half of that configuration.


In the SNAT rule, you'd set as your Source Traffic to be your "VPN SSL Pool". So anybody on there qualifies. 
Then in Traffic Service, this is only for the port.. so you can maybe leave this alone as Any service.
Then in Traffic Destination, you'd put in the Network definition you created for the private LAN of the remote side.
You CAN create a Network Group definition and inside of it, put in all the private IP's or networks behind multiple VPN connections. Then you can put this group in the "Traffic Destination" setting here.

Then your Source to change it to would just be the IP of the router itself, and you leave the Source Service alone.

The service stuff would only be if you wanted to route to different ports.

Hi Phil,

While the snat trick can be used (sometimes to great effect) its not technically required in order for a remote site to access another via the HQ when you are setup as a hub/spoke topology.

What you need to do is disable the strict routing control of the tunnel, as this will then allow for the "passthrough" routing that you are lacking, (and solving with SNAT). This has the same effect, but requires less work (and less resulting configuration) to accomplish.

Might be something you want to try.

Oh, very cool. I was afraid of turning off anything that said "strict" to avoid being loosey goosey.

I thought "why would I not want strict routing?"

coewar- I got everything working with the SNAT rules, including leaving the service blank. Thanks for that!

Angelo- I tried to disable the SNAT rules and disable strict routing in the IPSec config (which had previously been on, I had the same thought as coewar). It did not work. Is there anything else that needs to be set up for this method to work? I have firewall rules in place to allow VPN Pool (L2TP) -> Any -> Any and the same for VPN Pool (SSL).

Thanks!

-Phil

oh yeah that's right. The default is actually No strict routing. And below is the help of what it means. It actually merely prevents you from creating a SNAT rule to do what we are doing. So the question remains, without SNAT, how would it work?


Strict Routing: If strict routing is enabled, VPN routing is done according to source and destination IP address (instead of only destination IP address). In this case, only those packets exactly matching the VPN tunnel definition are routed into the VPN tunnel. As a consequence, you cannot use SNATto add networks or hosts to the VPN tunnel, that are originally not part of the tunnel definition. On the other hand, without strict routing, you cannot have a mixed unencrypted/encrypted setup to the same network from different source addresses

Phil, it's not clear that you have the 'VPN Pool (SSL)' included in the IPsec tunnel, and that's necessary for Angelo's suggestion.  You might want to [Go Advanced] below and post pictures of your 'IPsec Connection', 'Remote Gateway' and the 'Local networks' box in 'Remote Access >> SSL'.

Cheers - Bob

I would expect Phil specifically NOT to have VPN Pool in the IPSec configuration; I don't. The reason is that the other side would also have to have it. And I bet the point of this is to allow some users to get to these IP's in the other's network without them having to add some other private IP's in the configuration. That would mean extra work and likely conflicts in all the IP configurations on all sides.

It would also seem that if the VPN Pool SSL is already in the IPSec definition, then the Strict Routing would actually still work if enabled because as the help says, it's defined there. The Strict Routing seems to just protect you from having a SNAT rule do what we're doing.

I've tried adding the SSL and L2TP Pool to the IPSec config and it doesn't seem to like that very much. I get a no connection status. This doesn't seem like it should go there. I toggled between strict routing on and off, didn't make a difference. The only way I can make it work is with the SNAT rules on.

I don't want/need the Site to Site networks to be able to initiate a connection with SSL/L2TP remote access clients or be able to see that they are online. The remote access is mainly for administration and support via screen sharing.