cOS Core 10.20 Version: 2013-12-20 - clavister.com · • Internet Protocol Security • PPTP and L2TP • SSL-VPN • VPN Client using Config Mode • Generic Routing Encapsulation

We are Network Security We are Network Security

cOS Core 10.20

Version: 2013-12-20

Clavister VPN

We are Network Security We are Network Security Clavister HQ, Örnsköldsvik, Sweden

We are Network Security We are Network Security Clavister HQ, Örnsköldsvik, Sweden

We are Network Security We are Network Security Agenda

• Repetition

• User Authentication

• Internet Protocol Security

• PPTP and L2TP

• SSL-VPN

• VPN Client using Config Mode

• Generic Routing Encapsulation

• GPRS Tunneling Protocol (GTP)

– Telecom Only

• Troubleshooting

We are Network Security We are Network Security Exercises

• Basic setup of lab environment

• User Authentication using HTTP

• LAN-To-LAN IPsec Tunnel

– PSK

– IKEv2 and PSK

– Self signed certificates

– CA signed certificates

– Ikesnoop verbose

• L2TP over IPsec

• PPTP

• VPN Client using PSK and Config Mode

• GRE tunnel

– GRE inside IPsec

– IPsec inside GRE

We are Network Security We are Network Security Repetition

We are Network Security We are Network Security Repetition & Preparation

Objectives:

Establish a functional lab environment for the rest of the

course

Brush up the basics of what you have learnt during the

Clavister Fundamentals course.

What to do:

Configure cOS Core from scratch.

You should be able to:

Ping www.clavister.com

Browse www.clavister.com

http://www.clavister.com/


We are Network Security We are Network Security Practical details: Breaks

9

• Breaks

– 10:00-10:15

– 14:00-14:15

– Or when it best fits in the training

• Lunch

– 12:00-13:00 CET

Practical Details

Breaks

Lunch

We are Network Security We are Network Security Clavister Product Lineup PolarBear Series (ATCA, Stream)

Wolf Series

Eagle Series Lynx Series Virtual Series

W5 (Core) W3 (Core)

P8 P9 6016 P9 6014 P9 6006

P9 6002

All Series (not V or E7R) are sold with either Standard or Professional license

X8 E7 / E7 Remote V3, V5, V7, V9

We are Network Security We are Network Security Lab Setup via VNC

Student X

*VNC Client on one screen

*PPT slides on one screen/

projector

Internet

VMware

based server

LabNet

Internet

Clavister ISP/DNS

Lab

Environment

LabPC/InControl

Group X

1<=X<=6

We are Network Security We are Network Security Lab Network: Detailed description

Group X

WAN: 172.16.X.1

LAN: 192.168.X.1

LabPC X

192.168.X.2

ISP / DNS

172.16.0.1

Group X LAN

192.168.X.0/24

Server

HTTP, FTP,

SimpServ, …

172.16.0.2

LabNet

172.16.0.0/16


Online course: Skip this chapter,

it was included in the Course Preparation

Document

Link to next chapter

Setting Up VNC

We are Network Security We are Network Security Exercise: Installing VNC

Objectives

Install the VNC Viewer software

Connect to your LabPC

What you will know

Your Lab Group has a number (1 to 6) which

replaces the X in IP numbers etc

How to download and install the VNC Viewer

How to connect to the LabPC and work on it

via VNC

14


VNC is a free product for viewing desktops over TCP/IP

The trainer have the VNC viewer on a USB memory

Optionally: Download the VNC Enterprise Viewer from

http://www.realvnc.com/products/download.html

It supports scaling, which the standard viewer does not support

Install the software

It is actually just an .exe file that you start

Why not RDP?

VNC can have multiple viewers of the same desktop and also support resizing (scaling)

and enabling/disabling of input.

VNC makes the instructor's work much easier than RDP would.

Remember that Clavister AB will monitor and log all activity on those machines, including,

but not limited to, the desktop itself.

Exercise: Installing the VNC client

15

http://www.realvnc.com/products/download.html

We are Network Security We are Network Security Onsite ONLY: Setting up your PC

The PC's IP settings

IP: 10.8.1.10X

X = your group number

Mask: 255.255.255.0

GW: none

DNS: none

Connect the PC to the switch that leads to the

VMware Server

Start the VNC client

.exe file, no installation needed

Connect to: 10.8.1.1X

X = your group number

Password: Intoro123

Same for VNC and for WinXP

This is where you will do all the exercises in

this course

We are Network Security We are Network Security Online ONLY

Use your normal IP settings to reach the

Internet

Make sure your local firewall(s) allow

traffic to TCP/5900 to Clavister

Start the VNC client

Connect to: eduX.demo.clavister.com

X = your group number, see

invitation e-mail

Password: Intoro123

Same for VNC and for WinXP

This is where you will do all the exercises in

this course


Online course: Skip this chapter,

was included in the Course Preparation Document

Link to next chapter

Configure Internet Access

We are Network Security We are Network Security Exercise: Internet Access

Objectives

Configure cOS Core to do NAT of traffic from LAN to WAN.

• Web browsing

• Ping your external interface from the LabPC

Upgrade cOS Core to the latest available version

19


The IP Rule syntax in this course material is as follows:

Name Action Source Int Source Net Dest Int Dest Net Service

NAT_HTTP NAT lan lan_net wan all-nets HTTP

Exercise: IP Rules

20


Open the WebUI on http://192.168.X.1

Add these rules in Rules > IP Rule Sets > main:

DropNetBIOS Drop any all-nets any all-nets smb-all

PingWan Allow lan lannet core wan_ip ping-inbound

Why Core? See next slide!

NAT_All NAT lan lannet wan all-nets All_services

DropAll Drop any all-nets any all-nets All_services

Save and Activate

Test by Browse to www.clavister.com

Ping 172.16.X.1 from your LabPC

Watch the Memlog (Status > Logging).

You should see your traffic.

Exercise: Create IP Rules

21

http://192.168.x.1/


We are Network Security We are Network Security Core owns the interfaces IP addresses

CLI: routes -all

Lists all routes, including core routes

WebUI: Status > Routes, enable "Show all routes"

22

lan_ip=192.168.X.1 wan_ip=172.16.X.1

lan_net=192.168.X.0/24 wan_net=172.16.0.0/16

cOS Core

We are Network Security We are Network Security Exercise: Upgrade Loader & Core

Check that the current version is 10.20 or later

WebUI

Status > Run-time Information

CLI

Device:/> About

If necessary, perform an update:

Status > Maintenance > Upgrade > Firmware

Browse for the .upg file provided by

the trainer

Upgrade


Introduction to Authentication

User Authentication

We are Network Security We are Network Security User Authentication

Objectives

Understand

setting up authentication

pros and cons of local/central authentication

How to set up

local user authentication

Central authentication with Microsoft Active Directory

• LDAP

• RADIUS via IAS

Central Authentication with RADIUS

What to do:

Configure cOS Core for local user authentication using

WebAuth

www.clavister.com


What is Authentication

The process of ”proving that you are who you claim to be”

The foundation of security

Identity must be ensured before any access rules can be applied!

Different ways to authenticate

With something you know

password

With something you have

swipe card

certificate

With something you are

biometrics

Introduction to Authentication


Several methods are sometimes combined

A pass card that requires a password or pin code for use.

This is called two-factor authentication

Password/pin code = Something you know

Pass card = Something you have

Authentication based on several different authentication methods, is generally

referred to as multi-factor authentication.

The three factors described earlier are available (know/have/are)

Supplying a user name ("something the user knows") and a password

("something the user knows") is still considered single factor authentication

Multi-factor Authentication


Strong passwords consists of the following

Minimum 8 (12?) characters. This changes over time!

Mixed UPPERCASE and lowercase letters

Digits and non-alphanumeric characters

Such as high ASCII characters: ±§‗¾÷·²°¶

Alt + ascii code on the keypad

Makes brute-force hacking of the password more complicated

255 possible characters instead of 127

Non-dictionary words

The password must be possible to remember

A post-it on the screen or under the keyboard breaks the strength!

Easily guessed words should not be used

pet name, favourite hockey team, …

Examples of strong passwords

-=0_:)_0=-

kL4vizt3R#

MhaLL%443 (Mary had a Little Lamb plus the port for HTTPS…)

Strong Passwords

We are Network Security We are Network Security Authentication Types

Local Authentication

Users / passwords defined in the

Security Gateway(s)

Pros

+ Quick and easy to implement

+ Inexpensive

+ No extra hardware needed

