Проблема, направляющая openswan трафик VPN вне сервера

Попытка настроить openswan основывала сервер, находящийся в кластере VPC Amazon. Цель состоит в том, чтобы сделать его так, мы можем VPN в VPC и иметь наши рабочие станции быть, как будто они были в сети, большем количестве roadwarrior конфигурации.

Наш предпочтительный клиент VPN является Средством отслеживания VPN Equinux (http://equinux.com/us/products/vpntracker/) для Mac OS X. Мы уже используем его для соединения с нашими существующими сетями через аппаратные средства базирующегося VPNs и надеялись только продолжить использовать его для соединения с нашей сетью VPC.

До сих пор у меня есть он установка туда, где я могу успешно соединиться с openswan сервером, работающим в VPC, однако я могу только проверить с помощью ping-запросов внутренний IP openswan сервера. Я не могу говорить ни с чем больше в сети. Я могу выполнить tcpdump и видеть, что запросы ping обнаруживаются, однако они никогда не добираются до другого хоста.

Моя первая мысль была то, что это было связано с экземпляром EC2, только имеющим единственный сетевой интерфейс, однако я имею, устанавливают OpenVPN соединения прежде без проблемы, хотя они обычно используют туннельное устройство, и я действительно не нашел пример openswan с туннелем или единственным интерфейсом.

Любая справка значительно ценилась бы.

Некоторая конфигурация:

VPC Subnet: 10.10.1.0/24
VPC Gateweay: 10.10.1.1
Openswan Private IP: 10.10.1.11
Openswan Public IP: xxx.xxx.xxx.xxx

Конфигурация Openswan:

version 2.0

config setup
  interfaces=%defaultroute
  klipsdebug=none
  plutodebug=none
  dumpdir=/var/log
  nat_traversal=yes
  virtual_private=%v4:10.10.1.0/24

conn vpntracker-psk
  left=%any
  leftsubnet=vhost:%no,%priv
  right=10.10.1.11
  rightid=xxx.xxx.xxx.xxx
  rightsubnet=10.10.1.0/24
  rightnexthop=10.10.1.1
  auto=add
  authby=secret
  dpddelay=40
  dpdtimeout=130
  dpdaction=clear
  pfs=yes
  forceencaps=yes

iptables/sysctl:

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

tcpdump производят:

09:13:25.346645 IP ROADWARRIOR_IP.4500 > ip-10-10-1-11.4500: UDP-encap: ESP(spi=0x38543e78,seq=0x6), length 116
09:13:25.346645 IP 10.200.0.30 > 10.10.1.251: ICMP echo request, id 21250, seq 0, length 64
09:13:25.346789 IP ip-10-10-1-11.4500 > ROADWARRIOR_IP.4500: UDP-encap: ESP(spi=0x07046a51,seq=0x6), length 148
09:13:26.506120 IP ROADWARRIOR_IP.4500 > ip-10-10-1-11.4500: UDP-encap: ESP(spi=0x38543e78,seq=0x7), length 116
09:13:26.506120 IP 10.200.0.30 > 10.10.1.251: ICMP echo request, id 21250, seq 1, length 64
09:13:26.506245 IP ip-10-10-1-11.4500 > ROADWARRIOR_IP.4500: UDP-encap: ESP(spi=0x07046a51,seq=0x7), length 148
09:13:27.332308 IP ROADWARRIOR_IP.4500 > ip-10-10-1-11.4500: UDP-encap: ESP(spi=0x38543e78,seq=0x8), length 116
09:13:27.332308 IP 10.200.0.30 > 10.10.1.251: ICMP echo request, id 21250, seq 2, length 64
09:13:27.332397 IP ip-10-10-1-11.4500 > ROADWARRIOR_IP.4500: UDP-encap: ESP(spi=0x07046a51,seq=0x8), length 148

ping произвел от OS X:

:~> ping 10.10.1.251
PING 10.10.1.251 (10.10.1.251): 56 data bytes
92 bytes from 10.10.1.11: Destination Host Unreachable
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
 4  5  00 5400 6c64   0 0000  3f  01 f85a 10.200.0.30  10.10.1.251 

Request timeout for icmp_seq 0
92 bytes from 10.10.1.11: Destination Host Unreachable
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
 4  5  00 5400 1818   0 0000  3f  01 4ca7 10.200.0.30  10.10.1.251 

Request timeout for icmp_seq 1
92 bytes from 10.10.1.11: Destination Host Unreachable
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
 4  5  00 5400 1a09   0 0000  3f  01 4ab6 10.200.0.30  10.10.1.251 

Request timeout for icmp_seq 2