SSL VPN/UTM Routing to Internal Gateway

Try to add a gateway-route within UTM.

That can be done, Dirk, but it would require binding the tunnel to a specific WAN connection.  Even then, I'm not sure the configuration daemon would build the right rules to be able to reach the public IP.  I've had problems with that in the past.

I'd be interested in knowing if Dirk's idea would work without binding the tunnel to the WAN interface if the route were a Gateway Route like '{remote public IP} via {remote IP on the LAN interface in the tunnel}'.

Rob, if your goal is just to see if the tunnel is functioning, why not ping the IP on the LAN interface of the other tunnel endpoint?

Cheers - Bob

Two different versions of the same concept:

How to allow remote access users to reach another site via a Site-to-Site Tunnel

Hub and Spoke Site-to-Site VPNs

Cheers - Bob

Thanks for this, although after having gone through the configuration it's still a no go. 

To summarise:

UK Site:

LAN = 10.1.0.0/16

SSL VPN POOL = 10.1.17.0/24

Sophos UTM: 10.1.0.20 or for SSL VPN: 10.1.17.1

IP COP: 10.1.7.254 

US site: 

LAN = 10.2.0.0/21

Sophos UTM: 10.2.7.254

I've set up a static route on the UK UTM to say any going to the US LAN should be routed via IP COP. 

When pinging something on the US network from one of the SSL VPN clients, I receive "Reply from 10.1.17.1: Destination host unreachable." So it seems like the UK UTM is not routing the VPN traffic to IP COP. 

Are there any logs I could go through to check what's happening? I've taken a look at the firewall and ssl vpn logs to no avail. 

I can confirm I've been through the following link (https://community.sophos.com/kb/hu-hu/115734). 

In the site to site configuration for the US site, the UK LAN subnet is listed. I don't believe there's any need to add the SSL VPN pool separately as it falls under the same subnet. 

It's the same thing for the IP COP S2S configuration - the SSL VPN pool falls under the UK subnet, so there's no need to add it in separately. 

Thanks for your help and patience so far :) 

Hopefully we'll get to the bottom of this soon... 

"I've set up a static route on the UK UTM to say any going to the US LAN should be routed via IP COP."

I'm getting lost again, Rob.  I thought there was a VPN between the UTM and the US office.  If that's the case, your manual route could be causing a problem.  It shouldn't even be considered though.

Cheers - Bob

No, if you take a look at my diagram it's IP COP hosting the S2S VPN on the UK side going to the US UTM. 

Can it be that IPCOP cannot route to 10.1.17.0/24?
IPCOP is 10.1.7.254/16 so for IPCOP 10.1.17.0/24 is the same network so it will only do a arp request (who has 10.1.17.x, tell 10.1.7.254) while it should route it to Sophos as a next hop?

I believe the problem is in the overlapping subnets.

Rob, you said:

LAN = 10.1.0.0/16

SSL VPN POOL = 10.1.17.0/24

I didn't see this until apijnappels mentioned it - he nailed it.  Your overlapping subnet is the problem.

Cheers - Bob

Thanks for the reply and suggestion but IPCOP can route to 10.1.17.0/24. 

The SSL VPN pool is designed to be in the same network as the UK subnet to make the routing easier for IPCOP. The SSL VPN pool should be working in the same fashion as an internal user within the UK office. 

For example, I have IP 10.1.4.2/21 and I can ping/connect to the US network (10.2.1.1/21) perfectly fine. The SSL VPN pool has 10.1.17.0/24 so it should fit within the scope to forward the packets across to the US network if the destination address is 10.2.x.x/21.  

We're going to be retiring IPCop anyway, so I think I'll transfer the Site to Site VPN over to our UTM and hopefully that will resolve the issue. 

Please let us know if your tests show that the UTM still causes problems with routing because it won't answer an ARP request for an IP in a remote access subnet.

Cheers - Bob

Hello Rob, Your US site does indeed know to send the SSL-VPN subnet to the UK (because 10.1.17.0/24 is included in 10.1.0.0/16 BUT.... IPCOP thinks 10.1.17.0 is just in the same subnet as 10.1.0.0 and thus will only use ARP to learn the MAC-address of the client. However Sophos UTM is in between and will not pass ARP-requests.

Try to make a static route on IPCOP for 10.1.17.0/24 through gateway 10.1.0.20. Then it might just work.

Thanks for the explanation! I've put in the routing but often with IPCOP you need to restart it for the changes to take effect. As such, I'll restart it tonight out of hours and test the configuration tomorrow. 

Thanks for the explanation! I've put in the routing but often with IPCOP you need to restart it for the changes to take effect. As such, I'll restart it tonight out of hours and test the configuration tomorrow.