Cons

- Not suitable for many users

- Lacks advanced features

Central Server Authentication

Users / passwords defined in a central

server

Pros

+ Easy to administer for large

networks

+ Access criteria

time-of-day

Aging account locking (password

not changed in time)

Expiry date

+ Central activity logging possible

+ Proxy to other databases

Cons

- Needs extra hardware and licenses

- Network planning to be changed

- Local fallback authentication

accounts always needed


WLAN with UserAuth and DHCP

User Authentication

We are Network Security We are Network Security User Authentication

cOS Core supports

Local User Database

RADIUS User Database

LDAP User Database

WebAuth can be used for many different

scenarios

Login to get Internet access

Login to get a one-time password sent

to you via SMS from a Clavister SAG

used as a RADIUS server

Two-factor authentification

To access an OWA server

Outlook Web Access

WebAuth can be used as

http

https

Recommended if accessed over a

public network


Check List

Create User Database

Create User Authentication Rule

Create Networks Objects using

groups from the Database.

Create User Authentication

Policy

Create IP Rules

Exercise: WLAN with UserAuth

Objectives:

Setup User Authentication on a DMZ interface, where you connect your WLAN

bridge(s).

VMware: For practical reasons, we replace DMZ with LAN!

User Authentication

Local User Database (or RADIUS or LDAP…)

Internet access for logged in users only


Login to the Security Gateway using HTTP

Only give access rights to logged in users

We are Network Security We are Network Security Exercise: Address Book

Create a Configuration Backup

Status > Maintenance > Backup

Store on the Desktop

Create an IPv4 Address Object, that is a clone

of your Lan_net object

Name: lan_net_auth

Address: 192.168.X.0/24

User Authentication tab

Group: groupX

This must match the group name

of our authenticated users in the

User Database

Add a DHCP lease range

Lan_DHCP:

192.168.X.10-192.168.X.20

Adjust for the number of

concurrent users you support

Make sure you have a DNS object

Dnsserver1_ip 172.16.0.1

We are Network Security We are Network Security Exercise: DHCP Server

Network > Network Services > DHCP Servers

Add a DHCP server on LAN

Name: Lan_DHCP

Interface Filter: Lan

Relay: 0.0.0.0/0

IP Addr. Pool: Lan_DHCP

Netmask: 255.255.255.0

Options

Default GW: Lan_ip

DNS: dnsserver1_ip

We are Network Security We are Network Security Exercise: Local User Database

System > Local User Databases

Create a new Local User Database

Name it UserDB

We are Network Security We are Network Security Exercise: User

In the UserDB, the Users tab:

Add a new User:

Username: userX

Password: clavister

Group: groupX

Must match what we wrote as

Authentication group on the

lan_net_auth object

Remember: X is your group number.

We are Network Security We are Network Security Exercise: Move WebUI to Port 8080

System > Remote Management > Advanced

Settings

Change the WebUI HTTP port to 8080

Or it will collide with the Web Auth

login page

We are Network Security We are Network Security Exercise: User Authentication Rules

Policies > User Authentication >

Authentication Rules

Add a User Authentication Rule

From where users are allowed to

authenticate and towards which user

database

Name: WLAN_Auth

Auth Agent: HTTP

Auth Source: Local

Interface: Lan

Originator IP: Lan_net

Continued on next slide…


Authentication Options tab

Local User DB: UserDB

This is where we can use RADIUS or LDAP

instead


HTTP(s) Agent Options

We use the default values

Login Type: HTML Form

HTTP Banners: Default

You can create your own banner

files, but that is not covered here


Restrictions tab

We use the default values

Idle Timeout: 1800 seconds

Allow one login per username:

Enabled


1 ALLOW lan lannet core lan_ip HTTP

2 NAT lan lan_net_auth wan all-nets All_tcpudpicmp (or dns_http-alg)

3 NAT lan lannet wan all-nets DNS-udp

4 SAT lan lannet wan all-nets HTTP SETDEST AllToOne 127.0.0.1

5 ALLOW lan lannet wan all-nets HTTP

Disable your regular NAT_All rule

Save & Activate

Test the Authentication mechanism

(Set Dynamic IP on the LabPC) Leave out this step to save time.

Login by surfing anywhere and enter credentials on the automatically displayed

authentication page (userX, clavister)

Logout by surfing to http://192.168.X.1 and click on Logout

Or wait 1800 seconds for your session to timeout

Delete or disable the above rules and activate your NAT_All rule

This exercise is finished

Exercise: IP Rules

http://192.168.x.1/


Authentication defined on

Source network

User must be authenticated to get access to the resources

"browse the internet"

Destination network

User must be authenticated in order to run a Server that others can connect to

Very unusual scenario

Authentication on Source or Destination

We are Network Security We are Network Security User Authentication Servers, RADIUS

Add Radius_ip in Address Book

RADIUS Server

Centralized User Management

One-Time Password support with

XAUTH & HTTP/HTTPS

We are Network Security We are Network Security User Authentication Servers, LDAP

Add LDAP_ip in Address Book

LDAP Server

Centralized User Management

One-Time Password support with

XAUTH & HTTP/HTTPS


Using a Windows based authentication server

User Authentication


Microsoft Internet Authentication Service / Active Directory

One of the most common corporate solutions:

Single sign-on regardless of user location

Familiar software – easier to support

No legacy server hardware needed

Supports the standard RADIUS protocol

Authentication using Microsoft IAS / AD

HTTP IPsec + XAuth

IAS

Active Directory

2) Define Clavister as a client to IAS

3) Create Remote Access Policy

4) Set Clavister-Specific attributes

5) Configure Dial-in properties

1) Define Users + group in AD

6) Add Microsoft IAS as

Central User Authentication Server

(need to know IP + shared secret)

7) Add User Authentication rule, Network Objects

and Security Gateway rules as described earlier

We are Network Security We are Network Security IAS: Define Clavister as client

IAS

Add Security Gateway as client

Select RADIUS as protocol

After pressing ”Next” the following are

entered:

Security Gateway IP Address

RADIUS protocol flavour (select Standard)

Shared secret

Note!

De-select the option “Client must always

send signature attribute in the request”

HTTP IPsec + XAuth

IAS

Active Directory





We are Network Security We are Network Security IAS: Remote Access Policy

IAS Remote Access policy is a set of

access rules

Use the ”Add Remote Access Policy”

guide

Selectable Attributes are tied to the

policy

”Windows Groups”

”Day-And-Time restrictions”

HTTP IPsec + XAuth

IAS

Active Directory






HTTP IPsec + XAuth

IAS

Active Directory

Add a RADIUS ”Vendor Specific

Attribute”

IAS will speak Clavister's RADIUS dialect.

IAS: Set Clavister specific attributes

”Vendor Code: 5089”

”1”

”String”

”<group1>,<group2>..”










Authentication protocols PAP or CHAP

define how the handshaking and exchange

of passwords should be done

PAP – Passwords sent in clear text (less

secure), passwords can be stored

in

clear text in AD

CHAP – More secure, password storage

requires some extra work; see IAS

help file ”Authentication methods”

The definitions in the Security Gateway are

performed as described earlier, with the

IAS defined as a RADIUS server.

Don't forget your RADIUS shared secret!

IAS: Dial-in properties

HTTP IPsec + XAuth

IAS

Active Directory


• Now we have seen how to setup the IAS Radius

connection

Microsoft IAS / AD

52 25 November, 2014


Using a Linux/UNIX based authentication server

User Authentication


1) Define Users

2) Define Clavister as client

3) Set Clavister-Specific

attributes

Described earlier:

4) Add XTRadius as

Central User Authentication Server

(need to know IP + shared secret)

5) Add User Authentication rule,

Network Objects and Rules

Corporate solutions gaining in

popularity:

No legacy server hardware needed

Supports the standard RADIUS

protocol

No expensive licensing necessary

Authentication using a Linux/UNIX based authentication server

HTTP IPsec + XAuth

Linux

XTRadius


Users can be set up by using the regular

UNIX passwords from /etc/passwd and NIS.

This is achieved by editing the file

/etc/raddb/users

Define users

HTTP IPsec + XAuth

Linux

XTRadius

1) Define Users



attributes


Edit the file

/etc/raddb/client

Define Clavister as client

HTTP IPsec + XAuth

Linux

XTRadius

1) Define Users



attributes


Create the file

/etc/raddb/dictionary.clavister

Add the line

$INCLUDE dictionary.clavister

to the file /etc/raddb/dictionary

Setting Clavister-specific attributes

