3

I am currently trying to route traffic from one Linux box (local VM for testing purposes) to my Linux (Debian) server with the intent to use NAT. I was told to use IPSec to get my data to said server and decided that I would use Openswan to facilitate this scenario. I have successfully installed the required packages but as an amateur I struggle with understanding the different IPs that have to be defined in the ipsec.conf. This is an excerpt from an example found on the Debian wiki (including commented text by me):

left=10.15.109.36   #Is this the public (internet) IP? 
leftsubnet=192.168.50.0/24   #How do I find this one and whats the "/24"?
leftsourceip=192.168.50.X   #What is it and can it be deduced from the above?
leftnexthop=10.15.109.5   #I think this should be my gateway, right?
leftid=@vpngw1   #I assume this is something I can define myself?

I realize this might be a rather general question but I can assure you I did plenty of digging on this subject and could not find a comprehensive explanation.

6

Most of your answers can be found here: http://linux.die.net/man/5/ipsec.conf

To speak through them however:

  • left will specify the IP address of the left peer, as it is seen from the right peer. Typically, this public IP address of the left peer.
  • leftsubnet will specify the IP subnet for the left subnet. In the end, the IPsec SA (secure data channel) will encrypt everything from leftsubnet to rightsubnet. In your example, since it seems you only intend for your one Linux Box to speak to your other Linux box, you can simply use those Linux boxes' IP addresses directly for left/right subnet, using a /32 mask.
  • leftsourceip This will be the address that will be used when the VPN device itself is speaking through the tunnel. If the linux box referred to above is the only intended speaker through the VPN, and is also the machine that is doing the VPN processing, then this will be the IP address of your Linux box, and should match the leftsubnet above (but won't include a mask).
  • leftnexthop This will be the default-gateway of the box on the left that is doing the VPN processing
  • leftid This is going to end up being what is used in the negotiation as the ID Method (I go into a tun of details about what that is in this question/answer). For the most part, it doesn't matter what you put -- you may as well put something that identifies 'left' (Linux VM's hostname, or 'branch' or 'dev box' or anything). If the VPN connection will allow a FQDN/hostname ID, it will use this. If the VPN connection will default to its IP Address as its ID Method, then openswan will accommodate automatically.

Here are quotes from how the manual defines each term:

  • left

    (required) the IP address of the left participant's public-network interface, in any form accepted by ipsec_ttoaddr(3). Currently, IPv4 and IPv6 IP addresses are supported. There are several magic values. If it is %defaultroute, and the config setup section's, interfaces specification contains %defaultroute, left will be filled in automatically with the local address of the default-route interface (as determined at IPsec startup time); this also overrides any value supplied for leftnexthop. (Either left or right may be %defaultroute, but not both.) The value %any signifies an address to be filled in (by automatic keying) during negotiation. The value %opportunistic signifies that both left and leftnexthop are to be filled in (by automatic keying) from DNS data for left's client. The value can also contain the interface name, which will then later be used to obtain the IP address from to fill in. For example %ppp0 The values %group and %opportunisticgroup makes this a policy group conn: one that will be instantiated into a regular or opportunistic conn for each CIDR block listed in the policy group file with the same name as the conn.

  • leftsubnet

    private subnet behind the left participant, expressed as network/netmask (actually, any form acceptable to ipsec_ttosubnet(3)); Currentlly, IPv4 and IPv6 ranges are supported. if omitted, essentially assumed to be left/32, signifying that the left end of the connection goes to the left participant only

  • leftsourceip

    the IP address for this host to use when transmitting a packet to the other side of this link. Relevant only locally, the other end need not agree. This option is used to make the gateway itself use its internal IP, which is part of the leftsubnet, to communicate to the rightsubnet or right. Otherwise, it will use its nearest IP address, which is its public IP address. This option is mostly used when defining subnet-subnet connections, so that the gateways can talk to each other and the subnet at the other end, without the need to build additional host-subnet, subnet-host and host-host tunnels. Both IPv4 and IPv6 addresses are supported.

  • leftnexthop

    next-hop gateway IP address for the left participant's connection to the public network; defaults to %direct (meaning right). If the value is to be overridden by the left=%defaultroute method (see above), an explicit value must not be given. If that method is not being used, but leftnexthop is %defaultroute, and interfaces=%defaultroute is used in the config setup section, the next-hop gateway address of the default-route interface will be used. The magic value %direct signifies a value to be filled in (by automatic keying) with the peer's address. Relevant only locally, other end need not agree on it.

  • leftid

    how the left participant should be identified for authentication; defaults to left. Can be an IP address (in any ipsec_ttoaddr(3) syntax) or a fully-qualified domain name preceded by @ (which is used as a literal string and not resolved). The magic value %fromcert causes the ID to be set to a DN taken from a certificate that is loaded. Prior to 2.5.16, this was the default if a certificate was specified. The magic value %none sets the ID to no ID. This is included for completeness, as the ID may have been set in the default conn, and one wishes for it to default instead of being explicitly set. The magic value %myid stands for the current setting of myid. This is set in config setup or by ipsec_whack(8)), or, if not set, it is the IP address in %defaultroute (if that is supported by a TXT record in its reverse domain), or otherwise it is the system's hostname (if that is supported by a TXT record in its forward domain), or otherwise it is undefined.

2
  • I am currently working with only one "speaker" because I was aiming for a proof of concept. The idea in the long run however is to route multiple servers' data over one (remote) "gateway". How would assignment of the subnet and mask change because of that?
    – mti_
    Nov 24 '15 at 17:52
  • @mti_ the left and right subnets will become the IP/networks which are allowed to speak through the VPN. So if you have one host on the left speaking to an entire class C on the right, your 'leftsubnet' would be a /32, and your 'rightsubnet' would be a /24.
    – Eddie
    Nov 24 '15 at 18:40

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