VPN protocols

Michael2

While studying for the Sec+, I came across an article that listed some of the more common encryption protocols (PPTP, L2TP, IPSec, MS-CHAP, etc.) and when to use each one. I read that PPTP is the only one capable of passing through an NAT firewall which I thought was interesting. The article also said that L2TP should be used if IPSec-tunnel is being used (and if your VPN is not behind an NAT firewall). Does this mean that L2TP cannot be used with IPSec-transport? Do you even have to be using IPSec to run one of the other protocols like MS-CHAP or can you run PPTP and MS-CHAP without IPSec?

docrice

PPTP uses two "channels" for communication: TCP 1721 as well as GRE (Generic Routing Encapsulation, protocol 47). MS-CHAP is one of the user authentication options, but's not a VPN encryption protocol in itself. In other words, MS-CHAP isn't used to encrypt packets.

IPsec is relatively complicated, and you're certain to hear terms like "ESP" (Encapsulating Security Payload) and "AH" (Authentication Header) thrown around (protocols 50 and 51). In a nutshell, there are more knobs to turn with IPsec. You have a session initialization which typically runs over UDP 500, (although it can be done over TCP) and endpoint authentication can be done via passwords, certificates, etc.. After authentication, IPsec "security associations" form tunnels and allow you to send ESP / AH packets.

Fundamentally, IPsec runs into NAT problems due to IPsec checking header integrity at the receiving end. NAT unfortunately mangles the source and / or destination IP address fields in the IP header and thus breaks the integrity check. That's where NAT-Traversal (NAT-T) comes in, typically riding over UDP 4500. So yes, NAT can be a problem, but there's a solution for it.

I think the article you're reading is approaching it from a first-basics perspective or isn't written well and is confusing you. Discussions about VPNs can't be summarized very clearly in just a paragraph or two.

it_consultant

Michael2 wrote: »

While studying for the Sec+, I came across an article that listed some of the more common encryption protocols (PPTP, L2TP, IPSec, MS-CHAP, etc.) and when to use each one. I read that PPTP is the only one capable of passing through an NAT firewall which I thought was interesting. The article also said that L2TP should be used if IPSec-tunnel is being used (and if your VPN is not behind an NAT firewall). Does this mean that L2TP cannot be used with IPSec-transport? Do you even have to be using IPSec to run one of the other protocols like MS-CHAP or can you run PPTP and MS-CHAP without IPSec?

I think you are confusing tunneling protocols, encryption protocols, and authentication protocols. A tunneling protocol like L2TP is unencrypted but it will tunnel traffic between two disparate networks. IPsec will encrypt this traffic and is best practice. IPSEC can also be run on a wired or wireless network. PPTP combines the two functions of encryption and tunneling but the encryption is somewhat weak. MS-CHAP is a simple challenge protocol which is used in order for the two devices to authenticate with each other in order to set up the initial encrypted tunnel. MS-CHAP can be used for VPNs, serial or DSL connections, etc.

Michael2

Well, the article was pretty long. I didn't read the whole thing because that wasn't my goal. If I could find the link, I'd post it. I've been searching for it all day. It might have been outdated. All that I know is that it was on technet.

Anyhow, here's another question: If PPTP won't work with IPSec and L2TP only works with IPSec-tunnel, when would you use transport mode? Don't you need to use either PPTP or L2TP for a VPN?

docrice

With IPsec, you'll hear comparisons between "tunnel" and "transport" modes (these are separate concepts from "main mode," "aggressive mode," and "quick mode" which are VPN initialization stages). The former is generally used for site-to-site and remote access VPNs. The latter is for host-to-host. The difference is that with tunnel mode the original IP header is tucked within an new outer IP header so the original packet in its entirety is protected. With transport mode, the IPsec header is wrapped within the original IP header.

Confused yet? Don't be embarrassed if you are. This whole process of taking the original message, putting it inside a tamper-sealed FedEx box, then putting that whole thing into a UPS box and sending it off gets confusing for those new to VPNs and the encapsulation / decapsulation process.

Michael2

This book I'm using has some confusing information in it. The book says that the way to protect your network traffic when users are connected to a public network is to use a VPN. The thing is it says public network so I'm thinking antivirus software. The question literally says users; what users is not specified. Is this just an issue of the question being worded inappropriately or is it actually possible for authorized users to jump on and off a VPN?

instant000

Michael2 wrote: »

This book I'm using has some confusing information in it. The book says that the way to protect your network traffic when users are connected to a public network is to use a VPN. The thing is it says public network so I'm thinking antivirus software. The question literally says users; what users is not specified. Is this just an issue of the question being worded inappropriately or is it actually possible for authorized users to jump on and off a VPN?

It's possible for "authorized" users to get on or off a VPN connection.

Depending on your configuration, you can "split tunnel" which means you can send some traffic to the VPN, and some traffic to your other connection. (I feel that this is less secure).

They're saying it protects it on a public network like so:

