Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

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.

share|improve this question
    
I'm no expert but it seems that from here 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 0:46

2 Answers 2

up vote 3 down vote accepted

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.

share|improve this answer
    
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 0:59

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.

share|improve this answer
    
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 3 at 8:18

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.