Virtual Private Network (VPN) is a network which uses a shared network infrastructure (Internet) which allows a secure access between two networks or securely connects a remote user to his corporate network.

Let's check out here how to configure a Site to Site VPN using a Pre-shared Key in Cisco Routers running Cisco IOS

Let's use a HQ-Branch office network setup with the following:

Authentication Method: Pre-Shared Key

Encryption Algorithm: 3DES

Hash Algorithm: SHA

HQ Router External IP : 172.10.10.100

(Peer IP for Branch Network)

HQ Internal Network: 172.11.1.0/24

Branch Router External IP : 10.1.1.100

(Peer IP for HQ Network)

Branch Internal Network: 10.11.2.0/24

Configuring IKE Policies

Create an IKE Policy

From the global configuration mode, create a new IKE Policy.

VPN-HQ(config)# crypto isakmp policy 1

Set the Keep-Alive & Retry intervals

The default Keep-Alive time os 10 seconds and retry when the keep-alive fails is 2 seconds. If you prefer changing this value then do the following else can be ignored

VPN-HQ(config-isakmp)# crypto isakmp keepalive 15 retry 3

Specify the Encryption Algorithm

I'm using 3DES encryption method here

VPN-HQ(config-isakmp)# encryption 3des

Specify the HASH Algorithm

I'm using sha hashing algorithm here

VPN-HQ(config-isakmp)# hash sha

Set the Authentication Method

We are using Pre-shared key here for Authentication

VPN-HQ(config-isakmp)# authentication pre-share

Set the Diffe-Hellman Group Identifier

We are using DH Group-2 (1024)

VPN-HQ(config-isakmp)# group 2

Specify SA's lifetime (seconds)

Set the lifetime of the Security Associations in seconds. I'll set it for 24hrs (86400 seconds) here

VPN-HQ(config-isakmp)# lifetime 86400

Set Pre-shared Key

