gistfile1.txt

example openvpn config, from a site, to a Joyent zone, under SDC7:
----------------------------------------------------------------------------------------------------------------

example config:
server end, in joyent cloud, pick an IP address:  10.4.4.1
client ent, at home, pick an IP address:          10.4.4.2
in this example, I'm calling that network a /24, or 255.255.255.0 netmask

--------------------
on "the customer end":  (my example, on my linux OpenWRT router at home)

Install openvpn, according to your OS's installation instructions.

put this, in a file called "client.conf":
(find the primary IP address of your server, and substitute that in the first line)

----begin-dont-include-this-line
remote 165.225.139.100
dev tun
ifconfig 10.4.4.2 10.4.4.1
secret static.key
cipher AES-256-CBC
keepalive 10 120
----end-dont-include-this-line

Now, generate the "static.key" file with this command:
  openvpn --genkey --secret static.key

SCP this static.key file to your server side, as well, using SCP or SFTP.

To bring this config up (not just yet), you'll run: 
   openvpn --config client.conf

--------------------



on the "server end" , in JPC:


Install openvpn from pkgin:
   pkgin update
   pkgin install openvpn

cd /opt/local/etc/openvpn

put this in "server.conf"

----begin-dont-include-this-line
dev tun
ifconfig 10.4.4.1 10.4.4.2
secret static.key
cipher AES-256-CBC
keepalive 10 120
route 10.4.4.0 255.255.255.0
route 10.0.1.0 255.255.255.0
----end-dont-include-this-line

... the last two lines push routes for the 10.4.4.0/24 network, which is our made-up tunnel addresses,
and also for 10.0.1.0/24 , which is my network scheme at home.  This way, my JPC machine "knows the way" to find 10.0.1.99 , a device on my home network, over the tunnel.

NOTE that the ifconfig line has the .1 and .2 addresses switched around from the client.conf example.

** COPY *** the static.key file from the client side to the server side, into a file also named static.key.  It's ascii, you can paste it if you're careful.

Bring up the server with this command:
   openvpn --config server.conf

[root@1c6efc4e-db4e-60d0-923e-92398fbdbbd1 /opt/local/etc/openvpn]# openvpn --config server.conf 
Thu Apr  3 00:46:02 2014 OpenVPN 2.3.2 x86_64-sun-solaris2.11 [SSL (OpenSSL)] [LZO] [eurephia] [IPv6] built on Jan 14 2014
Thu Apr  3 00:46:02 2014 open_tun: got dynamic interface 'tun0'
Thu Apr  3 00:46:02 2014 TUN/TAP device tun0 opened
Thu Apr  3 00:46:02 2014 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Thu Apr  3 00:46:02 2014 /sbin/ifconfig tun0 10.4.4.1 10.4.4.2 mtu 1500 up
Thu Apr  3 00:46:02 2014 /sbin/ifconfig tun0 netmask 255.255.255.255
add net 10.4.4.0: gateway 10.4.4.2
add net 10.0.1.0: gateway 10.4.4.2
Thu Apr  3 00:46:02 2014 UDPv4 link local (bound): [undef]
Thu Apr  3 00:46:02 2014 UDPv4 link remote: [undef]




... now, on the client, bring up the client end:
   openvpn --config client.conf

root@stmarx:/tmp/var/tmp# openvpn --config openvpn.conf 
Thu Apr  3 01:47:29 2014 OpenVPN 2.1_rc20 mipsel-unknown-linux-gnu [SSL] [LZO1] [EPOLL] built on Nov  2 2009
Thu Apr  3 01:47:29 2014 IMPORTANT: OpenVPN's default port number is now 1194, based on an official port number assignment by IANA.  OpenVPN 2.0-beta16 and earlier used 5000 as the default port.
Thu Apr  3 01:47:29 2014 TUN/TAP device tun0 opened
Thu Apr  3 01:47:29 2014 /sbin/ifconfig tun0 10.4.4.2 pointopoint 10.4.4.1 mtu 1500
Thu Apr  3 01:47:29 2014 UDPv4 link local (bound): [undef]:1194
Thu Apr  3 01:47:29 2014 UDPv4 link remote: 165.225.139.100:1194
Thu Apr  3 01:47:29 2014 Peer Connection Initiated with 165.225.139.100:1194


... then, after a moment, you should see:
Thu Apr  3 00:46:32 2014 Initialization Sequence Completed

... on each side of the tunnel.

... once that's done, in my example, I can ssh from the zone to a computer on my home 10.0.1.X network, and reach 
it successfully (because the computer has default routes thru the router machine that's my openvpn client)
... and, from the computers at home, I can ssh to 10.4.4.1 , the tunnel address of the JPC zone.

All the rest is just adding appropriate routes on hosts that don't use this zone as their default router.

This example does NOT require disabling anti-spoof, because we're never sourcing packets from a "real" nic on a 
JPC zone's interface that aren't assigned by SmartDatacenter.  All vpn'd packets are safely encapsulated in the
openvpn UDP packets which are legitimately sourced from their "blessed" source IP address.

If, in the JPC, the customer wants to make this zone be a router, and have *other* hosts point to it in their
routing tables, then we'll need them to be on a private VLAN, because we'll need to disable anti-spoof protection. 
The packets coming from the "10.4.4.x" network, bound for *other* hosts on the private VLAN will be
packet-forwarded over the non-imaginary internal vnic, which means their forwarded src-address will be that of some
address of where they came from.  That requires anti-spoof disabling.

If you're just connecting the one to the one other host, though (or any number of client hosts on a
non-multi-tenant network that's not enforcing anti-spoof rules), and can refer to it as it's openvpn-assigned IP,
then it all just works.

note:  if your client side is actually behind a nat, this may still work, if you can configure the router to forward 
port 1194 (udp or tcp+udp) to your actual client's internal address.  This works if set that port-forward on my 
linksys, and then run the openvpn client on my mac desktop.