Basic VPN question

"Bueller?….Bueller?….Bueller? ..." (from "Ferris Bueller's Day Off")

Are the resident VPN gurus too busy living the last days of summer?

The more I think about this, the more I think that Terminal Server must need to be able to initiate transactions with the client.  Otherwise, why would it need to be able to see the 'Remote Access VPN Pool (SSL)' of the Astaro at the other end of the Site-to-Site IPsec VPN?

Or, is this a subtle routing issue?

Thanks - Bob

I'm not sure about your confusion on this issue Bob. In general traffic will only be routed over an IPSec site-to-site tunnel if both source and destination networks match exactly what is specified for the local and remote networks. That is why the remote ssl pool needs to be added to the local networks on the one side and the remote on the other, otherwise traffic to/from the ssl network will not be sent across the tunnel. Does that clear it up for you?

But that's not how I understand it.  As I understand it:

Site A

Remote Gateway: [Public IP of Site B]
Remote Networks: Astaro will create Gateway routes and packet filters to these at Site B
Local Networks: Astaro will allow Site B access to these

Site B

Remote Gateway: [Public IP Site A]
Remote Networks: Astaro will create Gateway routes and packet filters to these at Site A
Local Networks: Astaro will allow Site A access to these

If I'm connected to Site A via Remote Access, I should be able to reach, via the site-to-site, an IP inside Site B.  If someone inside site B tries to reach me, they won't be able to because Site A doesn't offer the VPN Pool to Site B.

Or, does this have something to do with Strict Routing?

Thanks - Bob

Dilandau is correct; this is how things have to be done so the Astaro VPN(s) know where to route the traffic.  Sort of like using static routes on a cisco routing infrastructure with 3 routers connected by 2 links (sort of in a chain, 2 T1s in the center one)... one has to add routes to define the "far" side WAN IP in order for routing to work end to end... it looks wierd, but it's necessary.

So, instead of the above, I should think of things as follows:

Site A

Remote Gateway: [Public IP of Site B]
Remote Networks: Astaro will create Gateway routes and packet filters to these at Site B
Local Networks: Astaro will allow Site B access to these and will allow these to access Site B

Site B

Remote Gateway: [Public IP Site A]
Remote Networks: Astaro will create Gateway routes and packet filters to these at Site A
Local Networks: Astaro will allow Site A access to these and will allow these to access Site A

With 'Strict Routing' enabled, no other traffic can transit the tunnel.

Thanks for your participation here, Bruce.

Cheers - Bob

OK, I found it.  Check out Article #119116 in the KnowledgeBase.  The recommended solution is to disable 'Strict Routing' and create a NAT rule: 'VPN Pool -> [Services] -> [Remote Network] : SNAT from Internal (Address)'.

Without the SNAT, I suspect that a request from a Road Warrior connected to Site A would indeed find a resource at Site B, but the resource would not know how to route its response back through the tunnel.  I assumed that conntrac in the Astaro at Site B would know that, which it would.  My mistake was not realizing that the resource behind the Astaro at Site B wouldn't know that.

My characterization in the previous post is correct with 'Strict Routing' enabled, so I have modified that post.

The solution with SNAT works even when you have no control over the remote VPN definition.  The solution with 'Strict Routing' enabled preserves any IP tracking done in the remote network.

Thanks Dilandau and Bruce, for helping me to understand.  Please feel free to correct me if I'm still confused - and confusing others!

Cheers - Bob

Thanks to all for this thorough discussion, it was very instructive. The solution I implemented is working well and I like seeing all of the SA's in the Site to Site display, it gives me visual clarity as to what is connected to what. Not to muddy the waters, but I have never had Strict Routing checked. I do have Auto Packet Filter checked. So, as far as I can tell, even without Strict Routing, you still have to provide the route back from the far site by including the SSL VPN Pool in the IPSEC/Remote Gateway configurations.

Right, that also works without strict routing.  With strict routing the SNAT approach recommended in the KB article doesn't work.  Thanks, I've modified the post again.

I wonder - instead of a SNAT in Site A, would a gateway route in the resource at Site B, '[VPN Pool for Site A]->[Internal (Address) of Site A]', work?  Would strict routing need to be disabled for that to work?

Cheers - Bob

Bob !

Sorry to kinda reopen on you 8 years later - just in case someone reads this like I did.

If your Site-to-Site is trusted and/or you would like to do fine grained access control. 

Please don't do any kind of NAT. 

As Bob suggested you can do a Route - and please do so !

 

Regards 

Maximilian S.

Hi, Similian, and welcome to the UTM Community!  Great nickname!

Cheers - Bob