Dmitriy's dashboard

David,

Thanks for taking time and providing us your thoughtful feedback - appreciate it.

We will definitely consider your ideas on enforced password change on first login (password already can be changed but it's not enforced on first login), ability to change username, and use of CAPTCHA. Based on overall theme of your feedback, we will also consider ways how to inform VPN-Cubed users if their manager instance might be experiencing a brute force attack.

As you correctly point out, there are at least three main factors that significantly reduce your risk: random nature of IP address, security groups and the fact that you don't need to widely publicize your manager's IP address for correct operation.

In general, we don't recommend that you open tcp port 8000 to entire Internet (0.0.0.0/0). It should be open to other managers in this topology, and to those IP addresses from which you will be configuring VPN-Cubed. Also, once you complete configuration, we encourage you to revoke access to tcp/8000 from your IP address. If you ever need to log in again or check something in Runtime Status, you can always open it again - changes to security group permissions take affect immediately. And then when you're done, always revoke it.

Re DNS->IP mapping: Even in topologies where some or even all hosts are publicly discoverable via DNS, our customers don't usually add their managers' IPs to publicly discoverable DNS. VPN-Cubed is your backend connectivity solution - there is usually no need for your customers to know its IP.

Re roaming employees: tcp/8000 is admin interface, only administrators need access to tcp/8000 port (somewhat like regular employees don't usually have access to admin interfaces of your hardware switches, only network admins do). In such situations, we advise administrators to copy a unique clientpack to employee's laptop beforehand and not open tcp 8000 to the world.

Re Rightscale documentation: it's an oversight and we will work with Rightscale to address this problem on their wiki. There is absolutely no reason to open any ports to the world. Also, as you might have seen, our own documentation recommends a very restricted security groups setup - exactly to mitigate security concerns.

Re disgruntled employees: there are at least 4 levels of protection here. Firstly, our internal processes and procedures that help ensure this won't happen (first line of defense). Secondly, if you submit a technical support request that requires us to SSH in (not all requests lead to this), we will ask you to open tcp/22 to your manager from a specific very narrow IP block - these will be IPs access to which we strictly control. Thirdly, without you opening tcp/22 access in your security group AND letting us know your IP address, no one at Cohesive will be able to do anything (that's right - we DON'T know IP address of your manager unless you tell us). Fourthly, you control how long SSH access remains open. We could schedule a 15 minute SSH window, or 2 hour window, etc.

All in all, with SSH access none of us (customer and CohesiveFT) WHEN WORKING BY THEMSELVES can do anything - customer controls the gate, we control login credentials.

Re updates: currently when we apply errata, we create new AMIs and customers can migrate to new AMI. In the upcoming rollout, we are introducing a feature of runtime snapshots - customers will be able to take snapshots of their runtime state from old instance, and easily import it on their new instance.

I hope this addresses your concerns. Again, we appreciate the time you took to share this feedback to help us make VPN-Cubed more secure. Please let us know if you would like to follow up on any of these topics. Either here, or if you prefer to do it in private, - please feel free to contact us at support _at_ cohesiveft d0t com.

Cheers,
Dmitriy

For all who might be looking at this thread: Openswan interop for sure works. I myself have used it many times for various purposes.

Joachim - we will continue troubleshooting over email.

- Dmitriy

Ed,

In ElasticFox, please go to Instances tab. Security groups that you assigned to an instance will be listed in column titled Groups - vpncubed-mgr should be there for your instance.

On page 12 of the documentation, the following rule is used to allow your browser to connect to VPN-Cubed Web Administration tool on port 8000 using HTTPS:

ec2auth vpncubed-mgr -P tcp -p 8000 -s ip_address_of_your_firewall/32

The IP address used in this rule must be what Amazon EC2 sees when you initiate a TCP connection from your browser. Some people don't know their Internet-facing IP address, so we use checkip.dyndns.org as a way to find that out. You can use any other Internet service for this - just type "what is my IP" into Google.

if you would like to continue troubleshooting this issue in private, please contact support AT cohesiveft.com.

- Dmitriy

There could be several possibilities.

First thing is to check if your instance is in fact running with vpncubed-mgr security group.

Then, please make sure that ip_address_of_your_firewall that you used corresponds to the output of http://checkip.dyndns.org.

If neither helps, please add the following rule temporarily and see if it fixes the issue:

ec2auth vpncubed-mgr -P tcp -p 8000 -s 0.0.0.0/0

- Dmitriy

Ed,

Please double check that you are hitting VPN-Cubed Manager HTTPS web admin console on port 8000 and that you have opened such access (tcp port 8000) in your security group.

- Dmitriy

RC,

Could you please try this bundle instead?

http://elasticserver.com/bundles/3583...

I think it doesn't have this problem and includes a gem as well as .so file.

HTH,
Dmitriy

Tito,

I will respond to you in private via email.

- Dmitriy

The manager's virtual IP address in your case is 172.31.0.1. Can you try that please?

Also, please double check local firewall on your client instance.

- Dmitriy

Hi Wade,

Could it be that multicast traffic is blocked by local Windows firewall(s) on source and/or destination instance(s)? Note that you may need to explicitly disable Windows firewall on tunnel interface *in* *addition* to disabling it on ethernet interface.

If it's not firewall, please contact us at support _AT_ cohesiveft.com to continue troubleshooting in private.

- Dmitriy

Hi Neo,

No, not at the moment. We currently don't offer a CLI interface for functionality available via web-based administration tool. We are looking at potentially doing something like this in the future though.

- Dmitriy

Hi Stuart,

Could you please double check which AMI ID you are running? You should be able to get this information via ElasticFox, AWS console or command line tools.

IPsec gateway AMI is ami-efc22486.

Please note that VPN-Cubed for EC2 free and paid editions do not include support for IPsec.

- Dmitriy

Sounds like a security group issue.

Please add your remote clients' Internet IP addresses to a managers' security group and it should work:

ec2auth MANAGER_GROUP -P udp -p 1194 -s INET_IP_ADDR/32

You can specify your entire subnet in -s option.

ElasticFox offers similar functionality, so you don't need to use command line tools for this.

Cheers,
Dmitriy

Hi there,

Have you seen this?

http://getsatisfaction.com/cohesiveft...

You can follow a similar procedure for Rails.

The power of Elastic Server factory is that users just like you can upload content and create components that make up your stack, and then you can share it with others.

Happy to give you additional assistance in private - email [support] at [elasticserver.com].

Cheers,
Dmitriy

Hi Joel,

Let me address your questions in reverse order.

The number of machines your VPN-Cubed can support simultaneously is determined by the number of clientpacks in your VPN-Cubed edition.

Also, It doesn't matter if your client machines are behind NAT or not - they should be able to connect individually and get their unique IP addresses. Are you sure each of your machines has a unique clientpack installed on it? Do you see each connected client on Runtime Status screen in the GUI?

If your firewall for some reason can't deal with same source ports of your connections, you can use "lport PORT" command in your clientpack's vpncubed.conf to randomize the ports on different clients (i.e., assign unique local port to each client).

Regarding connectivity. Each Elastic Server ships with local iptables-based firewall, which is managed by a program called "shorewall." Traffic within the overlay network flows on tun0 network interface on the clients.

Based on this, I suspect that your EC2-based elastic server does not have rules in its local iptables firewall to allow traffic on tun0 (default firewall created at assembly time deals only with eth0). You may see firewall rejecting packets on tun0 by running "dmesg" or in one of the log files (/var/log/syslog or similar).

If you allow traffic on tun0 using command line tools on your EC2 elastic server, provided I didn't miss anything in your topology setup, it should work.

Something like this might work:
/sbin/iptables -I INPUT 1 -i tun0 -p tcp --dport 22 -j ACCEPT

You should also re-enable Amazon security groups for extra protection (if you disabled them). But please note that traffic within overlay network does not get matched against security groups, because it's tunneled and encrypted.

I hope I answered your questions. If not, maybe you could clarify what's going on and we will look into it. If you'd like to continue troubleshooting in private, please send us an email to support (at) elasticserver.com

- Dmitriy

Hi Haichang,

It's definitely something wrong with your security group setup.

Could you also please double check that you launched the instance with the security group that you are modifying and where you added tcp/8000 rule? Or if it's running with "default" security group, then it's the one you modified.

One big possibility is that you wanted to start an instance with some special security group (where you probably added all rules according to our documentation), but for some reason you started it with "default" security group.

- Dmitriy

Hi Thomas,

The admin interface is running on https on port 8000. Does it time out for you or does it return any error?

Several questions to help us understand your scenario a little bit better.

Did you allow access to this port from your IP address in your EC2 security group? If you are not sure, try temporarily opening this port to entire Internet:

ec2auth GROUP-NAME -P tcp -p 8000 -s 0.0.0.0/0

(We don't recommend to run with this permission in place for too long).

You can determine your Internet IP address by visiting http://checkip.dyndns.org

What browser are you using? If it's Firefox 3, does it warn you about invalid SSL certificate (in reality it's not invalid, but self-signed)? If yes, did you try adding this certificate as an exception in your browser?

- Dmitriy

Hi David,

We completed rollout of this fix. The issue affected S3 buckets created via Elastic Server site in US region, and we believe it's now resolved.

Again, we are sorry for the inconvenience it caused.

- Dmitriy

Hi David,

We are aware of the issue you are referring to. A fix is almost ready and will be rolled out as soon as it passes QA. We will update this thread when the fix is up on the site.

We are sorry for the inconvenience and will get this resolved ASAP.

- Dmitriy

If your package provides a daemon, the best place to set environment variables for it would be its startup script.

On the other hand, if your package is a library or a command line tool and you want to make sure that all users who log in to the system will have your variable set in their environment, you can append its definition to /etc/profile.

For example, if you use Filesystem Tree Archive, you can specify something like this in your postinstall script:

#!/bin/bash

echo 'export MYVAR="value" ' >> /etc/profile

exit 0

Or you can use Run On-Boot Script to do the same.

If neither of these approaches work well for you and you can share more details about your package, we might be able to come up with a better way to implement it.

Hope this helps,

Dmitriy

Hi Barry,

I would like to ask you a couple of questions about your setup.

Do you have any other VMs running on this host in Bridged Mode under Vmware Player that do get an IP from DHCP and can go out to Internet?

Do you know if your DHCP server assigns IPs based on MAC addresses and hence restricts which MAC addresses it will respond to? (In this case, I guess you'd have to add elastic server's MAC address to your DHCP server config.)

When you statically assign an IP to your Rails elastic server, you can't ping google but since you were able to ssh from another host on your LAN, I assume you can ping hosts on your LAN, right? In that case, could it be your firewall blocking elastic server's access to the Internet?

- Dmitriy