HTTP IPsec + XAuth

Linux

XTRadius

1) Define Users



attributes


• Now we have seen how to setup the Radius

connection

Linux based Authentication Server

58 25 November, 2014


Strong Password policy example

http://www.sans.org/resources/policies/Password_Policy.pdf

Creating customized HTML screens

Core Plus Admin Guide, chapter 8.3 "Customizing HTML Pages",

http://www.clavister.com/support/documents.html

Integration of XTradius

https://forums.clavister.com/viewtopic.php?f=17&t=3419

Integration of Microsoft Active Directory



Further Reading

http://www.sans.org/resources/policies/Password_Policy.pdf

http://www.clavister.com/support/documents.html






Introduction

Virtual Private Network


• Objectives

– The following sections introduces the concepts of

• Virtual Private Networks

• Cryptography

• How encryption and authentication are used to construct

VPNs.

Introduction to VPNs


cOS Core supports all the major VPN encryption technologies to suit a wide

range of needs:

Internet Protocol Security

IPsec

Point-to-Point Tunneling Protocol

PPTP

Layer 2 Tunneling Protocol

L2TP

Generic Routing Encapsulation

GRE

Secure Socket Layer – Virtual Private Network

SSL-VPN

Types of VPNs supported by cOS Core


Example of a roaming client connecting to the corporate LAN.

Roaming Client VPN Scenario

HQ

Roaming

user


Example of two corporate LANs connected through VPN.

LAN-To-LAN VPN Scenario

HQ

Branch

Office

We are Network Security We are Network Security LAN-To-LAN & Roaming Clients VPN Scenario

.

HQ

Branch

Office

Roaming

user


Process is repeated for both Security Gateways to

participate in the LAN-to-LAN

Steps Involved, PSK VPN

HQ

Branch

Office

1) Define pre shared key

2) Create IKE / IPsec proposal list

(optional)

3) Define VPN Tunnel

4) Setup routing (automatic in 9.x and

newer)

5) Setting up rules


IPsec

Internet Protocol Security


www.clavister.com

Check List

PSK

Networks

IKE and IPsec proposal

lists

Routing

Rules

Objectives:

• The concept of IKE + IPsec and its usage

• Know how to set up a IPsec Lan-to-Lan tunnel

What to do:

• IPsec Lan-to-Lan tunnel using PSK to your peer group.

• Troubleshoot: "ikesnoop verbose"


• Tailor make proposal lists for IKE and IPsec.

• Browse your peer group's web server (shttpd) via the IPsec tunnel.

• Read and understand the "ikesnoop -on -verbose" output.

IPsec

We are Network Security We are Network Security What is IPsec?

Security protocols defined by IETF

Internet Engineering Task Force

Network Layer additions

Confidentiality

Encryption to prevent snooping

Integrity

Packets not tampered with

Authenticity

Message is from a valid source

Two parts

IKE protocol

IPsec protocol

IKE

IPsec


IKE sets up IPsec's security association (SA) pairs.

IPsec carries the VPN data

IKE Phase 1: - Proposal list is sent to ”B” on how to protect IKE communication (DH key exchange)

- ”A” authenticates ”B” and vice versa using PSK, Certificates or Public Key Encryption

- IKE session management

IKE Phase 2: - Proposal list is sent to ”B” on how to set up IPsec communication (SA pairs)

- Creation of new keying material based on IKE Phase 1 information

- IPsec session management

- Only operates in Quick Mode

IPsec: - Data Transport in the VPN until no data to send or IPsec/IKE session lifetime expiry

Read more: http://en.wikipedia.org/wiki/Internet_Key_Exchange

IKE and the IPsec protocols

IKE

IPsec

http://en.wikipedia.org/wiki/Internet_Key_Exchange


Diffie–Hellman key exchange (D–H)

Cryptographic protocol

Allows two parties that have no prior knowledge of each other to jointly establish a shared

secret key over an insecure communications channel

Without revealing the secret to an evesdropper

initiator secret = (Xb)a mod p = (Xa)b mod p = responder secret

a = Secret for node A, b = Secret for node B

Xa and Xb are public DH values

This key can then be used to encrypt subsequent communications using a symmetric key

cipher.

Symmetric keys can be longer (more secure) and require less CPU resources than

assymetric key encryption (factor 100s-1000s).

This is called Hybrid cryptosystems

asymmetric keys only have to be distributed authentically (know for sure who the

owner is)

symmetric keys need to be distributed in an authentic and confidential manner

Sources:

http://en.wikipedia.org/wiki/Diffie-Hellman_key_exchange

http://en.wikipedia.org/wiki/Symmetric_key

Diffie-Hellman Key Exchange




http://en.wikipedia.org/wiki/Symmetric_key


http://book.soundonair.ru/cisco/ch13lev1sec4.html

The Diffie-Hellman algorithm is used in IKE negotiations to allow the two peers

to agree on a shared secret, to generate keying material for subsequent use,

without knowing any secrets beforehand. Note that although the preshared

secret in this example is already defined on the two peers, the DH secret is used

in conjunction with that preshared secret to authenticate the two peers to each

other.

The DH algorithm relies on the following property:

There exists a DH public value = Xa

such that

Xa = ga mod p

where

g is the generator

p is a large prime number

a is a private secret known only to the initiator

And there exists another DH public value = Xb

such that

Diffie-Hellman Algorithm (Advanced)




Xb = gb mod p

where

g is the generator


b is a private secret known only to the responder

Then the initiator and the responder can generate a shared secret known only to

the two of them by simply exchanging the values Xa and Xb with each other. This

is true because

initiator secret = (Xb)a mod p = (Xa)b mod p = responder secret

This value is the shared secret between the two parties and is also equal to gab.

Coming back to IKE, in order to calculate the DH secret between the two peers,

the two peers calculate the DH public values and send them to each other. In

addition, a value known as a nonce is also generated and exchanged. A nonce is

a very large random number generated using certain mathematical techniques. It

is used in later calculations of the keying material. The following lists describe

the preparation for sending message 3 of the IKE.



First, the two peers independently generate a DH public value:

Generation of the DH public value by the initiator

DH public value = Xa

Xa = ga mod p

where

g is the generator


a is a private secret known only to the initiator

Generation of the DH public value by the responder

DH public value = Xb

Xb = gb mod p

where

g is the generator


b is a private secret known only to the responder

As soon as the DH public values have been calculated, the two peers also

independently calculate the nonces:



Generation of a nonce by the initiator

initiator nonce = Ni

Generation of a nonce by the responder

responder nonce = Nr



Lifetime “X” (seconds or

kB)

Lifetime “Y” (seconds)

IKE and the IPsec re-keying

IKE phase 1

IPsec

IKE phase 2

PFS: No Lifetime "X"

We are Network Security We are Network Security IKE Proposal parameters (1)

IKE

Endpoint identification Pass phrase or hex string identifying VPN Gw

Local and Remote networks/hosts Remote GW = 0.0.0.0/0 for roaming tunnels

Tunnel/transport mode See later slide

Remote gateway Set to “none” for roamers. Not used in transport

mode

Main/aggressive mode IKE negotiation. Aggressive is faster but less safe.

Only Main mode protects the identity of the peers.

IPsec protocol (ESP/AH/both) See later slide

IKE encryption Algorithms, ex: AES, Blowfish, 3DES, (DES)

IKE authentication Algorithms: SHA1, MD5


Strongest parameter combination Diffie-Hellman 5 key exchanges, PFS identities, AES encryption 256 bit key length, SHA1 authentication.

Lifetimes not longer than around 2 GB or 30 minutes.

IKE Proposal parameters (2)

IKE

IKE DH group Group 1: 768-bit, Group 2: 1024-bit, Group 5: 1536-bit

IKE lifetime seconds before session keys changed

PFS on/off/identities When and how IKE session keys are recalculated.

PFS on identities,where the identities are also protected,

by deleting the phase-1 SA every time a phase-2

negotiation has been finished, making sure no more than

one phase-2 negotiation is encrypted using the same

key.

IPsec DH group (if PFS is On) Group 1: 768-bit, Group 2: 1024-bit, Group 5: 1536-bit

IPsec encryption Algorithms, ex: AES, Blowfish, 3DES, (DES)

IPsec authentication Algorithms: SHA1, MD5

IPsec lifetime seconds / kilobytes before session keys changed


AH (Authentication Header) - for tamper proofing a

data stream. The AH header fingerprint detects

changes to the packet.

Transport mode – Original IP Header used for routing

