IPSec VPN between Amazon VPC and Linux Server

Question

I'm trying to set up an IPSec VPN connection between our corporate network and Amazon's Virtual Private Cloud, using their VPN system and a Linux server. Unfortunately, the only guide I've found discusses how to set up the tunnel using a host Linux machine and get that linux machine to access VPC instances, but there's no discussion I can find online on how to get the instance to access the corporate network (or the rest of the internet via that network).

Network information

Local subnet: 10.3.0.0/25
Remote subnet: 10.4.0.0/16

Tunnel 1:
  Outside IP Addresses:
    - Customer Gateway:        : 199.167.xxx.xxx
    - VPN Gateway              : 205.251.233.121

  Inside IP Addresses
    - Customer Gateway         : 169.254.249.2/30
    - VPN Gateway              : 169.254.249.1/30

Tunnel 2:
  Outside IP Addresses:
    - Customer Gateway:        : 199.167.xxx.xxx
    - VPN Gateway              : 205.251.233.122

  Inside IP Addresses
    - Customer Gateway         : 169.254.249.6/30
    - VPN Gateway              : 169.254.249.5/30

Here is my /etc/ipsec-tools.conf:

flush;
spdflush;

spdadd 169.254.249.2/30 169.254.249.1/30 any -P out ipsec
   esp/tunnel/199.167.xxx.xxx-205.251.233.121/require;

spdadd 169.254.249.1/30 169.254.249.2/30 any -P in ipsec
   esp/tunnel/205.251.233.121-199.167.xxx.xxx/require;

spdadd 169.254.249.6/30 169.254.249.5/30 any -P out ipsec
   esp/tunnel/199.167.xxx.xxx-205.251.233.122/require;

spdadd 169.254.249.5/30 169.254.249.6/30 any -P in ipsec
   esp/tunnel/205.251.233.122-199.167.xxx.xxx/require;



spdadd 169.254.249.2/30 10.4.0.0/16 any -P out ipsec
   esp/tunnel/199.167.xxx.xxx-205.251.233.121/require;

spdadd 10.4.0.0/16 169.254.249.2/30 any -P in ipsec
   esp/tunnel/205.251.233.121-199.167.xxx.xxx/require;

spdadd 169.254.249.6/30 10.4.0.0/16 any -P out ipsec
   esp/tunnel/199.167.xxx.xxx-205.251.233.122/require;

spdadd 10.4.0.0/16 169.254.249.6/30 any -P in ipsec
   esp/tunnel/205.251.233.122-199.167.xxx.xxx/require;

Here's my /etc/racoon/racoon.conf:

remote 205.251.233.122 {
        exchange_mode main;
        lifetime time 28800 seconds;
        proposal {
                encryption_algorithm aes128;
                hash_algorithm sha1;
                authentication_method pre_shared_key;
                dh_group 2;
        }
        generate_policy off;
}

remote 205.251.233.121 {
        exchange_mode main;
        lifetime time 28800 seconds;
        proposal {
                encryption_algorithm aes128;
                hash_algorithm sha1;
                authentication_method pre_shared_key;
                dh_group 2;
        }
        generate_policy off;
}

sainfo address 169.254.249.2/30 any address 169.254.249.1/30 any {
    pfs_group 2;
    lifetime time 3600 seconds;
    encryption_algorithm aes128;
    authentication_algorithm hmac_sha1;
    compression_algorithm deflate;
}

sainfo address 169.254.249.6/30 any address 169.254.249.5/30 any {
    pfs_group 2;
    lifetime time 3600 seconds;
    encryption_algorithm aes128;
    authentication_algorithm hmac_sha1;
    compression_algorithm deflate;
}

BGP is working fine, so I'm not going to post those configs.

Here's what works

From the Linux box, I can ping the local endpoints (169.254.249.2/169.254.249.6), and their remote equivalents (169.254.249.1/169.254.249.5).
I can also ping the instances in VPC, SSH to them, etc.
From the remote instances in VPC, I can ping the local and remote endpoints as well
I cannot ping the local servers on the 10.3.0.0/25 subnet

I assume I'm missing something simple, but I've tried adding entries to ipsec-tools.conf to mirror the {local endpoint}<->{remote subnet}, using {local subnet}<->{remote endpoint}, but it didn't seem to work.

When I ping from {remote instance} to {local server}, the pings timeout. The packets are visible on the eth0 interface (even though the local network is on eth1).

Google has been little help; it shows only people trying to use OpenSwan, or having similar issues but with hardware routers, or using older tools.

I'm no expert but it seems that from here http://wiki.debian.org/IPsec that you have to manually add routes to the remote local network when using ipsec, i might be wrong though.. — user993553, Jun 19 '12 at 00:46

score 3 · Answer 1 · answered Jun 19 '12 at 15:17

3

Well, I cheated :) I installed Astaro gateway which is officially supported by Amazon and then used that to model my own. You can just SSH into the Astaro unit and see how they set everything up. Of course, you could stick with the Astaro unit if you feel like paying for it.

answered Jun 19 '12 at 15:17

Petter

41
2

1

Could you please elaborate on your solution? What do you mean with "model my own"? I am stuck on the same problem, and would be interested in how you solved it, thanks! – Max Feb 03 '15 at 08:18

score 3 · Accepted Answer · answered Jun 19 '12 at 17:42

Figured it out. Had to change my ipsec-tools.conf to this:

