Score:0

Site-to-Site VPN and Remote Access VPN with Strongswan

in flag

I've recently deployed a Strongswan IKEv2 Remote Access VPN in two different sited with two different ubuntu servers. It all works great, but now i want to "merge" the two sites with a site-to-site vpn, so that i can leave only one Remote Access VPN and access both subnets. The issue is how to do it? My idea was an IPSec Tunnel using strongswan between the two sites and static routing on both sites routers to manage the traffic.

The sites are configured as follows:

A) 
Only One Public IP : x.x.x.x
Subnet : 10.5.5.0/24

B)
One Usable Public IP : x.x.x.x
Subnet : 192.168.5.0/24

The questions are:

  1. Can I run the two services (IKEv2 Remote access and IPSec Tunnel) on the same strongswan instance? My answer to this would be NO, and if this is the case I'm ready to add a new instance of strongswan using another two ubuntu servers as gateway.
  2. But if I'm using two different server in the sites another issue comes up, the sites only have one public IP each, how do i deconflict IPSec and IKEv2 as both should be using the same ports? Can i change the ports used by the IPSec Tunnel? Or maybe i don't need port forwarding for the IPSec Tunnel?

This is my reference for the IPSec Tunnel. https://www.tecmint.com/setup-ipsec-vpn-with-strongswan-on-debian-ubuntu/

Any ideas on how to make this mess work? Do i ALWAYS need two different ip addresses for running two vpn servers? Could OpenSource DMVPN help?

Thanks in advance.

cn flag
The answer to your first question is actually YES. Just configure appropriate traffic selectors (subnets) for the IPsec connection between the two servers (e.g. so virtual IPs from remote access clients are included) and possibly adjust the firewall rules (e.g. to avoid any NAT for traffic to the remote subnet). So with that out of the way, you might want to update your question if you still feel there are issues.
Score:0
us flag

To answer your question

  1. Yes, you can run Remote Access (aka. Roadwarrior) and Site-to-site Tunnel on the same StrongSwan instance.
  2. You can differentiate the Site-to-site connection and Remote Access connections by the authentication method.

Here is a working setup

connections {
  site {
    pools = ipv4, ipv6

    local {
      auth = pubkey
      certs = site1.example.com.pem
      id = site1.example.com
    }

    remote {
      auth = pubkey
      cacerts =  MyCA.cer
      id = "CN=site2.example.com"
    }

    children {
        site {
            local_ts  = 10.218.2.0/24, ::/0
            remote_ts = 10.218.1.0/24, 2001:470:ffff::/64
        }
    }
  }

  win {
    pools = ipv4, ipv6

    local {
      auth = pubkey
      certs = site1.example.com.pem
      id = site1.example.com
    }
    remote {
      auth = pubkey
      cacerts =  LloydsCertificateAuthorityG2.cer
    }
    children {
      win {
        local_ts = 0.0.0.0/0, ::/0, 10.218.1.0/24, 2001:470:ffff::/64
      }
    }
  }
}

pools {
  ipv4 {
    addrs = 10.218.2.3-10.218.2.254
    dns = 10.218.1.99
    netmask = 255.255.255.0
    subnet = 10.218.2.0/24,10.218.1.0/24
  }

  ipv6 {
    addrs = 2001:470:ffff:2::3-2001:470:ffff:2::ffff
    dns = 2001:470:ffff::99/64
    subnet = 2001:470:ffff:2::/64,2001:470:ffff::/64
  }
}

Site 2 connects with IKEv2 Protocol and Machine Certificate CN=site2.example.com

Certificates are stored on site 1 at

/etc/swanctl/rsa/site1.example.com.pem (private key)
/etc/swanctl/x509/site1.example.com.pem (public key)
/etc/swanctl/x509ca/MyCa.cer (Root CA)

Reload configuration with swanctl --load-all

To enable NAT for Remote Access clients

iptables -t nat -A POSTROUTING -s 10.218.2.0/24,10.218.1.0/24 -o eth0 -m policy --dir out --pol ipsec -j ACCEPT
iptables -t nat -A POSTROUTING -s 10.218.2.0/24,10.218.1.0/24 -o eth0 -j MASQUERADE
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.