Tunnel mode – Original IP Header is encapsulated, routing done on GW IP address.

AH packets cannot be NATed, as the change of the Outer IP header will break the Authentication

Not supported in CorePlus 8.x or 9.x or in cOS Core 10.x

Authentication Header Protocol


Transport mode – Original IP Header used for routing (in clear text & unprotected)

Tunnel mode – Original IP Header is encapsulated and encrypted, routing done on GW IP

address.

ESP packets can be NATed by applying NAT-T (uses UDP headers and port 4500)

Read more: http://en.wikipedia.org/wiki/IPsec#Encapsulating_Security_Payload

http://en.wikipedia.org/wiki/NAT-T

RFC-3948

Encapsulating Security Payload

Protocol

ESP (Encapsulating Security Payload) - for “tamper proofing”

and/or encrypting of a data stream.

“ESP auth” detects changes to the packet.

http://en.wikipedia.org/wiki/IPsec




We are Network Security We are Network Security IKE(v1) vs IKEv2 (Telecom only in cOS

Core)

Fewer RFCs

One instead of more than three

Improved NAT Traversal

Support for mobile and multihomed users

One four-message initial exchange

mechanism

vs eight different with different

problems in IKEv1

Fewer cryptographic mechanisms

Protects the packets similar to how

ESP protects IPsec packets

Reliability & State management

Sequence numbers &

Acknowledgements

IKEv1 could dead-lock

DoS attack resilience

Not much processing before

determining if the requester actually

exists

For cOS Core

Only IKEv2 can do Virtual Routing

Initiate/terminate tunnels in other

routing tables than Main

Initiate/terminate from

ProxyARPed IPs


0

10

20

30

40

50

60

70

80

90

100

1 2 3 4 5 6 7 8 9 10 11 12

Nodes

VP

N T

un

ne

ls

Pre-Shared Key scaling (Unique Keys!)

Number of VPN Tunnels for full mesh = Number of nodes * (Number of nodes – 1)

PSK Disadvantages:

Does not scale well for bigger networks

if all tunnels need a unique PSK.

If one unit is compromised, all PSKs

must be replaced.

N=n*(n-1)


Central problems for use of public-key cryptography is

Confidence

Proof that a public key is correct

Authenticity

Belongs to the person or entity claimed

Tampering

Not been tampered with or replaced by a malicious third party

Solutions

Public Key Infrastructure

Certificate Authorities certify ownership of key pairs

Web of trust

People sign and vouch each other's key pairs

Establish the authenticity of the binding between a public key and a user.

Certificates

25 November, 2014 83


By using Certificates, we can Revoke the certificate of a compromised machine.

Certificates are verified with the Certificate Authority (CA)

Certificate Revocation List, CRL

will not accept client certificates on that list

Self signed certificates

No CA server is involved

The matching Certificate on the GW can be removed if the machine is compromised

Root Certificate

An unsigned public key certificate or a self-signed certificate that identifies the Root CA

A signature by a root certificate is somewhat analogous to "notarizing" an identity in the

physical world.

All certificates below the root certificate inherit the trustworthiness of the root certificate

Every CA has at least one Root Key or Root Certificate and at least one Intermediate Root

Certificate.

Public Root Certificates distributed to "everyone" (Web browsers etc)

Certificates


ikesnoop -on -verbose example

Click the icon to the right


Changes e.g. to the Ethernet MTU will affect the other values

Updating them too is usually necessary to avoid fragmentation or packets that are not of

full size

VPN MTU and MSS

TCP MSS VPN Max

1392

Global setting

Plain text MTU

1420

IPsec Interface Setting

Ethernet MTU

1500

Ethernet Interface

Setting

TCP and IP

headers ESP or UDP

headers

We are Network Security We are Network Security Quick Lan to Lan Guide

On the following slides we'll demonstrate how to setup a

PSK Lan to Lan tunnel.

We are Network Security We are Network Security LAN-to-LAN PSK

Objects > Key Ring

1) Pre-shared key

2) IKE / IPsec proposal list (optional)

3) IPsec Interface

4) Routing (optional)

5) IP Rules


LAN-to-LAN Algorithms

Objects

IKE Algorithms

IPsec Algorithms

1) Pre-shared key


3) IPsec Interface


5) IP Rules


LAN-to-LAN IPsec Interface

Network > Interfaces > IPsec

1) Pre-shared key


3) IPsec Interface


5) IP Rules

We are Network Security We are Network Security LAN-to-LAN Routing

Network > Routing > Routing Tables > Main

Routes automatically added by default

1) Pre-shared key


3) IPsec Interface


5) IP Rules

We are Network Security We are Network Security LAN-to-LAN IP Rules

Policies > Firewalling > Main IP Rules

1) Pre-shared key


3) IPsec Interface


5) IP Rules


Check List

Pre-Shared Key

Remote Network Object

Remote Gateway Object

Proposal Lists (IKE/IPsec)

IPsec Interface

Routing

IP Rules

Exercise: LAN-To-LAN IPsec Tunnel using PSK

Objectives:

Setup a LAN-To-LAN tunnel between two groups

Allow traffic to go through the tunnel

What to do:

Create a IPsec Tunnel using a Pre-Shared Key.


Browse peer groups' web server on their internal

address (192.168.Y.2) over the IPsec tunnel.

We are Network Security We are Network Security Exercise: Lan to Lan Scenario

192.168.Y.2 Lab PC

192.168.X.2

Labnet

Group X

(You)

Group Y

(Peer group)

Lab Environment

IPsec

Tunnel

We are Network Security We are Network Security Exercise: RAM preservation

We have a very big lab license and only 256

MB of RAM, so we need to modify two settings

to preserve RAM:

System > Adv Settings > State Settings

Disable Dynamic Max

Connections

Max Connections = 8192

Network > Interfaces > IPsec >

Advanced Settings

IPsec Max Tunnels = 10


Information needed to connect to the peer group. If you want more detailed info, look at the following

slides.

PSK

• clavister

Remote network

• 192.168.Y.0/24

Remote gateway

• 172.16.Y.1

IKE proposal list

• AES 256 bit, SHA1, 7800 seconds

IPsec proposal list

• AES 256 bit, SHA1, 1 000 000 kB, 3600 seconds, Tunnel mode

IKE

• Main mode, DH group 2, no PFS, SA Per Net, NAT on if supported and NATed

Exercise: Needed information

We are Network Security We are Network Security Exercise: PSK

Objects > Key Ring

Add Pre-Shared Key

Type: Passphrase

Secret: clavister

We are Network Security We are Network Security Exercise: IKE proposal list

Objects > IKE Algorithms

Create IKE Proposal list

AES 256 bit

SHA1

We are Network Security We are Network Security Exercise: IPsec proposal list

Objects > IPsec Algorithms

Create IPsec proposal list

Use AES 256 bit + SHA1


Objects > Address Book

Add IPv4 Address

GroupY_gw 172.16.Y.1

GroupY_net 192.168.Y.0/24

Y is the peer group’s number.

Exercise: Address Book

We are Network Security We are Network Security Exercise: IPsec tunnel definition

Network > Interfaces > VPN > IPsec

Create a new IPsec tunnel

Name: VPN_GroupY

Local network: lan_net

Remote network: GroupY_net

Remote gateway: GroupY_gw

Encapsulation Mode: Tunnel

Local Endpoint: wan_ip

Source Interface: wan

IKE Algorithms: IKE_AES

IKE Lifetime: 7 800 s

IPsec Algorithms: IPsec_AES

IPsec Lifetime: 3 600 s

1 000 000 kB

Local Endpoint & Source Interface are new in

10.20 and if they are not specified, the IPsec

engine will ”eat” NATed IPsec traffic.

We are Network Security We are Network Security Exercise: IPsec Authentication tab

Authentication tab

Pre-Shared Key: IPsec_PSK

We are Network Security We are Network Security Exercise: IPsec IKE Settings tab

IKE Settings tab

IKE: Main mode, DH group 2

PFS: None

SA: Per Net

NAT Traversal:

On if supported and

NATed

DPD: Use DPD

Keep-alive tab

If one device should be behind NAT or

on a dynamic IP, Keep-alive is

recommended on that unit

Advanced tab

Keep the automatic Route creation

We are Network Security We are Network Security Exercise: Routing

Network > Routing > Main

The route is automatically created

See previous slide

If you instead want to create it manually:

RouteIPv4

Interface = VPN_GrpY

Network = GrpY_Net

Do not enter anything in any of the other

fields, please.


Policies > Firewalling > Main