The Authentication method we use here is the Pre-Shared key. We should now set this previously agreed shared key (don't exchange on emails. Use your phone,letters or faxes) from the global configuration mode.I'll use a simple pre-shared key "0urVpN" but use more complex key when configuring a production system.

VPN-HQ(config)# crypto isakmp key 0urVpN address 10.1.1.100

where 10.1.1.100 is the Peer routers IP Address and "0urVpN" is the pre-shared key.

Define Transformation Set

We set the transformation of ESP-3DES transform and ESP-SHA-HMAC transform to Transformation set 3DES-SHA-HMAC

VPN-HQ(config)# crypto ipsec transform-set 3DES-SHA-HMAC esp-3des esp-sha-hmac

VPN-HQ(cfg-crypto-trans)# exit

Setup a Crypto ACL

This ACL defines the protected traffic that passes through the VPN tunnel. Customize the ACL as per your organisation needs.

VPN-HQ(config)# ip access-list 101 permit ip 172.11.1.0 0.0.0.0 10.11.2.0 0.0.0.0

Create an IPSec Map

Create an IPSec Crypto Map and assign it a Sequence number

VPN-HQ(config)# crypto map HQ-BR1-MAP 2 ipsec-isakmp

where 2 is the sequence number and HQ-BR1-MAP is the nameof the map.

Set the Network traffic to be protected

Here use the extended ACl created earlier to define the traffic that is protected and passed through the tunnel.

VPN-HQ(config-crypto-map)# match address 101

where 101 is the Extended ACL

Set the Peer Address

VPN-HQ(config-crypto-map)# set peer 10.1.1.100

Set Transform Set

VPN-HQ(config-crypto-map)# set 3DES-SHA-HMAC

Set Perfect Forwarding Secret

VPN-HQ(config-crypto-map)# set pfs group 2

Apply Crypto Map to the external Interface

VPN-HQ(config)# int fa0/0

VPN-HQ(config-if)# crypto map HQ-BR1-MAP

Allow inbound IPSec traffic from the Peer on the external interface

VPN-HQ(config)# ip access-list 102 permit udp host 10.1.1.100 any eq isakmp

VPN-HQ(config)# ip access-list 102 permit esp host 10.1.1.100 any

That completes the configuration on the Cisco Router at the HQ. Repeat the procedure with only changing

1. The Peer IP in the steps for setting the Pre-shared Key & setting Peer.

2. Modify the ACLs for the protected networks

3. Inbound ACL to allow incoming traffic from peer

To verify the configs, use the following show commands:

Display Crypto IKE Policy

VPN-HQ# show crypto isakmp policy

Display Crypto Transform Set

VPN-HQ# show crypto ipsec transform-set

Display Crypto Map entries

VPN-HQ# show crypto map

Recently we had this problem with this problem with an Exchange 2003 server in the HQ and Outlook Clients in a particular branch office. The Branch office connects into the HQ through a site to site IPSec VPN using Juniper Netscreen SSG20 firewalls on either end of tunnels.

The Problem
The Outlook clients would connect OK but suddenly loose connection to the Exchange server and never connect back. The Outlook Client status will say "Disconnected". The client PCs will however be able to ping the server and network connections look OK. This happened in random times and sometimes when sending large emails.

Investigation

A deeper investigation revealed that every time the client(s) failed to make a connection there is an error event on the Exchange server with the error "MaxObjExceeded". This started pointing us in the right direction. Yes, a google did show a lot similar issues all pointing to connections over VPN.

Cause

The exchange server sends large packets with the DF bit set (Don't Fragment). This when added with the IPSec headers goes beyond the MTU of the Firewalls. The Juniper firewalls by default ignore the DF bits and fragments the packets and forwards it onto the VPN tunnel. Although, these are re-assembled at the client side, this caused problems with the Outlook Clients and they keep re-initiating connections until they run out of connection objects on the Exchange server. That's when they can no longer connect to the Exchange server and the server reports Error events with "MaxObjExceeded" message. Also, from Junipers Knowledge Base, most of the Microsoft applications which heavily rely on "NetBIOS over TCP/IP" are bound to have this problem as these send large packets with DF bit set.

Resolution

So where do we go from here?? Yes, the only possible resolution was to tune and tweak the Maximum Segment Size (MSS) of all the packets that traverses through the VPN Tunnel. We were to set the MSS on all the TCP packets to 1350. This is sufficiently low enough (as well good enough not to degrade too much of performance) to ensure that the packets never exceeds the MTU of the firewall which is 1500 bytes even after the Encryption overheads.

NOTE: All the following changes should be done on VPN firewalls on both ends

To do this on Juniper Firewalls

vpn-firewall> set flow tcp-mss 1350

This simply replaces the MSS value on all TCP packets for the VPN with the value 1350

To set for all TCP packets

vpn-firewall> set flow all-tcp-mss 1350

However, the previous command for VPN overrides this (for TCP packets destined to the VPN).

Also, added the Path MTU Discovery support on the Juniper Firewalls. This when set makes the firewall to drop any packet set which is more than its MTU (1500 bytes) with DF bit and send an ICMP error messages "Destination not recheable. Packet too big" (ICMP Type3 Code 4) message back to the source along with its MTU value. The source then adjusts its assumed Path MTU so the packet size is less than the MTU and hence there is no fragmentation necessary.

To do this on a Juniper

vpn-firewall> set flow path-mtu

Another option setting that you can try would be to set the Maximum Fragment Size on the firewalls for the generated Fragment size if it is more than the MTU.

To do this on a Juniper

Screen OS 5.4

vpn-firewall> set flow max-frag-pkt-size

Previous versions of Screen OS

vpn-firewall> set flow max

Also, you can disable the TCP SYN check before the session is created for the tunneled packets.

To do this on a Juniper

vpn-firewall> unset flow tcp-syn-check-in-tunnel

To check TCP syn before creating any TCP session

vpn-firewall> unset flow tcp-syn-check

Save the configuration

vpn-firewall> save

This resolved the problem for us and should resolve the Outlook & Exchange connectivity issues over VPN even if it is a different VPN device like Cisco ASAs but ofcourse use appropriate commands for those device.

If you have any more thoughts on this or any comments and more pointers, please take a moment to add a comment so should help other users who face similar issue.

If you have site to site IPSec VPNs configured between two network with your Juniper Netscreen or SSG firewalls and clients from one network access servers or services from the other network then it is advisable to enable Path MTU Discovery support on the Juniper firewalls.

Juniper Netscreen or SSG firewalls running Screen OS by default disable the Path MTU Discovery support. This means, when an IP Packet with DF bit set ("1") in the ip Header and its size after IPSec Encapsulation is more the MTU of the Juniper VPN Firewall arrives at the VPN Firewall, the firewall will ignore the "DF" bit and simply fragments the packets and forwards it to the appropriate tunnel interface. This can cause serious problems with some applications. A classic example is the Microsoft Applications that rely on NetBIOS over TCP/IP which wouldn't prefer the packets being fragmented (and hence DF set).

It is advisable that the Path MTU Discovery support is enabled on the Juniper VPN Firewalls. When enabled in the above scenario, the Firewall will drop the packet instead and send an "ICMP Destination Unreachable (Datagram Too Big)" message (ICMP Type 3 Code 4 message) back to the host with its MTU value. The source host then adjusts its assumed Path MTU value appropriately and sends the packet accordingly so the packet size is well within the MTU of the firewall and hence the packet is not fragmented and is forwarded as such.

To enable Path MTU Discovery in Juniper firewalls running Screen OS logon as an admin user and run the following commands:

Set Path MTU

SSG20> set flow path-mtu

SSG20> save

To verify the change

SSG20> get config | incl path

Remember, this needs to be enabled on the other VPN Peer as well.

This change should make users on either side a happy bunny!!!