I have a hosted Virtual Private Server (VPS) on which I have deployed VyOS 1.1.5 (Helium) in the hope of using it as an endpoint in a site-to-site VPN tunnel, with my in house Cisco ISA550 (ISA) being the other endpoint.
The hosted VPS end should also act as a gateway to the internet for the devices using the tunnel. This is the crux of the matter and the whole point of the exercise – to give (some) local devices (behind ISA) a Point of Presence in the VPS (geographic) network.
There are a number of restrictions I am trying to overcome, viz.:
- ISA is behind NATed ISP router, which provides the public (dynamic) IP.
- Local in house network is also NATed - behind ISA.
- VPS has only one Ethernet interface (static public IP). I am hoping this may be overcome by judicious use of a dummy interface (eth0 as WAN and dum1 as LAN, for instance).
- VPS provider has, rightly, declined to offer addition interfaces to VPS.
The main principle I am hoping to achieve is to set up IPSec policies on ISA (Site to Site, pre-shared key) to decide which local devices to route through the VPN tunnel at any given time (not all of them should use this tunnel). This being the dynamic IP end, I was thinking this should initiate the tunnel and VPS should respond. The other way round will not work as ISA public IP provided by ISP router, not ISA, so connection request would not traverse ISP Router.
Assuming the tunnel can be built, I then need to route traffic on VPS from WAN (eth0) to LAN (dum1) which then gets routed back out through eth0 to the real world, effectively using VPS as a gateway at that end of the tunnel. There are obviously no ‘real’ IP addresses on the dummy interface, so everything needs to route through eth0, the ONLY ‘real’ interface.
This all new to me. I did try a few virtual appliance solutions, but they all seem to require two ‘real’ interfaces. VyOS, although a steep learning curve, seems to be the most flexible but also, therefore, the most complex to configure. I hoping to stay the course and make it all worthwhile with an efficient, powerful and reliable solution as the result.
If such a VPN configuration is not possible, I would be happy to fall back on a more modest configuration for webproxy, but this, too, seems to rely on a multiplicity of interfaces.
Any ideas, suggestions or alternative solutions gratefully received.