Allow is state-tracking, so we do not have to have both to get it to work from one side to the

other

To_GroupY Allow lan lan_net VPN_GroupY GroupY_net All_tcpudpicmp (*)

Fr_GroupY Allow VPN_GroupY GroupY_net lan lan_net All_tcpudpicmp (*)

(*) The service you use should be more limited than this in a live scenario!

Exercise: IP Rules

We are Network Security We are Network Security Exercise: Testing the tunnel

Save & Activate

CLI: Activate ike snooping

Ikesnoop -on -verbose

Test the tunnel by pinging the peer group's

LabPC

ping 192.168.Y.2 –v

This should generate a lot of ikesnoop

output and a Ping response.

Test the tunnel by surfing to their web

server’s internal address.

http://192.168.Y.2

Ping simulate incoming traffic:

Ping 192.168.X.2 -srcif=VPN_GrpY

-srcip=192.168.Y.5 -verbose

Verify the tunnel status

Ipsecstat –ike –verbose

”PSK” is listed as auth. method

Ipsecstat

Ipsecstat –usage –verbose

To remove the tunnels

killsa –all

Useful if the tunnels only partially

started (e.g. only phase 1)

We are Network Security We are Network Security Exercise: Create a config backup

Create a config backup

We will use this config in the GRE

chapter

Name it "IPsec_PSK.cfg"


We are Network Security We are Network Security Exercise: Self-Signed Certificates

Objectives:

With this exercise we will setup a LAN-to-LAN tunnel, using

Self-Signed Certificates, between the groups and allow traffic to

go through it.

What to do:

Modify your PSK tunnel to use Self-Signed Certificates.


Browse peer groups web server on their internal address

(192.168.Y.2) over the IPsec tunnel.


Exercise: Lan to Lan Scenario

192.168.Y.2 Lab PC

192.168.X.2

Labnet

Group X

(You) Group Y

(Peer group)

Lab Environment

IPsec Tunnel IPsec Tunnel


Information needed to connect to the peer group

• Certificates

• Self-signed certificates

• Desktop > Resources > Certificates > Self_Signed

If you have completed the Lan to Lan PSK exercise, you already have created these network objects and

proposal lists

Remote network

• 192.168.Y.0/24

Remote gateway

• 172.16.Y.1

IKE proposal list

• AES 256 bit, SHA1, 7800 seconds

IPsec proposal list

• AES 256 bit, SHA1, 1 000 000 kB, 3600 seconds, Tunnel mode

IKE




This is how we created the Self-signed certificates we are using in this exercise

Exercise: Create Self-signed certificates

(X)

Screenshots from Clavister FineTune 8.90


Exercise: Create Self-signed certificates

(Y)


Local Objects > Certificates > Group_X > Export Certificate…

Export both certificates, including the private keys.

Store it on a USB memory stick and exchange self-signed certificates with your peer

group (Group_Y)

Don't give the private key to the peer!

Exercise: Export Self-Signed Certificate

We are Network Security We are Network Security Exercise: Upload your certificate

Objects > Key Ring

Name: Group_X

Disable CRLs

Upload X.509 Certificate

Browse to

Desktop > Resources > Certificates >

Self-Signed

Pick the .cer file matching your group

number

Pick the .key file matching your group

number

We are Network Security We are Network Security Exercise: Upload Neighbour’s Certificate

Objects > Key Ring

Name: Group_Y

Disable CRLs

Upload a remote certificate

Browse to


Self-Signed

Pick the .cer file for group Y

Ok

Now you should have one Local cert and one

Remote cert

We are Network Security We are Network Security Exercise: Modify the IPsec Interface


Open the IPsec Interface > Authentication tab

Select X.509 Certificate

Root Certificate: Group_Y

Gateway Certificate: Group_X

Identification List: None

Local ID Type: IP

Local ID Value 172.16.X.1

This value is also entered into your

certificate


Save and Activate on both units.

Reboot might be needed if you get “There are errors…”

Synchronize the groups and kill all tunnels from the previous exercise

killsa -all

On the receiving end, activate ike snooping:

Ikesnoop -on -verbose

Test the tunnel by pinging the peer group's internal IP

ping 192.168.X.2 –v

This should generate a lot of ikesnoop output at the peer end.

