vpdn vpn agenda - home | institute of computer · pdf file · 2011-09-13institute...
TRANSCRIPT
Institute of Computer Technology - Vienna University of Technology
L84 - VPN and VPDN in IP
© 2006, D.I. Manfred Lindner
Page 84 - 1
VPN
Virtual Private Networks IntroductionVPDN Details (L2F, PPTP, L2TP)
© 2006, D.I. Manfred Lindner VPN Intro + VPDN, v4.3 2
Agenda
• VPN– Classical Approach
– Overview IP Based Solutions• IP addresses non overlapping
• IP addresses overlapping
• MPLS-VPN
• VPDN– RAS Primer and VPN Dialup Issues
– L2F
– PPTP
– L2TP
Institute of Computer Technology - Vienna University of Technology
L84 - VPN and VPDN in IP
© 2006, D.I. Manfred Lindner
Page 84 - 2
© 2006, D.I. Manfred Lindner VPN Intro + VPDN, v4.3 3
Virtual Private Networks (VPN)
– old idea• private networks of different customers can share a single WAN
infrastructure
– since 1980´s public switched data networks (PSDN) were offered by providers (e.g. PTTs)
• to give open access to subscribers of a PSDN
• to interconnect parts of a physically separated private network
– do you remember• closed user group of X.25
• closed user group of ISDN
• PVC-DLCI´s of Frame relay
• PVC-VPI/VCI´s of ATM
• private subnetwork (customer gateway) and public MAN service (edge gateway) of MAN -> closed user group of MAN (Metropolitan Area Network based on 802.6 DQDB)
© 2006, D.I. Manfred Lindner VPN Intro + VPDN, v4.3 4
Classical VPN´s
– X.25, Frame Relay or ATM in the core
– dedicated physical switch ports for every customers CPE• router, bridge, computer
– customer traffic separation in the core done by concept of virtual circuit
• PVC service– management overhead
• SVC service with closed user group feature– signaling overhead
– separation of customers inherent to virtual circuit technique
– privacy is aspect of customer• in most cases overlooked
VPN‘s based on Overlay Model
Institute of Computer Technology - Vienna University of Technology
L84 - VPN and VPDN in IP
© 2006, D.I. Manfred Lindner
Page 84 - 3
© 2006, D.I. Manfred Lindner VPN Intro + VPDN, v4.3 5
Physical Topology of Classical VPN
Customer ALocation A1
Customer BLocation B1 Customer A
Location A2Customer BLocation B2
Customer ALocation A3
Customer BLocation B3
Customer ALocation A0
Customer BLocation B0
WAN Switches
© 2006, D.I. Manfred Lindner VPN Intro + VPDN, v4.3 6
Logical Topology Classic VPN (1)
Customer ALocation A1
Customer BLocation B1 Customer A
Location A2Customer BLocation B2
Customer ALocation A3
Customer BLocation B3
Customer ALocation A0
Customer BLocation B0
Hub and SpokePartial Mesh
Institute of Computer Technology - Vienna University of Technology
L84 - VPN and VPDN in IP
© 2006, D.I. Manfred Lindner
Page 84 - 4
© 2006, D.I. Manfred Lindner VPN Intro + VPDN, v4.3 7
Logical Topology Classic VPN (2)
Customer ALocation A1
Customer BLocation B1 Customer A
Location A2Customer BLocation B2
Customer ALocation A3
Customer BLocation B3
Customer ALocation A0
Customer BLocation B0
Full Mesh
© 2006, D.I. Manfred Lindner VPN Intro + VPDN, v4.3 8
Agenda
• VPN– Classical Approach
– Overview IP Based Solutions• IP addresses non overlapping
• IP addresses overlapping
• MPLS-VPN
• VPDN– RAS Primer and VPN Dialup Issues
– L2F
– PPTP
– L2TP
Institute of Computer Technology - Vienna University of Technology
L84 - VPN and VPDN in IP
© 2006, D.I. Manfred Lindner
Page 84 - 5
© 2006, D.I. Manfred Lindner VPN Intro + VPDN, v4.3 9
Virtual Private Networks based on IP
– single technology end-to-end• IP forwarding and IP routing
– no WAN switches in the core• based on different technology (X.25, FR or ATM) • administered by different management techniques
– but accounting and quality of service just coming in the IP world
• X.25, FR and ATM have it already
– often private means cases control over separation but not privacy
• data are seen in clear-text in the core• encryption techniques can solve this problem• but encryption means must be in the hand of the customer
VPN´s based on Peer Model
© 2006, D.I. Manfred Lindner VPN Intro + VPDN, v4.3 10
Physical Topology IP VPN
Customer ALocation A1
Customer BLocation B1 Customer A
Location A2Customer BLocation B2
Customer ALocation A3
Customer BLocation B3
Customer ALocation A0
Customer BLocation B0
Customer EdgeCE
Provider EdgePE
Core RouterP CE
PEPE
PEPE
CECECE
CE
CE CE
Institute of Computer Technology - Vienna University of Technology
L84 - VPN and VPDN in IP
© 2006, D.I. Manfred Lindner
Page 84 - 6
© 2006, D.I. Manfred Lindner VPN Intro + VPDN, v4.3 11
Possible Solutions for IP VPN´s
• IP addresses of customers non overlapping– filtering and policy routing techniques can be used in order
to guarantee separation of IP traffic• exact technique depends on who manages routes at the customer
site
• IP addresses of customers overlapping– tunneling techniques must be used in order to guarantee
separation of IP traffic• GRE• L2F, PPTP, L2TP• MPLS-VPN
• If privacy is a topic– encryption techniques must be used
• SSL/TLS, IPsec
© 2006, D.I. Manfred Lindner VPN Intro + VPDN, v4.3 12
Tunneling Solutions for IP VPN´s
• Tunneling techniques are used in order to guarantee separation of IP traffic– IP in IP Tunneling or GRE (Generic Routing
Encapsulations)• Bad performance on PE router
– PPTP or L2TP for LAN to LAN interconnection• Originally designed for PPP Dial-up connections
• LAN – LAN is just a special case
– MPLS-VPN• Best performance on PE router
• In all these cases– Privacy still an aspect of the customer
Institute of Computer Technology - Vienna University of Technology
L84 - VPN and VPDN in IP
© 2006, D.I. Manfred Lindner
Page 84 - 7
© 2006, D.I. Manfred Lindner VPN Intro + VPDN, v4.3 13
Tunneling IP VPNs without Encryption
Intranet Internet Intranet
Intranet IntranetVirtual Private Network (VPN)
(tunneling between customer edge routers e.g. GRE)
Company A
Company A Company A
Company A
Intranet IntranetVirtual Private Network (VPN)
(tunneling between PE routers of ISP provider e.g. MPLS VPN)
Company A
© 2006, D.I. Manfred Lindner VPN Intro + VPDN, v4.3 14
Encryption Solutions for IP VPN´s
• If privacy is a topic tunneling techniques with encryption are used in order to hide IP traffic– SSL (secure socket layer)
• Usually end-to-end
• Between TCP and Application Layer
– IPsec • Could be end-to-end
• Could be between special network components (e.g. firewalls, VPN concentrators) only
• Between IP and TCP/UDP Layer
– PPTP and L2TP Tunnels• With encryption turned on via PPP option
Institute of Computer Technology - Vienna University of Technology
L84 - VPN and VPDN in IP
© 2006, D.I. Manfred Lindner
Page 84 - 8
© 2006, D.I. Manfred Lindner VPN Intro + VPDN, v4.3 15
Tunneling IP VPNs without Encryption
Intranet Internet Intranet
Intranet IntranetVirtual Private Network (VPN)
(encryption between customer edge routers or border firewalls e.g. IPsec)
Intranet IntranetVirtual Private Network (VPN)
(encryption betweenIP hosts e.g. SSL/TLS, IPsec)
Company A
Company A Company A
Company A
© 2006, D.I. Manfred Lindner VPN Intro + VPDN, v4.3 16
SSL/TLS versus IPsec
TCP
IP
Lower Layers
TCP
IPsec
Lower Layers
IP
SSL / TLS
Application Application
standardAPI
new API
Application must be aware of new application programming interface
Application can use standard application programming interface
OS
Application
Institute of Computer Technology - Vienna University of Technology
L84 - VPN and VPDN in IP
© 2006, D.I. Manfred Lindner
Page 84 - 9
© 2006, D.I. Manfred Lindner VPN Intro + VPDN, v4.3 17
Agenda
• VPN– Classical Approach
– Overview IP Based Solutions• IP addresses non overlapping
• IP addresses overlapping
• MPLS-VPN
• VPDN– RAS Primer and VPN Dialup Issues
– L2F
– PPTP
– L2TP
© 2006, D.I. Manfred Lindner VPN Intro + VPDN, v4.3 18
Physical Topology IP VPN
Customer ALocation A1
Customer BLocation B1 Customer A
Location A2Customer BLocation B2
Customer ALocation A3
Customer BLocation B3
Customer ALocation A0
Customer BLocation B0
Customer EdgeCE
Provider EdgePE
Core NodesCN
Institute of Computer Technology - Vienna University of Technology
L84 - VPN and VPDN in IP
© 2006, D.I. Manfred Lindner
Page 84 - 10
© 2006, D.I. Manfred Lindner VPN Intro + VPDN, v4.3 19
IP Addressing non overlapping (1)
• one IP address space– in the core and at the customer sites
• one routing domain– dynamic routing protocols in the core transport network
information about all customer networks and all core networks
• challenge for the provider– to give every customer only network information about
own networks
– to discard packets with wrong destination address coming from a given customer
– several ways to achieve depending on the control of the routers at the customer site
© 2006, D.I. Manfred Lindner VPN Intro + VPDN, v4.3 20
IP Addressing non overlapping (2)
Customer A176.16.2.0
Customer B176.17.2.0 Customer A
176.16.3.0Customer B176.17.3.0
Customer A176.16.4.0
Customer B176.17.4.0
Customer A176.16.1.0
Customer B176.17.1.0
CEPE
CE
PEPE
PEPE
CECE
CE
CE
CE CE
Institute of Computer Technology - Vienna University of Technology
L84 - VPN and VPDN in IP
© 2006, D.I. Manfred Lindner
Page 84 - 11
© 2006, D.I. Manfred Lindner VPN Intro + VPDN, v4.3 21
IP Addressing non overlapping (3)
Customer A176.16.2.0
Customer B176.17.2.0 Customer A
176.16.3.0Customer B176.17.3.0
Customer A176.16.4.0
Customer B176.17.4.0
Customer A176.16.1.0
Customer B176.17.1.0
Routing Table Core
176.16.1.0 - 176.16.4.0
176.17.1.0 - 176.17.4.0
Routing Table Customer A
176.16.1.0 - 176.16.4.0
Routing Table Customer A
176.17.1.0 - 176.17.4.0
© 2006, D.I. Manfred Lindner VPN Intro + VPDN, v4.3 22
Routers under different control (1)
• CE router controlled by customer:– routing:
• static routing to the core
or
• dynamic routing to the core
• (no default route)
– data packet filtering:• (incoming packets concerning source and destination address)
• (…) can be done because of security reasons
– static routes and data packet filtering means• administrative overhead at the customer site
– default routing problem e.g. for Internet connectivity• must be solved by tunneling
Institute of Computer Technology - Vienna University of Technology
L84 - VPN and VPDN in IP
© 2006, D.I. Manfred Lindner
Page 84 - 12
© 2006, D.I. Manfred Lindner VPN Intro + VPDN, v4.3 23
Routers under different control (2)
• PE router controlled by provider:– routing:
• dynamic routing in the core
• static routing to the customer with route redistribution of static routes into the core
or
• dynamic routing with route filtering to the customer
– data packet filtering:• incoming packets concerning source and destination address
– static routes / dynamic routing with route filtering and data packet filtering means big administrative overhead at the provider site and have performance impacts on PE routers
© 2006, D.I. Manfred Lindner VPN Intro + VPDN, v4.3 24
All routers under provider control (1)
• CE router at the customer site:– routing:
• dynamic routing to the core
• no default route
• PE router– routing:
• dynamic routing in the core
• dynamic routing with route filtering to the customer
• for the provider less administrative overhead than routers under different control
Institute of Computer Technology - Vienna University of Technology
L84 - VPN and VPDN in IP
© 2006, D.I. Manfred Lindner
Page 84 - 13
© 2006, D.I. Manfred Lindner VPN Intro + VPDN, v4.3 25
All routers under provider control (2)
• special case if two customers are merged at the customer edge and not at the distribution or core area
– this router needs full information about all networks• in order to forward packets to all destinations
– therefore separation of customers based on different routing tables is not possible
– hence data packet filtering is necessary• based on incoming packets concerning source and
destination address
© 2006, D.I. Manfred Lindner VPN Intro + VPDN, v4.3 26
Agenda
• VPN– Classical Approach
– Overview IP Based Solutions• IP addresses non overlapping
• IP addresses overlapping
• MPLS-VPN
• VPDN– RAS Primer and VPN Dialup Issues
– L2F
– PPTP
– L2TP
Institute of Computer Technology - Vienna University of Technology
L84 - VPN and VPDN in IP
© 2006, D.I. Manfred Lindner
Page 84 - 14
© 2006, D.I. Manfred Lindner VPN Intro + VPDN, v4.3 27
IP Addressing overlapping (1)
• separated IP address spaces– in the core and at the customer sites
• needs either NAT at CE– solutions are the same as with non overlapping addresses
• or different routing domains– dynamic routing protocols in the core are independent
from dynamic routing protocols of the customer networks
• challenge for the provider– to separate routing domains
– several ways to achieve depending on the control of the routers at the customer site
© 2006, D.I. Manfred Lindner VPN Intro + VPDN, v4.3 28
IP Addressing overlapping (2)
Customer A176.16.2.0
Customer B176.16.2.0 Customer A
176.16.3.0Customer B176.16.3.0
Customer A176.16.4.0
Customer B176.16.4.0
Customer A176.16.1.0
Customer B176.16.1.0
CEPE
CE
PEPE
PEPE
CECE
CE
CE
CE CE
Institute of Computer Technology - Vienna University of Technology
L84 - VPN and VPDN in IP
© 2006, D.I. Manfred Lindner
Page 84 - 15
© 2006, D.I. Manfred Lindner VPN Intro + VPDN, v4.3 29
IP Addressing overlapping Scenario 1
Customer A176.16.2.0
Customer B176.16.2.0 Customer A
176.16.3.0Customer B176.16.3.0
Customer A176.16.4.0
Customer B176.16.4.0
Customer A176.16.1.0
Customer B176.16.1.0
Tunnel for Customer A
Tunnel for Customer B
© 2006, D.I. Manfred Lindner VPN Intro + VPDN, v4.3 30
Routers under different control (1)
• CE routers controlled by customer:– routing:
• static routing to the core
or
• dynamic routing to the core
– data packet filtering can be done because of security reasons
• incoming packets concerning source and destination address
– default routing e.g. for Internet connectivity• can be solved in accordance with the provider by a special tunnel
to the Internet exit point
Institute of Computer Technology - Vienna University of Technology
L84 - VPN and VPDN in IP
© 2006, D.I. Manfred Lindner
Page 84 - 16
© 2006, D.I. Manfred Lindner VPN Intro + VPDN, v4.3 31
Routers under different control (2)
• PE routers controlled by provider:– dynamic routing in the core for knowing about tunnel-
endpoints
– ip policy routing• traffic from a given interface can be forwarded only to certain
tunnels
• depending on the destination address a next hop is set– next hop points to a specific tunnel
• for unknown destinations next hop is set to null0 interface– these packets are discarded
• tunneling and ip policy routing– administrative overhead at the provider site
– performance and scalability impacts
© 2006, D.I. Manfred Lindner VPN Intro + VPDN, v4.3 32
IP Addressing overlapping Scenario 2
Customer A176.16.2.0
Customer B176.16.2.0 Customer A
176.16.3.0Customer B176.16.3.0
Customer A176.16.4.0
Customer A176.16.1.0
Customer B176.16.1.0
Customer B176.16.4.0
Tunnel for Customer A
Tunnel for Customer B
Institute of Computer Technology - Vienna University of Technology
L84 - VPN and VPDN in IP
© 2006, D.I. Manfred Lindner
Page 84 - 17
© 2006, D.I. Manfred Lindner VPN Intro + VPDN, v4.3 33
All routers under provider control
• CE routers at the customer site:– routing:
• dynamic routing to the core for knowing about tunnel-endpoints
• static routes to all customer destinations to find the right tunnel
or
• dynamic routing to all customer destinations– second dynamic routing process
– information is not given to the core
• PE routers– dynamic routing in the core
– will not see customer networks
© 2006, D.I. Manfred Lindner VPN Intro + VPDN, v4.3 34
Result: Routing Domain for Customer A
Customer A176.16.2.0
Customer A176.16.3.0
Customer A176.16.1.0
Core RoutingDomain
Customer A176.16.4.0
Customer ARouting Domain
Institute of Computer Technology - Vienna University of Technology
L84 - VPN and VPDN in IP
© 2006, D.I. Manfred Lindner
Page 84 - 18
© 2006, D.I. Manfred Lindner VPN Intro + VPDN, v4.3 35
Result: Routing Domain for Customer B
Customer B176.16.2.0 Customer B
176.16.3.0
Customer B176.16.1.0
Customer B176.16.4.0
Core RoutingDomain
Customer BRouting Domain
© 2006, D.I. Manfred Lindner VPN Intro + VPDN, v4.3 36
Agenda
• VPN– Classical Approach
– Overview IP Based Solutions• IP addresses non overlapping
• IP addresses overlapping
• MPLS-VPN
• VPDN– RAS Primer and VPN Dialup Issues
– L2F
– PPTP
– L2TP
Institute of Computer Technology - Vienna University of Technology
L84 - VPN and VPDN in IP
© 2006, D.I. Manfred Lindner
Page 84 - 19
© 2006, D.I. Manfred Lindner VPN Intro + VPDN, v4.3 37
MPLS-VPN
Customer A176.16.2.0
Customer B176.16.2.0 Customer A
176.16.3.0Customer B176.16.3.0
Customer A176.16.4.0
Customer B176.16.4.0
Customer A176.16.1.0
Customer B176.16.1.0
MPLS-Path (= Tunnel) for Customer A
MPLS-Path (= Tunnel) for Customer B
IP Network withMPLS-Switchingplus MPLS-ApplicationVPN
CEPE
CE
PEPE
PEPE
CECECE
CE
CE CE
© 2006, D.I. Manfred Lindner VPN Intro + VPDN, v4.3 38
MPLS VPN – Best of Both Worlds
• Combines VPN Overlay model with VPN Peer model
• PE routers allow route isolation– By using Virtual Routing and Forwarding Tables (VRF) for
differentiating routes from the customers
– Allows overlapping address spaces
• PE routers participate in P-routing– Hence optimum routing between sites
– Label Switches Paths are used within the core network
– Easy provisioning (sites only)
• Overlapping VPNs possible– By a simple (?) attribute syntax
Institute of Computer Technology - Vienna University of Technology
L84 - VPN and VPDN in IP
© 2006, D.I. Manfred Lindner
Page 84 - 20
© 2006, D.I. Manfred Lindner VPN Intro + VPDN, v4.3 39
What does MPLS VPN mean for the Provider?• Requires MPLS Transport within the core
– Using the label stack feature of MPLS
• Requires MP-BGP among PE routers– Supports IPv4/v6, VPN-IPv4, multicast
– Default behavior: BGP-4
• Requires VPN-IPv4 96 bit addresses– 64 bit Route Distinguisher (RD)
– 32 bit IP address
• Every PE router uses one VRF for each VPN– Virtual Routing and Forwarding Table (VRF)
© 2006, D.I. Manfred Lindner VPN Intro + VPDN, v4.3 40
Agenda
• VPN– Classical Approach
– Overview IP Based Solutions• IP addresses non overlapping
• IP addresses overlapping
• MPLS-VPN
• VPDN– RAS Primer and VPN Dialup Issues
– L2F
– PPTP
– L2TP
Institute of Computer Technology - Vienna University of Technology
L84 - VPN and VPDN in IP
© 2006, D.I. Manfred Lindner
Page 84 - 21
© 2006, D.I. Manfred Lindner VPN Intro + VPDN, v4.3 41
Intranet
• most of today´s company networks are based on– one or more of protocol techniques like
• IP, IPX, NetBios, AppleTalk, etc
– private addresses
– several network access principles• constant connectivity
– router/switches/leased lines
• dial on demand connectivity– access server/security server/ISDN-PSTN
• if network technology and network applicationsof a company network are based on TCP/IP protocol suite– we call such a network INTRANET
© 2006, D.I. Manfred Lindner VPN Intro + VPDN, v4.3 42
Intranet
AccessServer
ISDN/PSTN
WWW E-Mail Name Server
SecurityServer
Institute of Computer Technology - Vienna University of Technology
L84 - VPN and VPDN in IP
© 2006, D.I. Manfred Lindner
Page 84 - 22
© 2006, D.I. Manfred Lindner VPN Intro + VPDN, v4.3 43
RAS techniques for Intranets
• lets talk about remote access techniques first– functionality handled by remote clients, access server
and security server
– PPP protocol (RFC 1661, 1662)
– PPP authentication methods• CHAP (RFC 1994)
• PAP (RFC 1334)
– these basic techniques are used by ISP and Intranets
– encryption methods• end-to-end (IPsec; RFC 1825 - 1829)
• end-to-access server (PPP encryption; draft-ietf-pppext-des-encrypt-v2-00.txt, RFC 1968, 2419, 2420)
• in both cases remote PC must deal with encryption in order to achieve privacy!
© 2006, D.I. Manfred Lindner VPN Intro + VPDN, v4.3 44
RAS Operation 1
• remote PC places ISDN call to access server, ISDN link is established (1)
AccessServer
ISDN
SecurityServer
Intranet Server
1)
Institute of Computer Technology - Vienna University of Technology
L84 - VPN and VPDN in IP
© 2006, D.I. Manfred Lindner
Page 84 - 23
© 2006, D.I. Manfred Lindner VPN Intro + VPDN, v4.3 45
RAS Operation 2
• PPP link (multiprotocol over serial line) is established– LCP (2a)
– authentication• CHAP (2b)
• verification done by central security server (2c)
AccessServer
ISDNISDN
SecurityServer
Intranet Server
2a), 2b)
2c)
© 2006, D.I. Manfred Lindner VPN Intro + VPDN, v4.3 46
RAS Operation 3
• PPP NCP assigns IP address to remote PC
• remote PC appears as device reachable via virtual interface (3)
• optionally– filter could be established
on that virtual interface
• authorization
– accounting can be performed
• actually done by security server (AAA server)
• TACACS, TACACS+
• Radius
AccessServer
ISDN
SecurityServer
Intranet Server
3)
virtual interface
Institute of Computer Technology - Vienna University of Technology
L84 - VPN and VPDN in IP
© 2006, D.I. Manfred Lindner
Page 84 - 24
© 2006, D.I. Manfred Lindner VPN Intro + VPDN, v4.3 47
RAS Operation 4
• privacy on ISDN– PPP encryption between
remote PC and access server (4a)
• privacy end-to-end– IPsec efforts based on
additional encryption header between IP and higher layers (4b)
AccessServer
ISDNISDN
SecurityServer
Intranet Server
4b)
4a)
© 2006, D.I. Manfred Lindner VPN Intro + VPDN, v4.3 48
Internet Access
• access to the Internet:– firewall to secure Intranet against hacker attacks
– firewall to provide necessary connectivity for communication between Intranet hosts and other hosts located in the Internet
– address translation to map certain private addresses to official IP addresses and vice versa
• NAT network address translation gateway
– firewall and NAT could be one box
• but firewalls– do not replace end system security
– can compensate some weaknesses of end systems
Institute of Computer Technology - Vienna University of Technology
L84 - VPN and VPDN in IP
© 2006, D.I. Manfred Lindner
Page 84 - 25
© 2006, D.I. Manfred Lindner VPN Intro + VPDN, v4.3 49
Access to Internet
FirewallAddr. Transl.
ISPIntranet
Internet
© 2006, D.I. Manfred Lindner VPN Intro + VPDN, v4.3 50
A Possible Firewall Architecture
AccessServer
ISDN/PSTN
Intranet Server
WWW SMTP DNS
Bastion Host(Application Level
Firewall)
demilitarized zone
official IP addresses
Intranet
private IP addresses
Packet LevelFirewall
Packet LevelFirewall
INTERNET
Institute of Computer Technology - Vienna University of Technology
L84 - VPN and VPDN in IP
© 2006, D.I. Manfred Lindner
Page 84 - 26
© 2006, D.I. Manfred Lindner VPN Intro + VPDN, v4.3 51
VPN Purpose
Customer connectivity deployed on a shared infrastructure with the same
policies as a private network
SP SharedNetwork
VPNVPN
Internet, IP, FR, ATM
© 2006, D.I. Manfred Lindner VPN Intro + VPDN, v4.3 52
IP VPN Technologies
• Two major IP VPN implementations– Peer to Peer VPN , Service provider takes part in
customer routing e.g. MPLS
– Overlay VPN based on IP infrastructure, uses additional encapsulation technique to simulate virtual point to point connections between customer sites e.g. GRE, IPSEC, L2TP, PPTP, etc
Institute of Computer Technology - Vienna University of Technology
L84 - VPN and VPDN in IP
© 2006, D.I. Manfred Lindner
Page 84 - 27
© 2006, D.I. Manfred Lindner VPN Intro + VPDN, v4.3 53
VPDN Terminology
• VPDN – Virtual Private Dial-up Networks– When L2TP, L2F or PPTP are used to establish a virtual
private connection accross remote access (dial-up) networks
© 2006, D.I. Manfred Lindner VPN Intro + VPDN, v4.3 54
VPDN Overview
ISP Cloud
ISDNPSTN
Home Lan
RemoteUser Remote
User
Home Gateway
Institute of Computer Technology - Vienna University of Technology
L84 - VPN and VPDN in IP
© 2006, D.I. Manfred Lindner
Page 84 - 28
© 2006, D.I. Manfred Lindner VPN Intro + VPDN, v4.3 55
VPN in a Dial-Up Environment
• what is really new with VPN and Internet?– we have to look to the remote access part of a company´s
Intranet• costs of long distance calls
• aspects of administration and security
• user convenience
– remote access is one of the fastest growing areas of information technology
• mobility
• home office
• costs of telephone circuits
• answer: VPN in a dial up scenario -> VPDN
© 2006, D.I. Manfred Lindner VPN Intro + VPDN, v4.3 56
Dial up Scenario Remote
ISDN/PSTN
POP
short distance call official IP address
Internet
FirewallAddr. Transl.
AccessServer
SecurityServer
ISP
ISDN/PSTN
IntranetIntranet Server
long distance call private IP address
AccessServer
Institute of Computer Technology - Vienna University of Technology
L84 - VPN and VPDN in IP
© 2006, D.I. Manfred Lindner
Page 84 - 29
© 2006, D.I. Manfred Lindner VPN Intro + VPDN, v4.3 57
VPDN Challenge User Aspects
ISDN/PSTN
POP
Internet
FirewallAddr. Transl.
AccessServer
SecurityServer
ISP
ISDN/PSTN
IntranetIntranet Server
short distancecall withprivate
IP address
AccessServer
VPDNbetween remote hostand home-gateway
© 2006, D.I. Manfred Lindner VPN Intro + VPDN, v4.3 58
VPDN Challenge Provider Aspects
POP
Internet
FirewallAddr. Transl.
AccessServer
SecurityServer
IntranetIntranetServer
short distancecall to relieveISDN of data
circuits
AccessServer
ISDN/PSTNof
Provider X
circuit switching(synchronous multiplexing)
packet switching(statistical multiplexing)
Institute of Computer Technology - Vienna University of Technology
L84 - VPN and VPDN in IP
© 2006, D.I. Manfred Lindner
Page 84 - 30
© 2006, D.I. Manfred Lindner VPN Intro + VPDN, v4.3 59
VPN and Dial Up
• basic idea of VPN in a dial up environment– extension of local PPP sessions between remote client
and ISP to the native entry point of the Intranet (access server)
– this is done by encapsulation of PPP packets into IP
• several methods developed and deployed– L2F Layer Two Forwarding Protocol (Cisco; RFC 2341)
– PPTP Point-to-Point Tunneling Protocol (Microsoft; RFC 2637)
• finally efforts to combine these proposals lead in– L2TP Layer Two Tunneling Protocol (RFC 2661)
© 2006, D.I. Manfred Lindner VPN Intro + VPDN, v4.3 60
Layer 2 Overlay VPN Technologies
•Used to transport PPP frames across a shared infrastructure, to simulate virtual point to point connections
Layer 2 Tunnel Protocol (L2TP)
IP
PPP
Layer 2 Forwarding Protocol (L2F
Protocol)
Point-to-Point Tunnelling Protocol
(PPTP)
IP
Institute of Computer Technology - Vienna University of Technology
L84 - VPN and VPDN in IP
© 2006, D.I. Manfred Lindner
Page 84 - 31
© 2006, D.I. Manfred Lindner VPN Intro + VPDN, v4.3 61
PPP extension
ISDN/PSTN
POP
shortdistance
call
Internet
FirewallAddr. Transl.
AccessServer
SecurityServer
ISP
ISDN/PSTN
IntranetIntranet Server
AccessServer
PPP sessionbetween remote hostand home-gateway
virtual interface
SecurityServer
© 2006, D.I. Manfred Lindner VPN Intro + VPDN, v4.3 62
Agenda
• VPN– Classical Approach
– Overview IP Based Solutions• IP addresses non overlapping
• IP addresses overlapping
• VPDN– RAS Primer and VPN Dialup Issues
– L2F
– PPTP
– L2TP
Institute of Computer Technology - Vienna University of Technology
L84 - VPN and VPDN in IP
© 2006, D.I. Manfred Lindner
Page 84 - 32
© 2006, D.I. Manfred Lindner VPN Intro + VPDN, v4.3 63
L2F Overview
• Protocol, created by Cisco
• Not a Standard
• Defined in RFC 2341, May 1998
• Tunnelling of the Link Layer over Higher layer Protocols
© 2006, D.I. Manfred Lindner VPN Intro + VPDN, v4.3 64
L2F
ISDN
POP
Internet
AccessServer
SecurityServer
ISP
IntranetIntranet Server
AccessServer
home-gateway
SecurityServer
3)
1), 2)
remote-PC
L2F Tunnel4)
1) short distance ISDN call
2) PPP session setup between remote-PC and access server of ISP
3) username of CHAP used for mapping user to its VPDN (IP address of home-gateway)
4) L2F Tunnel established between ISP access server and home-gateway
FirewallNAT
Institute of Computer Technology - Vienna University of Technology
L84 - VPN and VPDN in IP
© 2006, D.I. Manfred Lindner
Page 84 - 33
© 2006, D.I. Manfred Lindner VPN Intro + VPDN, v4.3 65
L2F
ISDN
POP
Internet
AccessServer
SecurityServer
ISP
IntranetIntranet Server
AccessServer
home-gateway
SecurityServer
5)
remote-PC
L2F Tunnel
5) encapsulation of all traffic from remote-PC into L2F Tunnel an vice versa
6) CHAP (authentication) proceeded between remote-PC and of home-gateway(security server)
7) assignment of IP address out of the pool of private addresses
7)
6)
FirewallNAT
© 2006, D.I. Manfred Lindner VPN Intro + VPDN, v4.3 66
L2F
ISDN
POP
Internet
FirewallNAT
AccessServer
SecurityServer
ISP
IntranetIntranet Server
AccessServer
home-gateway
SecurityServer
3)
8)
remote-PC
8) PPP session end-to-end
9) remote-PC becomes part of private Intranet
authentication CHAP between ISP and home-gateway and vice versa may be usedoptionally during tunnel establishment to handle spoofing attacks
privacy (encryption) not handled by L2F!!!!
9)
Institute of Computer Technology - Vienna University of Technology
L84 - VPN and VPDN in IP
© 2006, D.I. Manfred Lindner
Page 84 - 34
© 2006, D.I. Manfred Lindner VPN Intro + VPDN, v4.3 67
L2F Encapsulation
PPP Header PPP Payload
private IP addr.Intranet Server IP Payloadremaining
IP Headerprivate IP addr.
remote-PC
L2F Header L2F Payload
remainingIP Header
official IP addr.ISP access server
official IP addr.home-gateway UDP Header UDP Payload
remote IP host Intranet Server
remote IP host home-gateway
ISP access server home-gateway
ISP access server NAT-gateway
source address destination address
© 2006, D.I. Manfred Lindner VPN Intro + VPDN, v4.3 68
L2F Facts
• ISP provider must know the home-gateway of a certain user
• ISP provider must establish and maintain L2F tunnel– different remote-clients are distinguished by “Multiplex ID”
• remote PC must know about ISDN number of local ISP POP
• remote PC becomes part of private Intranet
Institute of Computer Technology - Vienna University of Technology
L84 - VPN and VPDN in IP
© 2006, D.I. Manfred Lindner
Page 84 - 35
© 2006, D.I. Manfred Lindner VPN Intro + VPDN, v4.3 69
L2F Facts
• NAT and firewall must allow communication between ISP access server and home-gateway
• L2F supports incoming calls only
• end system transparency– neither the remote end system nor its home-site servers
requires any special software to use this service
© 2006, D.I. Manfred Lindner VPN Intro + VPDN, v4.3 70
Agenda
• VPN– Classical Approach
– Overview IP Based Solutions• IP addresses non overlapping
• IP addresses overlapping
• VPDN– RAS Primer and VPN Dialup Issues
– L2F
– PPTP
– L2TP
Institute of Computer Technology - Vienna University of Technology
L84 - VPN and VPDN in IP
© 2006, D.I. Manfred Lindner
Page 84 - 36
© 2006, D.I. Manfred Lindner VPN Intro + VPDN, v4.3 71
PPTP Overview
• Created by a Vendor Consortium US-Robotics, Microsoft, 3COM, Ascend and ECI Telematics
• Supports multiprotocol VPNs with 40 and 128-bit encryption using Microsoft Point-to-Point Encryption (MPPE)
• Not a Standard• RFC 2637 ,July 1999• Tunnelling of PPP over IP network• A Client-Sever Architecture
© 2006, D.I. Manfred Lindner VPN Intro + VPDN, v4.3 72
PPTP
ISDN
POP
Internet
AccessServer
SecurityServer
ISP
IntranetIntranet Server
AccessServer
home-gateway
SecurityServer
3)
1), 2)
remote-PC
1) short distance ISDN call
2) PPP session setup between remote-PC and access server of ISP
3) username and challenge of CHAP used for user authentication
4) official IP address assigned by ISP for remote-PC
5) PPP session fully established between remote-PC and ISP access server
FirewallNAT
4), 5)
Institute of Computer Technology - Vienna University of Technology
L84 - VPN and VPDN in IP
© 2006, D.I. Manfred Lindner
Page 84 - 37
© 2006, D.I. Manfred Lindner VPN Intro + VPDN, v4.3 73
PPTP
ISDN
POP
Internet
AccessServer
SecurityServer
ISP
IntranetIntranet Server
AccessServer
PPTP networkserver (PNS)
SecurityServer
6)
PPTPaccess
concentrator(PAC)
PPTP Tunnel
6) PPTP Tunnel established between PAC and PNS
7) authentication performed between PAC and PNS (security server)
7)
FirewallNAT
© 2006, D.I. Manfred Lindner VPN Intro + VPDN, v4.3 74
PPTP
ISDN
POP
Internet
AccessServer
SecurityServer
ISP
IntranetIntranet Server
AccessServer
PPTP networkserver (PNS)
SecurityServer
8)
9)
PPTPaccess
concentrator(PAC)
PPTP Tunnel
8) PPTP control messages are carried on top of a TCP session betweenPAC and PNS (responsible for call setup and tear down Call ID)
9) PPTP data messages contains PPP encapsulated in IP & enhanced GRE
10) private address must be assigned additionally by PNSto allow PAC to join the Intranet
FirewallNAT
10)
Institute of Computer Technology - Vienna University of Technology
L84 - VPN and VPDN in IP
© 2006, D.I. Manfred Lindner
Page 84 - 38
© 2006, D.I. Manfred Lindner VPN Intro + VPDN, v4.3 75
PPTP and ISP
ISDN
POP
Internet
AccessServer
SecurityServer
ISP
IntranetIntranet Server
AccessServer
home-gateway
SecurityServer
remote-PC
PPTP Tunnel
FirewallNAT
PPP Link
PPTP access concentrator (PAC)(Microsoft calls this
function FEP)
© 2006, D.I. Manfred Lindner VPN Intro + VPDN, v4.3 76
PPTP Encapsulation Data
PPP Header PPP Payload
private IP addr.Intranet Server IP Payloadremaining
IP Headerprivate IP addr.
PAC
GRE Header GRE Payload
remainingIP Header
official IP addr.PAC
official IP addr.PNS IP Payload
PAC Intranet Server
PAC PNS
PAC PNS
PAC NAT-gateway
source address destination address
contains Call-ID
Institute of Computer Technology - Vienna University of Technology
L84 - VPN and VPDN in IP
© 2006, D.I. Manfred Lindner
Page 84 - 39
© 2006, D.I. Manfred Lindner VPN Intro + VPDN, v4.3 77
PPTP Encapsulation Control
TCP Payload
remainingIP Header
official IP addr.PAC
official IP addr.PNS IP Payload
PAC NAT-gateway
PAC PNS-gateway
TCP Header
PPTP Control Message
© 2006, D.I. Manfred Lindner VPN Intro + VPDN, v4.3 78
PPTP Facts
• remote PC must know about ISDN number of local ISP POP and will be assigned a official IP address– private addresses are used message-internal to reach
Intranet server
• NAT and Firewall must allow communication between any PAC and PNS– that means more overhead than L2F at NAT and Firewall
• PPTP may be used for incoming and outgoing calls
Institute of Computer Technology - Vienna University of Technology
L84 - VPN and VPDN in IP
© 2006, D.I. Manfred Lindner
Page 84 - 40
© 2006, D.I. Manfred Lindner VPN Intro + VPDN, v4.3 79
PPTP Facts
• PPTP can be used for direct LAN-to-LAN connectivity without Dial on Demand– Microsoft VPN
• encryption may be performed on PPTP data tunnel end-to-end (PAC to PNS)
• end system transparency is not given– if remote-PC performs function of a PAC
© 2006, D.I. Manfred Lindner VPN Intro + VPDN, v4.3 80
Agenda
• VPN– Classical Approach
– Overview IP Based Solutions• IP addresses non overlapping
• IP addresses overlapping
• VPDN– RAS Primer and VPN Dialup Issues
– L2F
– PPTP
– L2TP
Institute of Computer Technology - Vienna University of Technology
L84 - VPN and VPDN in IP
© 2006, D.I. Manfred Lindner
Page 84 - 41
© 2006, D.I. Manfred Lindner VPN Intro + VPDN, v4.3 81
L2TP Overview
• Protocol developed by the PPTP forum, Cisco and the IETF
• A Proposed Standard
• Defined in RFC 2661, August 1999
• Transparent Tunnelling of PPP over Intervening Network
• Supports IPSec encryption
© 2006, D.I. Manfred Lindner VPN Intro + VPDN, v4.3 82
L2TP
• follows the basic ideas of L2F– end system transparency
– only private address at remote-PC assigned
• adapts PAC / PNS terminology and concept of Control / Data messages of PPTP– LAC = L2TP Access Concentrator
• ISP access server
– LNS = L2TP Network Server• home-gateway
– call establishment (assignment of CALL-ID), call management and call tear-down procedures
• sounds a little bit like ISDN Signaling Q.931
Institute of Computer Technology - Vienna University of Technology
L84 - VPN and VPDN in IP
© 2006, D.I. Manfred Lindner
Page 84 - 42
© 2006, D.I. Manfred Lindner VPN Intro + VPDN, v4.3 83
L2TP
– control messages and payload messages operates over a given tunnel in parallel
• L2TF will be encapsulated in UDP or mapped to PVC or SVC
– control messages are carried reliable• retransmission based on sequence numbers
– AVP (attribute value pairs) technique is used for control message format
– CALL-ID used for multiplexing• of different calls over the same tunnel
– control messages can be sent in a secure way• using MD5 hash as kind of digital signature
• tunnel peers must be authenticated by additional CHAP procedure between LNS and LAC before
© 2006, D.I. Manfred Lindner VPN Intro + VPDN, v4.3 84
L2TP
• different tunnels may be used between a given LAC / LNS pair– for implementing different QoS for different users
• optionally flow control techniques can be implemented– to perform congestion control over the tunnel
• support of accounting– at LNS and LAC site
• can be used for incoming and outgoing calls
• integrity of payload messages– not covered by L2TP
– still an end-to-end issue
Institute of Computer Technology - Vienna University of Technology
L84 - VPN and VPDN in IP
© 2006, D.I. Manfred Lindner
Page 84 - 43
© 2006, D.I. Manfred Lindner VPN Intro + VPDN, v4.3 85
L2TP
ISDN
POP
Internet
AccessServer
SecurityServer
ISP
IntranetIntranet Server
AccessServer
SecurityServer
5)
remote-PC
L2TP Tunnel
7)
FirewallNAT
L2TP networkserver (LNS)
PPP Traffic(remote-PC becomes part of
private address space of Intranet)
L2TPaccess
concentrator(LAC)
outgoing and incoming calls allowed
(more sophisticated call management)
© 2006, D.I. Manfred Lindner VPN Intro + VPDN, v4.3 86
L2TP Terminology
ISP Cloud
ISDNPSTN
Home LAN
RemoteSystem LAC Client
LNS
LAC NAS
L2TP Tunnel Switch
Institute of Computer Technology - Vienna University of Technology
L84 - VPN and VPDN in IP
© 2006, D.I. Manfred Lindner
Page 84 - 44
© 2006, D.I. Manfred Lindner VPN Intro + VPDN, v4.3 87
L2TP devices
• L2TP Network Server (LNS)– The LNS is the logical termination point of a PPP session that is
tunnelled from a remote system using L2TP encapsulation
• L2TP Access Concentrator (LAC)– Is a L2TP peer to the LNS– A LAC process could be run on a NAS or on a client PC itself
• Network Access Server (NAS)– Provides network access to users across a remote access network
e.g. PSTN
© 2006, D.I. Manfred Lindner VPN Intro + VPDN, v4.3 88
L2TP Overview – Layer2 Multiprotocol Transport
ISP
L2TP tunnel
IP WS IP WS
AppleTalkClient
L2TP Tunnel
POP HomeGateway
IPX Client
Institute of Computer Technology - Vienna University of Technology
L84 - VPN and VPDN in IP
© 2006, D.I. Manfred Lindner
Page 84 - 45
© 2006, D.I. Manfred Lindner VPN Intro + VPDN, v4.3 89
L2TP Tunnel Possibilities 1
ISP Cloud
ISDNPSTN
Home Lan
RemoteUser
L2TP Tunnel
LAC NAS
LNS
LAC Client
© 2006, D.I. Manfred Lindner VPN Intro + VPDN, v4.3 90
L2TP Tunnel Possibilities 2
ISP Cloud
ISDNPSTN
Home Lan
RemoteUser
Account to a public ISP
L2TP TunnelL2TP Tunnel
LAC NAS
LNS
LAC Client
Institute of Computer Technology - Vienna University of Technology
L84 - VPN and VPDN in IP
© 2006, D.I. Manfred Lindner
Page 84 - 46
© 2006, D.I. Manfred Lindner VPN Intro + VPDN, v4.3 91
L2TP Messages Types
• L2TP utilizes two types of messages
• Control Messages– Used for the establishment, maintenance and clearing of L2TP
tunnels
– Are transported across a reliable control channel
• Data Messages – In L2TP encapsulated PPP frames
– Are not retransmitted when a packet loss occurs
© 2006, D.I. Manfred Lindner VPN Intro + VPDN, v4.3 92
L2TP Structure
Packet Transport (UDP, FR, ATM, etc.)
L2TP Data Channel(unreliable)
L2TP Control Channel(reliable)
L2TP Data Messages L2TP Control Messages
PPP Frames
Institute of Computer Technology - Vienna University of Technology
L84 - VPN and VPDN in IP
© 2006, D.I. Manfred Lindner
Page 84 - 47
© 2006, D.I. Manfred Lindner VPN Intro + VPDN, v4.3 93
L2TP Header Format
Offset Size (optional)
Offset padding... (variable, optional)
1 8 16
T L X X S XXXPOX VerX
Length (optional)
Tunnel ID
Session ID
Ns (optional)
Nr (optional)
© 2006, D.I. Manfred Lindner VPN Intro + VPDN, v4.3 94
L2TP Control Bits
• Type (T) bit– Indicates type of message – 0 = data message, 1 = control message
• Length (L) bit – L = 1 means length field present, must be set to 1 in control messages
• X bits– Are reserved for future use
• Sequence (S) bit – S = 1 indicate the presence of the Nr and Ns counters, must be 1 in
control messages
• Offset (O) bit– O = 1 indicate the presence of the offset field, must be 0 in control
messages
• Priority (P) bit– P = 1 indicates preferential treatment, typically used in data messages
Institute of Computer Technology - Vienna University of Technology
L84 - VPN and VPDN in IP
© 2006, D.I. Manfred Lindner
Page 84 - 48
© 2006, D.I. Manfred Lindner VPN Intro + VPDN, v4.3 95
L2TP Header Fields
• Length field– Indicates the total length of the message in bytes
• Tunnel ID– Identifier for Control Connection
– Only Locally Significant
• Session ID– Identifier for Session in the Tunnel
– Only Locally Significant
• Nr Sequence Number– Used to Acknowledge received control messages
• Ns Sequence Number– Send Sequence number of actual control message
• Offset Field– Indicates the start of the payload data
© 2006, D.I. Manfred Lindner VPN Intro + VPDN, v4.3 96
Types of Control Messages
0 Reserved
1
2
3
4
5
SCCRQ
SCCRP
SCCCN
StopCCN
Reserved
Start-Control-Connection-Request
Start-Control-Connection-Reply
Start-Control-Connection-Connected
Stop-Control-Connection-Notification
6 HELLO Hello
Control Connection Management
Institute of Computer Technology - Vienna University of Technology
L84 - VPN and VPDN in IP
© 2006, D.I. Manfred Lindner
Page 84 - 49
© 2006, D.I. Manfred Lindner VPN Intro + VPDN, v4.3 97
Types of Control Messages
7 OCRQ
8
9
10
11
12
OCRP
OCCN
ICRQ
ICRP
ICCN
Outgoing-Call-Request
Outgoing-Call-Reply
Outgoing-Call-Connected
Incoming-Call-Request
Incoming-Call-Reply
Incoming-Call-Connected
13 Reserved
14 CDN Call-Disconnect-Notify
Call Management
15
16
WEN
SLI
WAN-Error-Notify
Set-Link-Info
Error Reporting
PPP Session Control
© 2006, D.I. Manfred Lindner VPN Intro + VPDN, v4.3 98
AVP Control Message extensions
• AVP – Attribute Value Pair– Used to exchange and negotiate more detailed L2TP
session related information e.g. Window size, Host names, call serial number etc.
• Uniform method for encoding message types and payload
• Several „Well Known“ AVPs are defined
Institute of Computer Technology - Vienna University of Technology
L84 - VPN and VPDN in IP
© 2006, D.I. Manfred Lindner
Page 84 - 50
© 2006, D.I. Manfred Lindner VPN Intro + VPDN, v4.3 99
AVP Format
1 8 16
M H Length (10)Reserved (4)
Vendor ID
Attribute Type
Attribute Value... (variable till length is reached)
© 2006, D.I. Manfred Lindner VPN Intro + VPDN, v4.3 100
AVP Bits
• Mandatory (M) bit– Controls the Behaviour for Unrecognized AVPs
• Hidden (H) bit– Responsible for Hiding Data of AVP
• Length field– Defines the Number of Octets in AVP
• Vendor ID – ID = 0 indicates IETF standardized AVP types
Institute of Computer Technology - Vienna University of Technology
L84 - VPN and VPDN in IP
© 2006, D.I. Manfred Lindner
Page 84 - 51
© 2006, D.I. Manfred Lindner VPN Intro + VPDN, v4.3 101
Some of „Well Known“ AVPs
• Message Type• Random Vector• Result Code• Protocol Version• Framing Capabilities• Bearer Capabilities• Bearer Type• Tie Breaker• Firmware Revision• Host Name• Vendor Name
• Assigned Tunnel ID• Receive Window Size• Challenge• Challenge Response• Q.931 Cause Code• Assigned Session ID• Call Serial Number• Min and Max BPS• Framing Type• Caller Number• Calling Number
© 2006, D.I. Manfred Lindner VPN Intro + VPDN, v4.3 102
L2TP Operation
User LAC Home LAN
PSTN or
ISDNISP
IP
L2TP Tunnel
LNS
Control Connection
PPP PPP PPPL2TP SessionCall
Institute of Computer Technology - Vienna University of Technology
L84 - VPN and VPDN in IP
© 2006, D.I. Manfred Lindner
Page 84 - 52
© 2006, D.I. Manfred Lindner VPN Intro + VPDN, v4.3 103
Control Connection Setup
User LACor LNS
Home LAN
PSTN or
ISDNISP LNS
or LAC
SCCRQ
SCCRP
SCCN
ZLB ACK
© 2006, D.I. Manfred Lindner VPN Intro + VPDN, v4.3 104
L2TP Tunnel Authentication
• Similar to CHAP
• Optional
• Using a Challenge AVP
• Included in SCCRQ or SCCRP Messages
• A Single Shared Password
Institute of Computer Technology - Vienna University of Technology
L84 - VPN and VPDN in IP
© 2006, D.I. Manfred Lindner
Page 84 - 53
© 2006, D.I. Manfred Lindner VPN Intro + VPDN, v4.3 105
L2TP Incoming Call
User LAC Home LAN
PSTN or
ISDNISP LNS
User Calls inICRQ
ICCN
ICRP
ZLB ACK
© 2006, D.I. Manfred Lindner VPN Intro + VPDN, v4.3 106
Forwarding of PPP Frames
User LAC Home LAN
PSTN or
ISDNISP
IP
L2TP Tunnel
LNS
Virtualinterface
ppp
Control Connection
PPP PPP PPPL2TP SessionCall
Institute of Computer Technology - Vienna University of Technology
L84 - VPN and VPDN in IP
© 2006, D.I. Manfred Lindner
Page 84 - 54
© 2006, D.I. Manfred Lindner VPN Intro + VPDN, v4.3 107
Disconnecting a Session
User LACor LNS
Home LAN
PSTN or
ISDNISP LNS
or LAC
CDN (Clean up)
ZLB ACK (Clean up)
© 2006, D.I. Manfred Lindner VPN Intro + VPDN, v4.3 108
L2TP over UDP/IP
• Using UDP Port 1701– Might be Changed by LAC or LNS, Could Cause a
Problem for NAT
• IP Fragmentation May be Involved– LCP Could negotiate MRU
• Recommended to Use UDP Checksum
Institute of Computer Technology - Vienna University of Technology
L84 - VPN and VPDN in IP
© 2006, D.I. Manfred Lindner
Page 84 - 55
© 2006, D.I. Manfred Lindner VPN Intro + VPDN, v4.3 109
L2TP Security
• Tunnel Endpoint Security– Optional, Performed by LAC and LNS
• Packet Level Security– the lower layer uses encryption
• End to End Security– Using a Secure Transport
• L2TP and IPsec– IPsec is in charge of packet level security (RFC 3193)