Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

What standards/protocols/products exist that support encryption of all data sent between a device (e.g. a workstation) and a LAN switch? Something like WPA for WLAN.

share|improve this question
IPSec is a higher layler protocol, do you specifically want Link Layer encryption? – Marcin Dec 5 '11 at 13:50
up vote 1 down vote accepted

I"m not sure how to reply to the above post but here's my response to your question to Rory. In multi-host mode, you can support multiple clients behind a single port but it isn't great because as long as one device authenticates, the entire port is authorized for all clients. Multi-auth is better because it forces each unique mac to authenticate but you lose the ability to use guest vlans, authentication fail vlans and multiple radius provided vlans in certain cases. Also, there is a bug in multi-auth and multi-domain in IOS 12.2(54) SG1 on at least the 4500 series switches. See for details: I have these features working with netgear and d-link little 5 port desktop switches - not just Cisco branded gear. Dot1x is more for authenticating clients before they connect to the network. For client to server encryption IPSec is the way to go and can be configured completely (and for free) via GPO

share|improve this answer

Any IP traffic can be secured using IPSEC – whether it's on LAN or WAN.

However, it is more complicated in LANs – as you have to deal with setting up SA's (security associations) and key management (if not using PSKs). With Windows you can integrate the key management into active directory, but you also need Certificate infrastructure to support distribution of certificates to clients, and how do they get the certificates if traffic isn't already encrypted.

share|improve this answer
I have found some information about Cisco TrustSec, it talks about IEEE 802.1AE for encryption and 802.1X for authentication, access control etc. I think this is more like what our company is looking for, as IPsec seems to be more for encryption between a server and client, not between 2 clients. – Alex Nov 30 '11 at 7:25
IPsec will encrypt any TCP/IP connection. It's definitely the way to go. – Joel E Salas Nov 30 '11 at 7:29
It's strange that nobody suggests 802.1X-2010 – Alex Nov 30 '11 at 8:11

802.1x works fine on a single vendor LAN (my experience has been with Cisco ones) - and in fact has less challenges from a management perspective than IPSec in an Enterprise environment.

If you use Cisco for your LAN I'd probably suggest this as it is straightforward to implement.

share|improve this answer
Does this option mean we have to connect all endpoint devices to Cisco switch ports (which means more cables in the walls and more or bigger Cisco switches), or we can still use "small" switches/hubs in each department (room)?? I have heard mixed feedback, some say each port can only authenticate one device attached to it (making use of hubs impossible), others say there is MultiAuth, MultiHost modes (with not much documentation on this), yet others say MultiAuth and MultiHost modes are for Cisco branded devices only (like their access points, sip phones etc). – Alex Dec 1 '11 at 1:49

Previous posts mention 802.1x but don't really go into much detail. 802.1x has been around for a long time (major IEEE spec in 2004), but there was always a concern about guaranteeing client integrity post authentication. Rogue packet injection and monitoring after authentication using a wired hub was always a possibility (Good luck placing an ageing hub + attack box unnoticed on someone's desk, though). NAC as a concept was in part meant to solve this, but never did so as cleanly as 802.11i.

802.1x had a standards revisions in 2010 (802.1x-2010, also known as 802.1x-REV), which incorporated a 2006 standard (802.11AE) addressing Alex's specific requirements. Check out MacSec Encryption. IEEE now has free to download specifications, which are interesting.

MacSec is designed as a parallel to the security provided by WPA2-AES (802.11i), with both encryption schemes being driven by 802.1x EAP (Extensible Authentication Protocol) authentication to a RADIUS server. MacSec assures packet integrity at the link-layer and protects against packet injection and monitoring.

Cisco is as of this post the most advanced with regards to implementing and supporting 802.1x-2010, but I'm seeing hints of pending support from other hardware vendors (some Juniper switches are MacSec 'ready'). There are three bits you need to get it all working though and only Cisco currently has all three bits in a commercial state: - An 802.1x supplicant that can do EAP authentication and MacSec encryption in software and/or work with a hardware NIC that supports MacSec in hardware. - A switch that can be configured for MacSec Encryption on a port. - A AAA server that can deliver all the keying material as part of the EAP Accept response.

The real world value of MacSec is open to debate. If someone can get close enough to tap a network cable, you're in bigger security strife.

share|improve this answer

you mean something like RADIUS?

share|improve this answer
Almost certainly not - Radius is an AAA solution, it does nothing at all to encrypt transmitted data. – Chopper3 Dec 5 '11 at 12:30
right; i don't see why OP wouldn't just run IPSEC over RADIUS and be done with it. auth plus encryption. i felt the need to mention IPSEC redundant, as it's already been mentioned. – brent saner Dec 5 '11 at 12:40
and again this makes no sense at all - can you explain what you mean by this please - Radius is simply an AAA solution and has no bearing whatsoever on encryption. – Chopper3 Dec 5 '11 at 12:55
it doesn't have anything to do with encryption, no. but take note of OP's request: "...Something like WPA for WLAN." if he's looking to emulate that sort of implementation into a LAN analog, he'll want the encryption (which could be handled by, as others have mentioned, IPSEC) AND an underlying auth framework- per my suggestion, RADIUS. i have a feeling this is getting us nowhere, so i'm done discussing this as we seem to be going in circles. – brent saner Dec 5 '11 at 13:01

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.