Test by surfing to their web server (http://192.168.Y.2)


Ping 192.168.X.2 -srcif=VPN_GrpY -srcip=192.168.Y.5 -verbose

Verify the tunnel status, including “RSA Signatures” as auth method:

Ipsecstat –ike -verbose

Ipsecstat

Ipsecstat –usage –verbose

Exercise: Testing the tunnel


Device:/> ipsecstat -ike group1_vpn -verbose

--- Active IKE SAs:

1

Initiator SPI : 0xf8ac9c32ac784cda

Responder SPI : 0x5585267d95bfb4ff

Remote peer : wan:172.16.1.1:500

Local IP : 172.16.2.1:500

Local identity : 172.16.2.1

Remote identity : 172.16.1.1

Created : 2013-09-11 10:34:03

Expires : 2013-09-11 12:44:03

Diffie-Hellman group : 2

Encryption alg : aes256-cbc

MAC alg : hmac-sha1-96

PRF alg : hmac-sha1

Local auth method : RSA signatures

Remote auth method : RSA signatures

Exercise: Authentication Method

We are Network Security We are Network Security Exercise: CA Signed Certificates

Objectives:

In this exercise we will setup a LAN-To-LAN tunnel, using CA

signed Certificates

What to do:

Modify your IPsec tunnel to use CA signed Certificates.


Browse peer groups web server on their internal address

(192.168.Y.2) over the IPsec tunnel.



Certificate Request -> Signed Certificate

• Signed using Windows 2008 Server CA services

• Modified according to the Clavister Admin Guide

If you have completed the Lan to Lan PSK exercise, you already have created these network objects and

proposal lists

Remote network

• 192.168.Y.0/24

Remote gateway

• 172.16.Y.1

IKE proposal list

• AES 256 bit, MD5, 50 000 kB, 3600 seconds

IPsec proposal list

• AES 256 bit, MD5-96, 1 000 000 kB, 3600 seconds, Tunnel mode

IKE




There are many applications that can create certificates and certificate requests.

We were using Clavister InControl

The trainer will have them pre-made for you

Desktop > Resources > Certificates > CA_Signed

Exercise: Creating a CA Signed

Certificate


To request certificates from a CA server or CA company

Send a CA Certificate Request for a certificate in a well known, predefined format.

It is possible to manually create the required files for a Windows CA server using the

following stages.

Create a gateway certificate on the Windows CA server (example below from

2003 server)

Open IE > http://localhost/certsrv

Request a certificate

Submit an advanced certificate request

Submit a certificate request…

Copy the contents of the .req file and paste into the box.

Template: Web server

Download certificate (DER encoded)

Give it a name that matches the .key file you have

Download the CA Server's certificate

Home

Download a CA certificate, …

DER encoded, Download CA certificate

Save it under a suitable name, such as CA_Root.cer

Exercise: Windows CA Server Request

http://localhost/certsrv


If you use another CA which can only generate .pfx format

A single .pfx file contains

CA root certificate

Personal certificate

Private key certificate.

Convert the .pfx file to the .pem format with openssl

openssl pkcs12 -in gateway.pfx -out gateway.pem -nodes

OpenSSL exists for several platforms including Windows.

Take out the relevant parts of the .pem file to form the required .cer and .key

files.

Copy the RSA Private Key into a GrpX.key file

Copy the Certificate into a GrpX.cer file

Exercise: Convert .pfx files

We are Network Security We are Network Security Exercise: Import CA Signed Cert

Objects > Key Ring

Add Certificate

Name: CA_GroupX

Disable CRLs

“Upload X.509 Certificate”


CA_Signed

Will ask for .cer and .key files

Select those matching your group

number

We are Network Security We are Network Security Exercise: Import Root CA

Objects > Key Ring

Add Certificate

Name: CA_Root

Disable CRLs

Upload a Remote certificate

Select the CA root certificate

Desktop > Resources > Certificates

> CA-Signed > CA_Root.cer

We are Network Security We are Network Security Exercise: IPsec Tunnel Authentication

Network > Interfaces > IPsec > VPN_GrpY

Root Certificate: CA_Root

The CA's root certificate, so we trust

all certificates signed by this CA

Gateway Certificate: CA_GroupX

Your own certificate

Identification List: None

Local ID Type: IP

Local ID Value: 172.16.X.1


Make sure the date and time are correctly set.

Save and Activate on both units

Restart the devices completely

Status > Maintenance > Reset > Reboot

The Certificate cache will otherwise still use the self-signed certificate and the tunnel won’t

form properly.

The Admin Guide: “Restart cOS Core if any certificates are added, modified or deleted.”

On the receiving end, activate ike snooping:

Ikesnoop -on –verbose

Test the tunnel by pinging the peer group's internal IP

ping 192.168.X.2 –v

Test by surfing to their web server.


ping 192.168.X.2 -srcif=VPN_GroupY -srcip=192.168.Y.5 -verbose

Verify the tunnel status and that it uses RSA and not PSK:

ipsecstat –ike -verbose

ipsecstat –usage –verbose

Exercise: Testing the tunnel


Point-to-Point Tunneling Protocol (PPTP)

Layer 2 Tunneling Protocol (L2TP)

PPTP and L2TP


PPTP, Point-to-Point Tunneling Protocol

Provide IP security at the network layer.

A PPTP based VPN, such as the one in Clavister Security Gateway, is made by these parts:

Point-to-Point Protocol (PPP)

Authentication Protocols (PAP, CHAP, MS-CHAP v1, MS-CHAP v2)

Microsoft Point-To-Point Encryption (MPPE)

Generic Routing Encapsulation (GRE)

PPTP uses TCP port 1723 for it's control connection and GRE (IP protocol 47) for the PPP data.

PPTP supports data encryption by using MPPE.

Introduction to PPTP


L2TP, Layer 2 Tunneling Protocol

Provide IP security at the network layer.

A L2TP based VPN, such as the one in Clavister Security Gateway, is made up by

these parts:

Point-to-Point Protocol

PPP over UDP

Authentication Protocols

PAP

CHAP

MS-CHAP v1

MS-CHAP v2

Encryption

Microsoft Point-To-Point Encryption, MPPE

IPsec, since UDP carries the PPP data

Introduction to L2TP


PPP (Point-to-Point Protocol)

Transports datagrams over point-to-point links.

Encapsulates IP packets for transport between two peers

PPP consists of these three components:

Link Control Protocols (LCP)

Negotiate parameters

Test and establish the link

Network Control Protocol (NCP)

Establish and negotiate different network layer protocols

cOS Core supports IP

Data encapsulation

Encapsulate datagrams over the link

Point-to-Point Protocol


PPP supports different authentication protocols

Which authentication protocol to use is determined during LCP negotiation.

PAP - Password Authentication Protocol

Simple, plaintext authentication

PAP is not a secure authentication protocol

CHAP - Challenge Handshake Authentication Protocol

Uses a MD5 one-way encryption scheme to hash the response to a challenge issued by

the server.

MS-CHAP v1 - Microsoft Challenge Handshake Authentication Protocol version 1

Similar to CHAP, the main difference is that with MS-CHAP v1 the password only needs

to be stored as a MD4 hash.

MS-CHAP v2 - Microsoft Challenge Handshake Authentication Protocol version 2

Is similar to MS-CHAP v1

The server also authenticates itself with the client

Authentication Protocols

We are Network Security We are Network Security Microsoft Point-To-Point Encryption

MPPE

Encrypt Point to Point Protocol (PPP)

packets.

MPEE has the following attributes:

RSA RC4 provides data confidentiality

40-bit, 56-bit and 128-bit RC4 session

keys

Not hardware accelerated in cOS Core!

We are Network Security We are Network Security PPTP/L2TP Server

Network > Interfaces > PPTP/L2TP Servers

General Parameters

Name

IP Address

Tunnel protocol, L2TP or PPTP

Outer Interface Filter: server listens on

Ethernet or IPsec tunnel

Server IP

IP Address the PPTP/L2TP Server

listens for connections on

PPTP mostly used for old legacy operating

systems (and to Windows Servers…)

L2TP preferred choice for Windows XP, 7, 8,

…

We are Network Security We are Network Security PPTP/L2TP Server > PPP Parameters

User Authentication Rules

MPPE Parameters

Key lengths you accept

Recommendations

Use 128 bit for PPTP

Use None for L2TP/IPsec

IP Pool

IP addresses and DNS/WINS servers to

hand out to clients

We are Network Security We are Network Security PPTP/L2TP Client

Used to connect to some ISPs

Connect to a PPTP/L2TP server on another

cOS Core device (Lan to Lan)

Network > Interfaces > PPTP/L2TP Clients

General Parameters

Name

Tunnel protocol, L2TP or PPTP

Remote Endpoint

Remote Network

User name

Password

We are Network Security We are Network Security PPTP/L2TP Client > Security

Settings for negotiation with the server

Authentication Parameters

The type of authentication and

encryption accepted

MPPE Parameters

Key lengths accepted

Recommendations

Use 128 bit for PPTP

Use None for L2TP/IPsec


Check List

Pre-Shared Key

Proposal Lists/Pre-defined

Interfaces

User Authentication Rules

IP Rules

Exercise: L2TP over IPsec

Objectives:

L2TP/IPsec server

What to do:

Create an IPsec tunnel interface that use a Pre-

Shared Key and connect it to a L2TP interface.

User Authentication Rules.


Browse the peer groups web server over the IPsec

tunnel.


L2TP_net

• 192.168.9X.0/24

L2TP_Pool

• 192.168.9X.2 - 192.168.9X.253

L2TP_ip

• 192.168.9X.1

L2TP_PSK

• clavister

IKE Main mode, DH group 2, no PFS, SA per net, NAT-T On if supported. Transport mode.

High/Medium proposal list

• Or manually: DES, 3DES, AES 128-256, SHA1, MD5, 28800 s

High/Medium proposal list

• Or manually: Transport, DES, 3DES, AES 128-256, SHA1-96, MD5-96, 250 000 kB, 3600 s




Create these IPv4 Address objects

L2TP_net

192.168.9X.0/24

L2TP_Pool

192.168.9X.2 - 192.168.9X.253

L2TP_ip

192.168.9X.1


We are Network Security We are Network Security Exercise: L2TP_PSK

Objects > Key Ring

Add Pre-Shared Key

Type: Passphrase

Secret: clavister

We are Network Security We are Network Security Exercise: Local user database


Create a database

UserDB

Add a user

userX

clavister

groupX

Groups could later be used in the IP Rules to

setup different policies based on group

membership

We are Network Security We are Network Security Exercise: Manual IKE proposal list (Optional)

Optional!


Name: IKE_L2TP

DES

3DES

AES 128, 128, 256

MD5 & SHA1

We are Network Security We are Network Security Exercise: Manual IPsec proposal list (Optional)

Optional!


Name: IPsec_L2TP

DES

3DES

AES 128, 128, 256

MD5 & SHA1

We are Network Security We are Network Security Exercise: IPsec Tunnel

Network > IPsec

Local Network: wan_ip

Same IP the L2TP tunnel will

connect to!

When behind NAT, set to all-nets

because of the incorrect local ID

that will be sent.

Remote Network: all-nets

Remote Gateway: <none>

Encapsulation: Transport

Local endpoint: wan_ip

Source interface: wan

IKE: High/Medium/IKE_L2TP

28800 sec

IPsec: High/Medium/IPsec_L2TP

3600 sec

1 000 000 kB (or 250 000 kB)

We are Network Security We are Network Security Exercise: Authentication tab

Authentication tab

Select Pre-Shared Key

Pre-shared Key: L2TP_PSK

The value is “clavister”

We are Network Security We are Network Security Exercise: IKE Settings tab

IKE Settings tab

Use the default settings, as displayed

to the right.

We are Network Security We are Network Security Exercise: Advanced tab

Advanced tab

Add route dynamically: Disabled

Add route statically: Disabled

Click OK

Make sure this tunnel is last in your list of

IPsec interfaces

It triggers on all incoming tunnels

We are Network Security We are Network Security Exercise: L2TP server

Network > PPTP/L2TP Servers

Name: L2TP_Server

Inner IP Address: L2TP_ip

From the network which the clients are

assigned IP addresses from

Tunnel Protocol: L2TP

Outer Interface Filter: L2TP_IPsec

Connects L2TP to Ipsec

Server IP: wan_ip

This is the IP that the L2TP server is

listening on

We are Network Security We are Network Security Exercise: PPP Parameters tab

PPP Parameters tab

Disable MPPE

You use IPsec for encryption

MPPE is not hardware accelerated

IP Pool: L2TP_Pool

Addresses to assign to clients

DNS dnsserver1_ip

We are Network Security We are Network Security Exercise: Add Route tab

Add Route tab

Only needed if a local network is

used as L2TP_pool

We use a separate network

Click OK

We are Network Security We are Network Security Exercise: Authentication Rules

Policies > User Authentication >

Authentication Rules


Name: L2TP_Auth

Agent L2TP/PPTP/SSLVPN

PPP

Authentication Source: Local

Interface: L2TP_Server

Originator IP all-nets

Clients are roaming

Terminator IP wan_ip

Outer Server IP for the L2TP_Server

We are Network Security We are Network Security Exercise: Authentication Options tab


Select the UserDB

We are Network Security We are Network Security Exercise: Agent Options tab

Agent Options tab

Select allowed PPP protocols

PAP = plaintext, so it is not secure

at all

We are Network Security We are Network Security Exercise: Restrictions tab

Restrictions tab

Allow one login per username

Idle timeout

Session timeout

Specify desired values



An Allow rule for the traffic to the internal LAN (or DMZ or wherever you want it to

go).

If they also should be able to access the Internet via the L2TP/IPsec tunnel, a NAT

rule is also required

This requires enabling the client setting: "Use default gateway on remote

network"

Exercise: IP Rules


Network & Sharing Center

Set up a new connection or network

Connect to a workplace

No, create a new connection

Use my Internet connection

Internet address: 172.16.Y.1

Destination Name: L2TP to Group Y

Don't connect now; just set it up so I can connect later

User name: userY

Password: clavister

Remember this password

Create, Close

Change Adapter Settings

Right click on "L2TP to Group Y", select Properties

Security > Type of VPN, set to L2TP/IPsec

Security > Advanced settings, select "Use Pre-shared key" and enter "clavister"

You are done

Exercise: Windows 7 L2TP client

We are Network Security We are Network Security Exercise: Verifying

Open the L2TP tunnel

If needed

User: userY

Password: clavister

You should be able to connect and surf their

web server

http://192.168.Y.2

The inbound connection can be verified in the

CLI:

userauth –list

ipsecstat –u –v

L2TP: Both can be connected at the same

time, BUT the web server will be inaccessible.

The response traffic will take the wrong path

back to you...

PPTP: You must disconnect when the peer

group connects to you or the GRE tunnels will

collide, as they are not using GRE Session

Keys

We are Network Security We are Network Security Exercise: Managing L2TP Users

In Windows Server 2003 and 2008

You can create an executable file with

all settings related to L2TP

Run the file on the clients



Client based SSL-VPN

SSL-VPN


SSL-VPN is another alternative for creating a secure tunnel

Uses Secure Sockets Layer (SSL)

Clavister’s SSL-VPN Client software is installed on the client computer

The SSL-VPN server is cOS Core

The clients can now access the protected resources via the SSL-VPN tunnel

Advantages

Secure communication from locations where IPsec etc is not allowed

SSL-VPN Tunnel


Disadvantages

The tunnel is encapsulated in TCP and inside the tunnel, TCP flows.

Delays due to exponential increase of segment timeouts

The timeouts inside the tunnel might be shorter than the timeouts in the outer

layer

Retransmissions inside the tunnel might queue up quicker than they are handled

Connection problems / no traffic gets through

No hardware acceleration

IPsec usually enjoy this

Only MS Windows is supported

Client software

SSL-VPN Tunnel


Use the default SSL port: 443

If you have HTTPS management (WebUI) on the same port

Members of the Administrator or Auditor groups get WebUI access

Source IP must be included in the Remote Management rule

Others reach the SSL VPN User Portal:

SSL-VPN Login


Download and install the client

Download the configuration file

Contains a certificate fingerprint to avoid man-in-the-middle attacks

Connect using the configuration file

Access the protected resources...

The SSL-VPN Client

We are Network Security We are Network Security Exercise: Setup SSL-VPN

Objectives

Setup the SSL-VPN server

Connect the client to the server

• Download and install the SSL-VPN Client

• Establish the connection

We are Network Security We are Network Security Exercise: SSL-VPN Scenario

192.168.Y.2 Lab PC

192.168.X.2

Labnet

Group X

(You) Group Y

(Peer group)

Lab Environment

SSL-VPN

Server

SSL-VPN

Tunnel

SSL-VPN

Client


Make a configuration backup


SSLVPN_ip 192.168.99.1

SSLVPN_net 192.168.99.0/24

SSLVPN_pool 192.168.99.11-

192.168.99.20

We are Network Security We are Network Security Exercise: User Database


Make sure you have a Local User Database

with a user

UserDB

Username: userX

Password: clavister

Group: groupX

We are Network Security We are Network Security Exercise: SSL-VPN Interface

Network > Interfaces > SSL

Add an SSL-VPN Interface

Name SSLVPN

Inner IP SSLVPN_ip

Outer If wan

Server IP wan_ip

Server Port 443

IP Adr Pool SSLVPN_pool

DNS: 172.16.0.1

Route All Traffic... Enabled

Click OK

We are Network Security We are Network Security Exercise: User Authentication Rule

Policies > User Authentication > ...


Name SSLVPN_Auth

Auth Agent ../SSL VPN

Auth Src Local

Interface SSLVPN

Orig. IP all-nets

Term. IP wan_ip


Local User DB > UserDB



Reach the internal web server

SSLVPN_to_WebServer Allow SSLVPN SSLVPN_pool lan Server_ip HTTP

NAT to the Internet

SSLVPN_NAT NAT SSLVPN SSLVPN_pool wan all-nets all_tcpudpicmp

Exercise: IP Rules


Now, Save & Activate

Wait for your peer groups to be finished

Surf to their SSL-VPN portal

Make sure you NAT out TCP/443!

https://172.16.Y.1

userY / clavister

Install the client software

Download the Client Configuration File

Connect

Verify that you can surf through the tunnel

To the Internet

To the peer group's web server

Disconnect

Restore the configuration backup


Exercise: Save & Activate

https://172.16.x.1/

We are Network Security We are Network Security Exercise: VPN Client using PSK

Objectives

Install and configure a VPN Client using PSK and Config Mode

What to do:

Configure cOS Core for connections from the VPN Client

• Access to the local network(s)


Browse your neighbour’s web server on 192.168.Y.2

199


Information needed to connect to the peer group. If you want more detailed info, look at the following

slides.

• Address book objects

• DHCP_Pool: 192.168.99.100-192.168.99.200

• PSK

• clavister

• Remote Network

• All-nets

• Remote Endpoint

• All-nets

• IKE Config Mode pool

• Setup a DHCP server, fetch IPs to an IP Pool object, assign IPs via the tunnel

• IKE proposal list

• AES 256 bit, SHA-1, 7800 seconds

• IPsec proposal list

• AES 256 bit, SHA-1, 1 000 000 kB, 3600 seconds, Tunnel mode, No PFS

• IKE

• Main mode, DH group 2, no PFS, SA Per Host, NAT on if supported and NATed



Add the following object in the Address Book

Config_Mode_Pool: 192.168.99.100-192.168.99.200

Config_Mode_ip: 192.168.99.1


We are Network Security We are Network Security Exercise: PSK

Objects > Key Ring

Add Pre-Shared Key

Type: Passphrase

Secret: clavister

We are Network Security We are Network Security Exercise: IKE proposal list


Create IKE Proposal list

AES 256 bit

SHA1

We are Network Security We are Network Security Exercise: IPsec proposal list


Create IPsec proposal list

Use AES 256 bit + SHA1


Exercise: DHCP server

Network > Network Services > DHCP Servers

General tab

Name Config_Mode_DHCP

Interface Filter core

IP Addr Pool Config_Mode_Pool

Netmask 255.255.255.0

Options tab

Default GW Config_Mode_ip

DNS dnsserver1_ip


Exercise: IP Pool

Objects > IP Pools

An IP Pool that fetches IPs from a DHCP

server, in this case the one on Localhost

Name IPPool

DHCP Server Addr. Localhost

Advanced tab

Keep the default values


Exercise: IKE Config Mode Pool

Objects > IKE Config Mode Pool

Add an IKE Config Mode Pool

Use a pre-defined IP Pool Object

IP Pool IPPool

Click OK

A simpler alternative would be to use a Static

IP Pool, but the current example can easily be

modified to use an external DHCP server,

which is common in live environments

Change the IP Pool on the previous

slide to point to the external DHCP

server...

We are Network Security We are Network Security Exercise: IPsec Roaming Tunnel


Add IPsec Tunnel

General tab

Name Roaming_VPN

Local network all-nets

Remote Network all-nets

Remote Endpoint (None)

Encapsulation Mode Tunnel

Local Endpoint wan_ip

Source Interface wan

IKE Config Mode P. PreDefined

IKE Algorithms IKE_AES

IKE Lifetime 7800

IPsec Algorithms IPsec_AES

IPsec Lifetime 3600 / 1 000 000

Continued…


Authentication tab

Pre-shared Key VPN_PSK

Exercise: Authentication tab

We are Network Security We are Network Security Exercise: IKE Settings tab

IKE Settings tab

IKE Main mode, DH group 2

No PFS (+ Groups 01, 02 and 05)

Security Association per Host

NAT-T On if supported and NATed

Use DPD

We are Network Security We are Network Security Exercise: Advanced tab

Advanced tab

Add Route dynamically Enable

Add Route Statically Disable

Otherwise All-nets will be routed through the

tunnel, but actually only a warning will appear

every time you Save and Activate…

X


Exercise: Tunnel Order

Click OK

Note! Place it last, but it cannot be

combined with the PSK tunnel for L2TP, so it

must either be placed above that tunnel, or

disable/delete the L2TP tunnel and all objects

depending on it.

To combine these two tunnels, one or both

must use Certificates. Only one roaming PSK

tunnel can exist (per interface, now that we

have IPsec VR)



Roaming_To_Lan

For traffic going to Lan.

Drop NetBIOS must be under Roaming_To_Lan if they should access LAN with

Windows file share traffic

Roaming_To_Internet

NAT roaming users to the Internet

Exercise: IP Rules

We are Network Security We are Network Security Exercise: Install the VPN Client

Install the 30 Day Free Evaluation version of

The Green Bow

http://www.thegreenbow.com/

Resources > Tools&Software

Install the software and its drivers

Restart your LabPC (if necessary)

Click on Evaluate

Start the VPN Client software

214

We are Network Security We are Network Security Exercise: Setup a Tunnel to Group Y

Open the Configuration Panel

Right click on the root node ”VPN

Configuration”

Select New Phase 1

Now a new node appears, named Gateway

Select it and fill in these values

Interface 192.168.X.2

Remote GW 172.16.Y.1

Pre-shared key clavister

Encryption AES 256

Authentication SHA-1

Key Group DH2 (1024)

Advanced tab

Mode Config Enabled

Click on Save

Continued...

215

We are Network Security We are Network Security Exercise: Setup VPN Tunnel

Right click again on the Gateway object

Now a sub node named Tunnel appears.

Select it.

Fill in these values

VPN Client addr: <grayed out>

Due to Config Mode

Address type: Single address

Remote host addr: 192.168.Y.2

Subnet Mask: <grayed out>

Encryption AES 256

Authentication SHA-1

Mode Tunnel

PFS Disable

Save

Rename the ”Gateway” to ”Group_Y”

216

5


Connect with SSH to the receiving Security Gateway

ikesnoop -on -verbose

GreenBow

Open the tunnel

Right click on ”Tunnel” and select ”Open Tunnel” or right click on the blue icon near

the clock and select ”Open Group_Y Tunnel”

Make sure the tunnel gets established

ipsecstat

ipsecstat -ike

ping 192.168.Y.2 –v

Depending on how the incoming IP Rules are defined…

http://192.168.Y.2

You should reach the webserver of group Y, via the tunnel

Disconnect and let the other group verify towards you

Exercise: Test the tunnel

217

http://192.168.y.2/


GRE

Generic Routing Encapsulation


• Generic Router Encapsulation (GRE) tunnels is a

method of connecting two networks together

across another network, like the internet.

• GRE tunnels does not use any kind of encryption

for the communication.

• IP protocol number 47 is used

• Used for instance to send traffic from IPv4-only

capable devices over IPv6 and in certain legacy

or telecom applications.

Introduction to GRE

We are Network Security We are Network Security GRE Tunnel

Interface Settings

The Name and IP Address of the GRE Tunnel

interface.

Encapsulations Settings

The Source IP of the GRE tunnel and the

Remote Gateway of the GRE tunnel.

The routing table and the rules decides what

will get through the GRE tunnel.

If Additional Encapsulation Checksum is

enabled, GRE will add an extra level of

checksums above the one provided by the

IPv4 layer.

Useful for tunnels over private networks

Does not slow down traffic due to encryption

We are Network Security We are Network Security Exercise: GRE Tunnel

Objectives:

With this exercise we will setup a GRE tunnel between

two groups and allow traffic to go through it.

What to do:

Create a GRE Tunnel interface that connects to your

peer group.


Ping the peer group's LabPC and browse their

webserver over the GRE tunnel.


Exercise: GRE Scenario

192.168.Y.2 Lab PC

192.168.X.2

Labnet

Group X

(You) Group Y

Lab Environment

GRE Tunnel GRE Tunnel


Start by restoring the IPsec PSK config

In the exercise after this one, we will combine GRE and IPsec, so load the IPsec config you

stored earlier.

Disable the IPsec tunnel and the IP Rules that are depending on it for now.

Exercise: Restore the IPsec PSK config



• IP address

• 192.168.X.1 (= Lan_ip)

• Remote Network (for the routing)

• 192.168.Y.0/24

• Remote Endpoint

• 172.16.Y.1

• Session key

• The lowest of the two group numbers

• Additional Encapsulation Checksum Enabled

• IP address to ping/surf to

• 192.168.Y.2




Add the following IPv4 Address Objects

GroupY_net 192.168.Y.0/24

GroupY_gw 172.16.Y.1

Y is your peer group’s number

We are Network Security We are Network Security Exercise: Setting up GRE

Network > Interfaces > GRE

Add a GRE Tunnel Interface

Name GRE_GroupY

IP Address lan_ip

Remote Network GroupY_net

Remote Gateway GroupY_gw

Use Session Keys Enable

Session Key Lowest of X and Y

Additional Encap-

sulation Checksum Enable



Add one IP Rule in each direction

Use a Service Group to limit what is permitted via the tunnel

Create it in the Service Drop-down menu if you do not have a suitable group already!

To_GroupY Allow lan lan_net GRE_GroupYGroupY_net http_ping

From_GroupY Allow GRE_GroupY GroupY_net lan lan_net http_ping

Exercise: Setting up IP Rules


Ping 192.168.Y.2 -verbose

Verify that the traffic isn't going through an IPsec tunnel or similar

Check the GRE interface statistics. The counters should increase.

Ifstat GRE_GroupY

Device:/> ifstat GRE_Group2

Iface GRE_Group2

GRE tunnel to 172.16.2.1 from 172.16.1.1 (session key 1)

Receive Mode : Normal

MTU : 1472

IP Address : 192.168.1.1

Software Statistics:

Soft received : 2 Soft sent : 2 Send failures : 0

Dropped : 0 IP Input Errs : 0

Driver information / hardware statistics:

None.


Exercise: Testing the GRE tunnel

We are Network Security We are Network Security Troubleshooting


Incorrect Pre-shared Key

Roaming VPN-tunnel with “all-nets” GW placed before the new, failing tunnel can

cause the new tunnel not to trigger and exit with this fault code.

Move the new tunnel before the “all-nets tunnel”.

For more information see: http://www.clavister.com/support/kb/10087/

No matching IKE proposals

During IKE Phase 1 parameters like lifetimes, IKE authentication, encryption etc

are negotiated in the form of proposals. These must exactly match between

endpoint A and B, or a tunnel will never form.

Tunnel order

Routes are the only entity that is not susceptible to changes in order.

Generally for VPN troubleshooting routes and rules can often be ignored.

Common VPN mistakes


Record IKE and IPsec proposal sequence

cmd> ikesnoop -verbose [remote_gw_ip]

This is preferably done on the Security Gateway on “receiving end”,

capture the text using your favourite terminal program

See a nice overview of tunnels & rough proposals

cmd> ipsectunnels [tunnelname]

See bytes and package statistics

cmd> ipsecstat –u –v [remote_gw_ip]

Useful console commands

We are Network Security We are Network Security Certification Test


• The End

Thank you for attending this Clavister Fundamentals

course!

We hope that you will also attend our other courses,

such as:

Clavister IPv6

Clavister Building Corporate Networks

Clavister VPN

Clavister Advanced Routing

Clavister InControl

Clavister Next Generation Firewalling

The End

Documents

cOS Core 10.20 Version: 2013-12-20 - clavister.com · • Internet Protocol Security • PPTP and L2TP • SSL-VPN • VPN Client using Config Mode • Generic Routing Encapsulation