Private network traffic between two accounts

According to their FAQ, yes:

http://www.linode.com/faq.cfm#what-can- … le-linodes">http://www.linode.com/faq.cfm#what-can-i-do-with-multiple-linodes

It does not specify whether it works between two Linodes on separate accounts. I use the private network a lot between Linodes on the same account, but the Linode on a separate account is unable to communicate with the others.

@carmp3fan:

Is this true? Yes.

-Chris

@carmp3fan:

.. I use the private network a lot between Linodes on the same account, but the Linode on a separate account is unable to communicate with the others.

If they are in the same data center and you've requested a private ip through the linode manager and set up a static config, you should be good to go (reboot?).

@devjonfos:

(reboot?)
Yes – reboot to bring up the new IP.

Don't forget to firewall the private interface, or other customers may be able to connect to whatever services you're running on that IP. As far as I'm aware of, it's "private" only in the sense that it's not accessible from outside the datacenter. A malicious Linoder in the same datacenter would have no trouble finding you (although they tend to get kicked in the butt very soon).

In addition to firewalling your private interfaces, I would also suggest using something like IPSec in transport mode between the machines so that the traffic can't be snooped upon.

@jkfritcher:

In addition to firewalling your private interfaces, I would also suggest using something like IPSec in transport mode between the machines so that the traffic can't be snooped upon.
If you are concerned about snooping, I'd go with tunnel mode - transport mode only encrypts the payload, so the original header on each packet is unchanged, which can be useful information to snoopers. I tend to use OpenVPN for such tunneling, but that's just personal preference.

To be honest though, I'm not sure that snooping is even a risk in this sort of setup?

I presume the main network network infrastructure is purely switched, so traffic will only show up on the host's interface that contains the target Linode and no other hosts. So that immediately shrinks the pool of possible snoopers immensely. But of course, only the individual Linode should see the traffic as passed on via the host barring a Linode cracking into the hypervisor which seems unlikely.

It's not like individual Linodes are on common, non-switched segments. I'd think attacks would have to be directed at specific Linode addresses and not by passive monitoring.

– David

@db3l:

…

To be honest though, I'm not sure that snooping is even a risk in this sort of setup?

…

Wireshark data from putting eth0 in promiscuous mode?

@devjonfos:

Wireshark data from putting eth0 in promiscuous mode?
And Linode allows the local interfaces to be put into promiscuous mode?

If so, that seems like a bit of a security loophole.

@devjonfos:

Wireshark data from putting eth0 in promiscuous mode?
Promiscuous mode can still only see actual packets that arrive at the input of the interface being monitored. That means only those packets that (a) get to the physical interface on the host itself, and (b) get passed along by the xen hypervisor to the virtual interface of your Linode. Infrastructure switches should prevent traffic other than that destined for all the Linodes on a given host from reaching (a), and from there, the xen hypervisor is in control of how traffic gets to a Linode domU virtual driver.

I suspect that aside from the occasional broadcast, not much traffic other than that directed specifically to your Linode is going to get through (a)+(b), no matter what you do at the virtual interface level from within your Linode itself.

You definitely still want to apply filters on your private interface since active attacks against its address are easy. Secure tunnels between Linodes certainly won't hurt (and can simplify some items like an internal addressing scheme), but I just don't know that worrying about passive snooping attacks need be a major concern, or if realistically possible at all.

– David

@vonskippy:

And Linode allows the local interfaces to be put into promiscuous mode?

If so, that seems like a bit of a security loophole.
Promiscuous mode would be within the context of the driver, since it's just telling the driver to pass along everything it sees on the interface's "wire". But in a Linode case, the "wire" is "virtual", represented by the internal connection between the virtual network driver and the hypervisor.

So I suspect promiscuous isn't a problem (I don't think I had a problem with tcpdump, for example), but it's still limited to whatever traffic is presented to the virtual driver by the xen hypervisor.

It's analogous to the issues with trying to snoop on a switched network with regular hosts - you won't see unicast traffic among hosts not involving your port since the switch (unlike the older hubs) only passes traffic down the needed port that contains the device with the target mac address. That's also why some switches can support replicating traffic down a dedicated port specifically for such monitoring, but then you need management control over the switch itself.

In this context, the bridging done by the xen host among all its guest virtual interfaces is essentially another network switch.

– David

The topic has majorly evolved into a completely new set of topics, all of which I am already well aware of. Back to the original problem.

While I eventually just used the public network since this was a test system, I did experience problems trying to communicate between two Linodes on different accounts. I verified the private IP addresses were assigned correctly, I verified no traffic was arriving at the target system using tcpdump, I verified no firewall rules were in place (even though tcpdump captures prior to the firewall process receiving the traffic. I had tested this in both directions and I was never able to get the two to communicate.

Just a few minutes ago I figured out the problem. While I had verified the /etc/sysconfig/network-scripts/ifcfg-eth0:0 file contained the right information, I had not verified it with ifconfig. Come to find out, I used NETMAKS instead of NETMASK, thus causing the interface to default to 255.255.255.0 and not 255.255.128.0. Once I corrected this everything started to work without a problem.