14

This is a follow-up to my Encrypting absolutely everything... question.

Important: This is not about the more usual IPSec setup, where you want to encrypt traffic between two LANs.

My basic goal is to encrypt all traffic within a small company's LAN. One solution could be IPSec. I have just started to learn about IPSec, and before I decide on using it and dive in more deeply, I'd like to get an overview of how this could look like.

  • Is there good cross-platform support? It must work on Linux, MacOS X and Windows clients, Linux servers, and it shouldn't require expensive network hardware.

  • Can I enable IPSec for an entire machine (so there can be no other traffic incoming/outgoing), or for a network interface, or is it determined by firewall settings for individual ports/...?

  • Can I easily ban non-IPSec IP packets? And also "Mallory's evil" IPSec traffic that is signed by some key, but not ours? My ideal conception is to make it impossible to have any such IP traffic on the LAN.

  • For LAN-internal traffic: I would choose "ESP with authentication (no AH)", AES-256, in "Transport mode". Is this a reasonable decision?

  • For LAN-Internet traffic: How would it work with the internet gateway? Would I use

    • "Tunnel mode" to create an IPSec tunnel from each machine to the gateway? Or could I also use
    • "Transport mode" to the gateway? The reason I ask is, that the gateway would have to be able to decrypt packages coming from the LAN, so it will need the keys to do that. Is that possible, if the destination address isn't the gateway's address? Or would I have to use a proxy in this case?
  • Is there anything else I should consider?

I really just need a quick overview of these things, not very detailed instructions.

3 Answers 3

7
  • Is there good cross-platform support? It must work on Linux, MacOS X and Windows clients, Linux servers, and it shouldn't require expensive network hardware.

I don't really have much experience with this, as I mainly have Linux systems, but I did get it mostly working on a Windows 2000 machine (this was some time ago). It had a problem that the IPsec failed to renegotiate a new session key after some number of bytes had been transferred (this is supposed to happen automatically), so the connection went down after a while, and I could never be bothered to dig into it further. It probably works much better nowadays.

  • Can I enable IPSec for an entire machine (so there can be no other traffic incoming/outgoing), or for a network interface, or is it determined by firewall settings for individual ports/...?

How it works is (or, rather, how I managed to get it working), you define that a machine foo must use only IPsec to machines bar, baz, and yow. Any traffic from and to these machines is now secure and as trustworthy as those machines are. Any other traffic is not IPsec and works normally.

  • Can I easily ban non-IPSec IP packets? And also "Mallory's evil" IPSec traffic that is signed by some key, but not ours? My ideal conception is to make it impossible to have any such IP traffic on the LAN.

IPsec traffic is only allowed for those IPsec "policies" that you define, so any random machine cannot send IPsec packet - there must exist an IPsec policy matching those packets.

  • For LAN-internal traffic: I would choose "ESP with authentication (no AH)", AES-256, in "Transport mode". Is this a reasonable decision?

Yep. There is talk about abandoning AH completely because it's redundant - you can use ESP with NULL encryption with the same effect.

  • For LAN-Internet traffic: How would it work with the internet gateway? Would I use
    • "Tunnel mode" to create an IPSec tunnel from each machine to the gateway? Or could I also use

I would choose this option. As it is I don't control the gateway myself, and the traffic will be unencrypted outside my network anyway, so I don't really see a pressing need.

Internet traffic to hosts which does not use IPsec must be seen as possibly being intercepted - there's little point in encrypting on the local LAN when your ISP or your ISP's ISP can listen to the same packets unencrypted.

  • "Transport mode" to the gateway? The reason I ask is, that the gateway would have to be able to decrypt packages coming from the LAN, so it will need the keys to do that. Is that possible, if the destination address isn't the gateway's address? Or would I have to use a proxy in this case?

As I understand it, that does not work - you would need a proxy.

  • Is there anything else I should consider?

See if you can use something sensible like OpenPGP keys instead of X.509 certificates. I use X.509 since that was the only thing supported by the IPsec keying daemon I first used, and I haven't had the energy to look into redoing it all. But I should, and I will, someday.

P.S. Me and an associate held a lecture on IPsec in 2007, it may be of help to clarify some concepts.

1
  • @Teddy: Fantastic answer (+++1) I also scanned quickly across the PDF you linked to - it looks very much like what I need! Apr 8, 2010 at 20:33
0

This sounds a bit like overkill. I can't say that I've ever heard of anyone encrytpting all traffic on their LAN. What's your driving motivation for doing this?

9
  • @joe: I'm not yet sure, if I really want to do this or not. It may sound crazy, but I really want to simplify my LAN's security concept. WLAN access will be allowed, so I will have to do something against attacks. Either it'll be an elaborate IDS setup, or my crazy idea of encrypting everything. Please see my original question, if you want to hear all the details :-) Apr 8, 2010 at 18:32
  • It does sound crazy. I'm no IPSEC expert so I don't have any help for you but I'm going to follow this post as it's got my interest up.
    – joeqwerty
    Apr 8, 2010 at 18:53
  • 5
    It isn't a crazy idea at all. Encrypting everything is something that many folks have considered, particularly those is secure environments. AFAIK, this is one of the driving reasons behind including IPsec in the IPv6 spec: so all endpoints can encrypt all traffic. @chris_l, I wish you luck and hope you decide to do it. Please share how it turns out. Apr 8, 2010 at 20:34
  • 1
    So you utterly trust everyone on your LAN? Even though anyone with a laptop or able to crack your wireless (or is it unencrypted?) can access your LAN at will? If you really trust everyone on your LAN, I might ask why you have a password on the consoles of the machines connected to it - aren't the people in the building trustworthy? The answer is, of course, "NO", and that is why LAN traffic, like any other traffic, should be encrypted.
    – Teddy
    Apr 8, 2010 at 20:36
  • 1
    @Teddy: I didn't say that I trusted or didn't trust anyone or anything. I only said that it sounds like a crazy idea to me. Don't infer what you think I mean, there's nothing between the lines in my answer or comments, only curiosity.
    – joeqwerty
    Apr 8, 2010 at 20:53
0

IPSec is great for connecting to untrusted networks (ie. Web DMZs, etc) and within and networks that are segregated with firewalls. Apps that use RPC protocols (ie. Microsoft AD, etc) like to use high ephemeral port ranges, which doesn't jive with the firewalls. Within the LAN, your benefits depend on a number of factors.

It's not a silver bullet, and it isn't going to necessarily simplify network security. It will help you to operate services on the internet or other untrusted networks without making huge investments in network gear.

If you're doing this as an exercise or learning experience, that's fine, but nothing that you've posted up to this point makes a compelling argument to do what you're talking about.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .