robbash's questions

https://wiki.strongswan.org/projects/strongswan/wiki/ConnSection

According to strongSwan documentation rightsubnet with multiple network addresses only works with IKEv2. There is a common (?) workaround, to set up multiple connections, all using the same SA. Our scenario is that we use a Vigor 2860 as the company VPN gateway where all home offices etc connect to.

If I setup multiple connections in strongSwan I would need to define multiple LAN-to-LAN profiles in the Vigor. Depending on the home offices to connect this would exceed the number of profiles.

Is there another workaround to achieve traffic to a 2nd subnet being sent through the tunnel? (Routing? NATing?)

Thanks in advance.

I have two servers establishing an IPSec VPN as a site-to-side kind of setup. I use StrongSwan on Ubuntu 16.04 for both servers and the VPN itself works. What may be a bit special is that the subnet behind each gateway is just virtual as in I created a virtual network adapter eth0:0.

auto eth0
    iface eth0 inet static
    address <PublicIP-A>
    ... etc

auto eth0:0
    iface eth0:0 inet static
    address 192.168.6.1
    netmask 255.255.255.0
    broadcast 192.168.6.255

(The second server has the 192.168.6.0/24 network and PublicIP-B, where PublicIP-A and -B are of course replaced by real and working IP addresses.)

The reason for the virtual network is that I want to connect to one of the servers through IPSec VPN tunnel and use that tunnel for SSH/FTP transfer communication. To be able to connect to the server via SSH/FTP or ping it I found I needed this virtual network. (Found that in earlier tests with a host-to-site VPN config which worked; unfortunately, that changed with my site-to-site setup.) Is the virtual network the right approach? Is there something better?

My /etc/ipsec.conf:

config setup
    # strictcrlpolicy=yes
    # uniqueids = no

conn %default
    ikelifetime=60m
    keylife=20m
    rekeymargin=3m
    keyingtries=1
    authby=secret
    keyexchange=ike

conn net-net
    right=<PublicIP-A>
    rightsubnet=192.168.6.0/24
    left=<PublicIP-B>
    leftsubnet=192.168.5.0/24
    auto=add

When I traceroute server B's virtual network address 192.168.5.1, it tries to go through the internet instead of the tunnel, and gets stuck... So I tried setting up routes with approaches like this in various combinations - but with very limited success:

ip route add 192.168.5.0/24 via 192.168.6.1 dev eth0 src PublicIP-A table 220

I also tried some iptables settings taken from the StrongSwan documentation (https://www.strongswan.org/testing/testresults/ikev2/net2net-psk/), but didn't get it running.

I hope this setup makes sense to anyone who would help me figure out how to set-up my routing to tell traffic to the other server's virtual local network to go through the tunnel. Any more information needed - please don't hesitate...

Thanks in advance!

EDIT 2016-08-26

Thinking about @ecdsa's comment, I don't need a site-to-site setup. Site-to-host is fine.

traceroute output

traceroute to PublicIPServer-B (PublicIPServer-B), 30 hops max, 60 byte packets
 1  PublicIPServer-B (PublicIPServer-B)  1.467 ms  1.298 ms  1.229 ms

whereas without the tunnel some other gateways popup.

This helped to get from Server B to Host A - SSH works - But the other direction doesn't want to work. Real world setup later will be site-to-host where there's a real network behind gateway Server B.

Taken from here https://www.strongswan.org/testing/testresults/ikev2/host2host-cert/, I tried to add a route

ip route add PublicIPServer-B via PublicIPServer-B src PublicIPHost-A
// and
ip route add 192.168.5.0/24 via PublicIPServer-B src PublicIPHost-A

which results in RTNETLINK answers: Network is unreachable errors. Not sure if I will ever need the host-to-site direction communication but would be nice to be on the safe side. (Especially since I'm not 100% sure if the answers to the traceroute are send through the tunnel)

Any ideas on how to achieve the last bit?

EDIT 2016-08-26 (2nd)

strongSwan apparently does set-up the routes in this scenario. traceroute-ing and ping-ing the remote subnet (as in the Server-B's remote subnet IP address 192.168.5.1) works.

So, yeah, I guess this is solved for now!

Cheers @ecdsa