SSL VPN/UTM Routing to Internal Gateway

Question

Hi all, 
 
 I'm trying to set-up routing on the Sophos UTM so it can ping a server at our US site. I can see through the tracert on the UTM that it's using the external gateway address, whereas I need it to use our internal gateway as that also hosts our site-to-site VPN. 
 Is there any way I can do this? 
 Any help would be appreciated. 
 Regards, 
 
 Rob

BAlfson · Accepted Answer

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

BAlfson · Answer

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

apijnappels · Answer

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.

apijnappels · Answer

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.

BAlfson · Answer

Yes, it appears that my guess above was correct - this is still an issue with the UTM not responding to ARP requests for IPs in VPN Pools. A quick test (and Band-Aid) to demonstrate that this is the problem would be to masq "VPN Pool (SSL)" with the IP on the UTM. 
 Cheers - Bob