flush;
spdflush;

# Generic routing
spdadd 10.4.0.0/16 10.3.0.0/25 any -P in  ipsec esp/tunnel/205.251.233.121-199.167.xxx.xxx/require;
spdadd 10.3.0.0/25 10.4.0.0/16 any -P out ipsec esp/tunnel/199.167.xxx.xxx-205.251.233.121/require;

# Tunnel 1
spdadd 169.254.249.1/30 169.254.249.2/30 any -P in  ipsec esp/tunnel/205.251.233.121-199.167.xxx.xxx/require;
spdadd 169.254.249.2/30 169.254.249.1/30 any -P out ipsec esp/tunnel/199.167.xxx.xxx-205.251.233.121/require;

spdadd 10.4.0.0/16 169.254.249.2/30 any -P in  ipsec esp/tunnel/205.251.233.121-199.167.xxx.xxx/require;
spdadd 169.254.249.2/30 10.4.0.0/16 any -P out ipsec esp/tunnel/199.167.xxx.xxx-205.251.233.121/require;

# Tunnel 2
spdadd 169.254.249.5/30 169.254.249.6/30 any -P in  ipsec esp/tunnel/205.251.233.122-199.167.xxx.xxx/require;
spdadd 169.254.249.6/30 169.254.249.5/30 any -P out ipsec esp/tunnel/199.167.xxx.xxx-205.251.233.122/require;

spdadd 10.4.0.0/16 169.254.249.6/30 any -P in  ipsec esp/tunnel/205.251.233.122-199.167.xxx.xxx/require;
spdadd 169.254.249.6/30 10.4.0.0/16 any -P out ipsec esp/tunnel/199.167.xxx.xxx-205.251.233.122/require;

And change my racoon.conf to this:

path pre_shared_key "/etc/racoon/psk.txt";

remote 205.251.233.122 {
        exchange_mode main;
        lifetime time 28800 seconds;
        proposal {
                encryption_algorithm aes128;
                hash_algorithm sha1;
                authentication_method pre_shared_key;
                dh_group 2;
        }
        generate_policy off;
}

remote 205.251.233.121 {
        exchange_mode main;
        lifetime time 28800 seconds;
        proposal {
                encryption_algorithm aes128;
                hash_algorithm sha1;
                authentication_method pre_shared_key;
                dh_group 2;
        }
        generate_policy off;
}

sainfo address 169.254.249.2/30 any address 169.254.249.1/30 any {
    pfs_group 2;
    lifetime time 3600 seconds;
    encryption_algorithm aes128;
    authentication_algorithm hmac_sha1;
    compression_algorithm deflate;
}

sainfo address 169.254.249.6/30 any address 169.254.249.5/30 any {
    pfs_group 2;
    lifetime time 3600 seconds;
    encryption_algorithm aes128;
    authentication_algorithm hmac_sha1;
    compression_algorithm deflate;
}

sainfo address 10.3.0.0/25 any address 10.4.0.0/16 any {
    pfs_group 2;
    lifetime time 3600 seconds;
    encryption_algorithm aes128;
    authentication_algorithm hmac_sha1;
    compression_algorithm deflate;
}

However, this configuration as I understand it will only route traffic between 10.3.0.0/25 and 10.4.0.0/16 over the first tunnel (via x.x.x.121). I'll update the answer when I figure that out.

I have also been stuck with this issue for a while and your answer really helped. Did you come up with a solution for making routing over both tunnels? I added the 'Generic routing' parts with the other tunnel IP but haven't tested it. — Will, Feb 11 '14 at 13:02
I didn't find any good solution for routing over both tunnels, but I think that makes sense in one context. The idea here is to provide redundancy, and ideally that would include redundancy on both ends. You could set up a separate server on the second tunnel and provide two routes to your VPNs (e.g. by providing your standard servers with two routes, one to each box). Either that, or you trigger manual failover with some kind of monitoring system. Neither solution is really 'optimal', but the first provides redundancy on your side as well. — Dan Udey, Feb 21 '14 at 00:59

score 0 · Answer 3 · edited Aug 13 '19 at 20:44

Do you know the reason to using "require" instead of "use" for the setkey configuration? Do you also know if it matters in what order I place the statements within the remote and sainfo sections and mistakenly duplicating certain statements? For example:

#original
remote 205.251.233.121 {
        exchange_mode main;
        lifetime time 28800 seconds;
        proposal {
                encryption_algorithm aes128;
                hash_algorithm sha1;
                authentication_method pre_shared_key;
                dh_group 2;
        }
        generate_policy off;
}

vs

#edited
remote 205.251.233.121 {
        generate_policy off;                           #moved/duplicated
        lifetime time 28800 seconds;
        proposal {
                dh_group 2;                           #moved
                encryption_algorithm aes128;
                hash_algorithm sha1;
                authentication_method pre_shared_key;
        }
         exchange_mode main;                      #moved
        generate_policy off;                   #duplicated/moved
}

Did you also figure out how to get traffic to flow on both tunnels?

Thank you for any guidance.

Welcome to Serverfault. It looks like you're trying to ask a question in the answer section of another poster's question. If you have a new question, please post it as a new question by going to https://serverfault.com/ and clicking the big red "Ask Question" button. — vjones, Aug 13 '19 at 17:44

IPSec VPN between Amazon VPC and Linux Server

3 Answers3