1

How one encrypts traffic in wired LAN segment?

Can IPv6 in combination with IPSec be configured for IKE/ISAKMP authentication?

OR

Will I drown in configuring appropriate IKE host-to-host rules for the ISAKMP?

OR

Should I look towards 802.1X-2010 which according to Wikipedia supports "service identification and optional point to point encryption over the local LAN segment"?

Let's say my LAN segment consists mostly of Windows 7 and higher PCs, few FreeBSD VMs. Switches are moderately modern DLINKs, routers are from Mikrotik.

4
  • how one encrypts traffic in wired LAN segment? - Is this something you really need to do?
    – joeqwerty
    Jun 14, 2016 at 19:48
  • @joeqwerty Yes I do. 1) Unfortunately, physically securing the network perimeter isn't possible. 2) Unfortunately, there are some network services working in LAN which don't use encryption.
    – P. D
    Jun 14, 2016 at 19:56
  • You can't physically secure the network perimeter (the easy part) but you want to encrypt the LAN (the hard part)? Jun 14, 2016 at 19:57
  • @MarkoPolo In the case I'm dealing with it's not possible to move all 'risky' network ports to DMZ-s, so it's not that easy securing perimeter physically. So it's more like "I have to" than "I want to". Also, I'm curious if and how it's possible
    – P. D
    Jun 14, 2016 at 20:00

1 Answer 1

3

You can go all-IPSec, no need for IPv6 necessarily. Obviously there will be some management required, all hosts need to have the IPSec rules. In a pure Windows/AD environment, it's almost easy; the GPOs for server<->client IPSec are all available to use, and generally clients don't talk to each other. Exceptions can include SIP traffic of course, or any other P2P chat protocol.

If you just implement 802.1x, you're implicitly trusting your now-authorized-and-authenticated endpoints, which could still sniff traffic.

5
  • +1, and blocking the user to be a local admin make that risk less problematic (and it should be that way if domain joined usually), as the winpcap driver need to be installed.
    – yagmoth555
    Jun 14, 2016 at 20:11
  • 1
    +1 IPSec in transport mode is made for precisely this use case. Don't try and implement IPSec in tunnel mode for this - you'll have a bad day.
    – EEAA
    Jun 14, 2016 at 20:49
  • @mfinni In the particular environment there's plenty of client<->client traffic, unfortunately... So it will be necessarily to determine rules for every single client x client combination? No options for automation? At least in case of IPv6?
    – P. D
    Jun 14, 2016 at 21:03
  • @EEAA I've set up a lot of IPSec tunnels in my life, but no transport-only ones. I would appreciate if you could present some links for this kind of deployment. Shame on me, but can't google any.
    – P. D
    Jun 14, 2016 at 21:07
  • @P.D I have a brief write-up on my (horribly neglected) blog about getting this set up on Linux. I have no experience doing on on Windows, though, unfortunately.
    – EEAA
    Jun 14, 2016 at 21:10

You must log in to answer this question.

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