If a user on the public network communicates to your system, that traffic goes across the internet, where tons of people are out there trying to sniff what traffic you're sending.
If that user turns their system into a VPN endpoint, then all the traffic that leaves their system is encrypted, and if it is secure enough, only the remote end should be able to decrypt the transmission.

I'm not sure if you'll really begin to understand it much, until you start playing with configuring it, to be honest.

you can read the Welcome to The TCP/IP Guide!, if you want another slant on things. I just like to reference that one, as it's a free site.

Michael2

Okay, the thing that confused me is that the question says "users connected to a public network." This comes from the CompTIA SY0-301 Practice Exams by LaChance and Clarke, published by McGraw-Hill. My question is; if users of a VPN must first authenticate to a RADIUS server (TACACS for legacy equipment), they're not really connected to the public network, are they? Wouldn't that mean it's no longer necessary to protect them from public network traffic?

docrice

Here's the classic remote access VPN sequence of events:

1) User connects to the Internet via Wi-Fi, 3G / 4G, dial-up, home LAN connection, etc.. Machine is now connected (directly or indirectly) to the Internet.

2) User needs to access a resource (file server, mail server, etc.) located within his company's headquarter's private network behind their firewall.

3) User starts a VPN client app on the machine which then makes the initial contact to the company's VPN gateway (which the firewall could be acting as, but it could also be a dedicated VPN appliance). This VPN gateway has an outside and inside interface. The outside interface connects to the Internet.

4) The VPN client negotiates a first-phase encrypted connection and passes user credentials to the gateway.

5) The gateway takes these credentials and (if the user account is not defined on the gateway itself) passes it over to a AAA / user account database through the RADIUS protocol (or LDAP or whatever).

6) Assuming the RADIUS server / AAA / user account database gives a thumbs up, the VPN gateway and VPN client negotiate further session parameters. The tunnel forms as both the client and gateway now know the session-specific keying parameters, how to tunnel what packets in what mode, etc..

Michael2

Is there a difference between joining an Active Directory domain and logging into the domain to receive security settings? The book is suggesting that they are separate steps. Don't you have to log in to join the domain, and aren't the settings automatically loaded to your computer when you do log in?

docrice

Joining an Active Directory domain is the process of establishing authorization to sync security policies between your machine and the LDAP database on the AD domain controllers. Essentially, joining means that a computer account for the member machine is created and therefore becomes authorized to receive policies set by the AD admins. When initially joining a computer machine to a domain, a domain admin (or at least someone who is a member of the domain's Account Operators group) has to authorize it through a prompt during the time of joining.

Logging into the domain can mean several things depending on the context. Typically, a user logging into the domain means that once the user enters domain account credentials into his machine, the machine then locates via DNS a DC that's part of the domain the machine is a member of, establishes a "secure channel" and passes those credentials for LDAP authentication, and once the username / password is verified, the machine receives a thumbs up by the DC, the Local Security Authority on the client-side generates a session security token for the user account, runs Explorer.exe and creates the desktop environment for the user, and subsequent processes run under the context of that account.

Before the user logs into the domain, the machine also logs into the domain as well if it's connected to a network which can talk to the DCs. It basically authenticates via its machine account and downloads machine-specific Group Policy configuration. When the user logs in and goes through the process in the previous paragraph, user-specific policies are downloaded from the DC and applied as well.

This is quite a bit off-topic from the subject of VPN protocols.

Michael2

Okay, now I understand. When they say 'join" Active Directory, they're talking about the machine and not the person. When they say 'log in', they're talking about a person logging in to a machine that's already part of the Active Directory structure.

it_consultant

Michael2 wrote: »

Okay, now I understand. When they say 'join" Active Directory, they're talking about the machine and not the person. When they say 'log in', they're talking about a person logging in to a machine that's already part of the Active Directory structure.

Maybe. Logging into Active Directory actually supplies you with a kerberos ticket which lets you access network resources without having to repeatedly input your password every time you go to a resource. You join a computer to AD and you login to AD. The machine gets its own GUID and everything when you join it to the domain.

Michael2

I believe I understand IPSec a little more now. I did some more research and found out that it uses ESP to encapsulate the entire datagram, including the header, inside another packet with a different header and digitally signs the whole thing. This is known as tunnel mode. This mode of communication is used on VPNs and is more secure than AH which simply encrypts the payload and inserts an authentication header into the datagram. AH is rarely used in VPNs nowadays, but is still used in transport mode for authenticated transfer between nodes on a LAN.

Bl8ckr0uter

instant000 wrote: »

It's possible for "authorized" users to get on or off a VPN connection.

Depending on your configuration, you can "split tunnel" which means you can send some traffic to the VPN, and some traffic to your other connection. (I feel that this is less secure).

I agree with your thoughts on split tunneling. I don't like it and I am very much against it in most cases

» VPN Split Tunneling - Roger's Information Security Blog
https://social.technet.microsoft.com/wiki/contents/articles/why-split-tunneling-is-not-a-security-issue-with-directaccess.aspx - Interesting

Understanding Split Tunneling