I dont think we need an introduction to the most widely used Remote console utility, PUTTY. Putty support SSH, Telnet, RLogin & RAW connections.

If you telnet or SSH to your Cisco IOS routers or switches or Juniper Firewalls and ofcourse anything that support CLI and SSH or Telnet then one of the things you would prefer to do is to take a backup of the config (Running or Startup) or even capture session text including logs tech information etc. We discussed here about using Hypereterminal to capture text and hence backup and restore config on Cisco IOS Routers and Switches.

Capture Text in Putty

When you have established a remote session with a device like a Cisco Router and you want to capture text from the session as with any other remote consoles like Hyper terminal then

1. Right-click on the menubar and select "change Settings"

2. Click logging under Session.

3. Select "Log all session output"

4. Select the location (default is your desktop) using the browse button and enter the file name (default is putty.log) and click Apply

This should create the file in the location you choose and start loggin everyting from the session.

If you want to make this a default for any saved session in your putty, then choose the session and click load and then follow the above procedure.

Backup config from Cisco IOS Routers & Switches

Now, to backup configuration from a Cisco IOS Based routers and switches, do the following:

ciscorouter# term len 0

ciscorouter# sh running-config

For Startup Configuration

ciscorouter# sh startup-config

The above will show the running config and will in turn be loggedd to the file.

Backup config from Juniper Netscreen Firewalls

In case of Juniper Netscreen based Firewalls,login via SSH or Telnet and run the following command:

admin> get config

As I said earlier, any device that allows you to sh config in the CLI then they all can certainly be backed up this way.

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!!!