1

Were trying to create a road warrior VPN network. Since the internet in our office is slow, we are running it through a VPC with a replicated AD and File Server. There is currently an Amazon VPC VPN to the office connecting to the VPC. In the VPC we have a OpenSwan server, that allows you to VPN into the AWS network. I am having trouble getting it to route back to the office, to allow a single VPN connection for both. In addition internet does not work when routed through Openswan. Therefore routes have to be manually added on Mac OS X. Does anyone know the correct configuration to have every connect, and provide internet if the user wants it? In addition, how can OpenSwan provide routes?

(10.1.5.0) IPSEC VPN <-OpenSwan CentOS Server-> (172.16.1.0) Amazon VPC Subnet <-Meraki/VPC VPN-> (192.168.1.0) In Office Network

Current OpenSwan Config

    # basic configuration
    config setup
        # plutodebug / klipsdebug = "all", "none" or a combation from below:
            # "raw crypt parsing emitting control klips pfkey natt x509 private"
            # eg: plutodebug="control parsing"
            #
        # ONLY enable plutodebug=all or klipsdebug=all if you are a developer !!
            #
        # NAT-TRAVERSAL support, see README.NAT-Traversal
            nat_traversal=yes
            #virtual_private=%v4:10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/12
            # If we consider that we have an internal interface on subnet 192.168.22.0/24,
            # we need to had here we had %v4:!192.168.22.0/24
            virtual_private=%v4:10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/12
            #
        # enable this if you see "failed to find any available worker"
            nhelpers=0
            protostack=netkey
            oe=no
    conn L2TP-PSK-CLIENTS
      #
      # Configuration for one user with any type of IPsec/L2TP client
      # including the updated Windows 2000/XP (MS KB Q818043), but
      # excluding the non-updated Windows 2000/XP.
      #
      #
      # Use a Preshared Key. Disable Perfect Forward Secrecy.
      #
      # PreSharedSecret needs to be specified in /etc/ipsec.secrets as
      # YourIPAddress  %any: "sharedsecret"
      authby=secret
      pfs=no
      auto=add
      keyingtries=3
      # we cannot rekey for %any, let client rekey
      rekey=no
      type=transport
      #
      left=172.16.1.53
      leftnexthop=172.16.1.1
      #leftsubnets={172.16.0.0/12,192.168.1.0/24}
      leftsubnet=0.0.0.0/0
      #leftsubnet=172.16.0.0/12
      # or you can use: left=YourIPAddress
      # leftnexthop=YourGatewayIPAddress
      #
      # For updated Windows 2000/XP clients,
      # to support old clients as well, use leftprotoport=17/%any
      leftprotoport=17/%any
      #
      # The remote user.
right=%any
  rightsubnet=0.0.0.0/0
  rightnexthop=172.16.1.1
  # Using the magic port of "0" means "any one single port". This is
  # a work around required for Apple OSX clients that use a randomly
  # high port, but propose "0" instead of their port.
  rightprotoport=0/%any

Current Openswan Route Tables

Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
10.5.1.11       0.0.0.0         255.255.255.255 UH        0 0          0 ppp0
172.16.1.0      0.0.0.0         255.255.255.0   U         0 0          0 eth0
0.0.0.0         172.16.1.1      0.0.0.0         UG        0 0          0 eth0

Openswan version:

openswan-2.6.43

VPC Routing Table

Destination Target
172.16.0.0/16 local
0.0.0.0/0 igw-xxxxxxxx
10.5.1.0/24 eni-xxxxxx / i-xxxxxx (openswan)
192.168.0.0/16 vgw-xxxxxxx
David Eisen
  • 643
  • 5
  • 21
  • Part of the problem is that traffic to foreign subnets can't transit a VPC's network like this. The office network will not see the road warrior network and vice versa. Note how there is no route table assignable for traffic coming in from the vgw. The office network can only route to the VPC's native subnets. Possible workaround involves natting the VPN users behind the instance's IP. – Michael - sqlbot Jun 29 '15 at 01:09
  • Hi Michael, I am not quite sure as to what ended up getting it working, but by switching to Libreswan and getting a guide through this site. http://fortycloud.com/setting-up-ipsecopenswan-in-amazon-ec2/ it somehow started working. Everything can transport now... really weird. – David Eisen Jun 29 '15 at 02:16
  • Glad it's working. Step 5 seems to describe the workaround I mentioned. You will probably see the road warriors connecting to your corporate network with a source IP of the gateway instance, rather than their assigned tunnel IP. If that's okay, then you may be good. – Michael - sqlbot Jun 29 '15 at 03:37
  • @DavidEisen That fortycloud example is almost useful. Unfortunately he holds his examples hostage behind a sign-up. Do you mind posting the config files that worked for you? I too am having some trouble with my routes. – jorfus Aug 17 '15 at 19:10

0 Answers0