How do I give VPN users access to the "other end" of an L2TP site-to-site connection?

Hi, welcome to the board.

The UTM supports L2TP for remote access but not for site-to-site VPN. Is this tunnel via another device or maybe you are using IPSec or SSL vpn tunnels for the site-to-site?

Regardless,In your site-to-site configuration you have 3 networks 192.168.1.0/24, 10.241.1.0/24 and 10.241.2.0/24 as local and 192.168.100.0/24 as remote? The other end of the site-to-site should have the reverse.

Alternatively, you can create a SNAT (masq could be used as well) to change the source of the remote users to that of 192.168.1.1.

Ex:
Source: 10.241.1.0/24
Service: ANY
Destination: 192.168.100.0/24
source: 192.168.1.1

PPTP should route all traffic over the tunnel but in SSL VPN you will need to make sure 192.168.100.0/24 is added as a local network.

Thanks. 

I may have not stated the problem clearly or simply enough. And I confused IPSec with L2TP.

The UTM has an **IPSec** site-to-site connection running. This connection joins 192.168.1.0/24 (the local, internal network) to 192.168.100.0/24 (the remote system).

All users on 192.168.1.0/24 can access assets on 192.168.100.0/24. No users with addresses in either the SSL pool or the PPTP pool can access 192.168.100.0/24. And yes, the other end has defined all three networks at my end and has established a connection with them.

Does that change your answer in any way?

Thanks -- relative noob. Happy just to have the IPSec site-to-site going. :-)

Thanks for all the help. I have it working -- and I am not sure it's the most elegant solution, but now both PPTP and SSL users have access to the internal network, the other end of the site-to-site VPN and the Internet (for SSL users, it's split tunnel; PPTP users go through the UTM).

The key was dilandau's recommendation to use SNAT to translate the incoming VPN user's private addresses to the address of the internal network.

After that, it was just a matter of adding the correct firewall and masquerading rules. (PPTP needed masq rules for both the internal and external networks, something I don't quite understand -- what's the purpose of a VPN if the default access is no access at all?)

Thanks for all the suggestions.

Good to hear it is working. You always need to add a masquerade rule when Private IPs need to access the Internet. If you used the wizard it made this for you for the Internal network automatically. That is why if you want PPTP users to access the internet you will need to add it manually. The masq for the Internal would have the same effect as the SNAT rule I posted earlier.

If the SNAT rule worked and allowed the remote access users to reach the network across the site-to-site it might indicate a problem with the IPSec tunnel config or maybe a routing issue on the far end. For example if the other side of the tunnel is also using PPTP and SSL, the default pools will be the same which may lead to a routing issue. Therefore, the SNAT would be a workaround for any of these issues. If you want to troubleshoot further, post screenshots of the IPSec, Remote Access, NAT rules etc.

I appreciate your willingness to take a look. I am attaching screenshots. I'm also annotated a couple of them to show that even if I bring up a S2S connection at the "other end" for the SSL/PPTP subnet pools, no traffic flows unless I do NOT bring those up and use your SNAT recommendation. That's what has me flummoxed. I don't understand why, if VPN pools are added to the local networks in the IPSec connection -- and the other side recognizes them -- traffic won't flow.

I appreciate your willingness to take a look. I am attaching screenshots. I'm also annotated a couple of them to show that even if I bring up a S2S connection at the "other end" for the SSL/PPTP subnet pools, no traffic flows unless I do NOT bring those up and use your SNAT recommendation. That's what has me flummoxed. I don't understand why, if VPN pools are added to the local networks in the IPSec connection -- and the other side recognizes them -- traffic won't flow.