Get your own customer support community
 

Why won't some of my VPN-Cubed clients talk to each other?

I have successfully established a VPN-Cubed environment between a physical datacenter, an EC2 elastic server (Ubuntu 8.10 built from elasticserver.com), and a remote client.

However, I am unable to connect to any of the services on the EC2 elastic server from the other VPN-Cubed clients.

External access to the EC2 server (ports 22, 8080, etc.) works fine.
For testing I turned off the firewall on the EC2 elastic server and verified that the Amazon security group is allowing port 22 for SSH.
On any of the other VPN-Cubed clients I can not access port 22 (or any other port) on the EC2 Elastic server, yet I can create an SSH session FROM the EC2 server to the clients.
The other VPN-Cubed clients have full access to each other.
I have tried numerous changes to the Amazon security groups and nothing seems to work.
I have also noticed that only one machine can be connected to the VPN-Cubed manager per physical ip address. In my case this is the physical address of a firewall with a number of machines behind it in a datacenter. I would like to connect multiple machines behind the firewall as VPN-Cubed clients.

Any suggestions would be greatly appreciated,

Joel
Inappropriate?
1 person has this question

  • Inappropriate?
    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
  • Joel Stachowicz
    Inappropriate?
    Dmitriy,

    Thanks for the quick response!

    Yes, all of the clients showed up in the Runtime Status screen in the gui.

    You were exactly correct. Once I enabled access to port 22 for tun0 on the EC2 elastic server then connectivity from the other clients worked fine.

    I am still testing the lport option in the vpncubed.conf files, but it looks like that will also solve the other issue.

    Many thanks for your help,

    Joel
     
    happy
User_default_medium