Site-to-Site VPNs - Part 1: The Basics

I've been getting a lot of questions lately about VPNs (virtual private networks); how they work, what are they, how to configure them. To most CCNA graduates it can be a bit confusing. Seeing as more than half the work in our NOC consists of VPN-related issues I thought it'd be good to get everything out in the open for those who aren't sure about them.

There are a couple different types of VPN connections (L2L, RAS, SSL, etc), however we're going to just with the basics and cover a site-to-site connection.

If you have your CCNA, you should be familiar with the concept of Frame-Relay. It allows two private networks to connect to one another as if there was nothing but a router in between. Nowadays we generally use MPLS or VPNs in place of a Frame-Relay PVC. What this allows you to do is more easily and dynamically connect multiple subnetworks together for very cheap (and in VPN cases, basically free - provided you have the equipment).

Speaking of equipment, we'll be covering three in these posts: a Cisco IOS-based router, a Cisco ASA, and a Juniper SSG - they all employ the same technology.

Core

Before we can configure our tunnels, we need to know how they operate. You'll hear terms like phases, SAs, "interesting traffic", route based vs policy based, encryption, and a million other terms thrown around by NOC-monkies; this is where we'll explain everything you need to know to keep up in the conversation and impress your friends.

Let's begin by breaking down the order of operations for establishing an IPSec VPN.

First we'll need some traffic that wants to connect to a remote host. This is called "interesting traffic"; it's interesting because it triggers an ACL (or policy). This ACL/policy is being monitored by the VPN on your firewall. ACL is hit, traffic is tunneled - simple. This is a policy based VPN. The alternative would be a route based VPN; I find these very popular on ScreenOS. They require you to create a virtual tunnel interface to route traffic towards as you would any other interface.

Your VPN can be configured in one of two modes, Aggressive or Main. Aggressive is used when your remote LAN is using a dynamic IP address or behind NAT; this will cause the tunnel peer or hub (where your VPNs terminate) to consider VPN requests from any peer IP address. However, all interesting traffic will have to be initiated from the remote firewall; the head doesn't know the IP of its peer until the tunnel is established.

Once your remote firewall has interesting traffic that needs to be tunneled, it reaches out to its peer's IP and initiates what's referred to as "Phase One negotiations".  In Phase One, the two peers negotiate an authentication method, encryption algorithm, hash algorithm, and Diffie Hellman group as well as a timeout - this is known as the proposal in Junipers and a Transform Set in Cisco-world. After both sides are in an agreement an IKE SA is created and a secure connection has been created between them so they can safety start with Phase Two. If a single setting in the Phase One proposal is mismatched between peers, the IKE SA will fail to be established.

In Phase Two, the keying material is generated, and the two peers agree upon the policy that will be used (known as a proxy ID in Juniper-land when using a route based tunnel). This mode, which is called quick mode, differs from Phase One in that it can't occur until after Phase One is successful and all of the Phase Two packets are encrypted. This makes troubleshooting a little more difficult as it is possible for Phase One to be successful but Phase Two to fail. If Phase Two is successful, it will result in a Phase 2 SA, also called an IPSec SA, and the tunnel will be fully established.

I'll be going into more detail about everything mentioned above in Part 2, when we go through deploying both route based and policy based IPSec VPNs on a Juniper SSG Firewall from start to finish.

Enabling PPTP passthrough on ScreenOS

Enable vip multi-port command; this allows a VIP service to listen to multiple ports simultaneously
After entering set vip multi-port you'll be promptd with a warning that you must reboot.

set vip multi-port
save

reset

Define the service as usual

set service CustomPPTP group "other" 47 src 2048-2048 dst 2048-2048      

Append the TCP source ports to the service we just defined

set service CustomPPTP + tcp src 0-65535 dst 1723-1723

The source port for TCP 1723 must be 0-65535 to allow for any source port

Set up your VIP   

set int eth0/0 vip interface-ip 2048 CustomPPTP 192.168.1.2

And define your policy

set policy from untrust to trust any vip(ethernet0/0) CustomPPTP permit log

Blocking Skype on ScreenOS

Unfortunately, ScreenOS doesn't have the same deep packet inspection and application control that Fortinet or even Cisco has. Skype is built around P2P networking and uses dynamic incoming ports and can even fall back on to 80/443 for it's communication. It's design this way for ease-of-use, so that a layer 3 firewall will never stand in the way from you having free VoIP phone calls. However, this can cause some frustration when trying traditionally block it on a firewall using a port-range.

On a Cisco you can utilize NBAR because they've implemented a Skype application classification, and with Fortinet you can use their application control function. But on an old fashioned ScreenOS-based Juniper, you're shit-out-of-luck. There is however a very McGuyver-way to do it.

When a Skype client is connected it must authenticate the username and password with the Skype login server. There are many different Skype login servers using different ports. An obfuscated list of servers is hardcoded in the Skype executable. With this list we can deny outbound traffic.

Can't login, can't use Skype. Simple.

Now there is a list of servers published on Wikipedia, however after some research this appears to be an outdated and pre-Microsoft server list. This is a tested and working list of authentication servers:

64.4.23.0/24
65.55.223.0/24
111.221.74.0/24
111.221.77.0/24
157.55.56.0/24
157.55.130.0/24
157.55.235.0/24
157.56.52.0/24
213.199.179.0/24

Defining your remotes

set address "Untrust" "Skype_64.4.23.0/24" 64.4.23.0 255.255.255.0
set address "Untrust" "Skype_65.55.223.0/24" 65.55.223.0 255.255.255.0
set address "Untrust" "Skype_111.221.74.0/24" 111.221.74.0 255.255.255.0
set address "Untrust" "Skype_111.221.77.0/24" 111.221.77.0 255.255.255.0
set address "Untrust" "Skype_157.55.56.0/24" 157.55.56.0 255.255.255.0
set address "Untrust" "Skype_157.55.130.0/24" 157.55.130.0 255.255.255.0
set address "Untrust" "Skype_157.55.235.0/24" 157.55.235.0 255.255.255.0
set address "Untrust" "Skype_157.56.52.0/24" 157.56.52.0 255.255.255.0
set address "Untrust" "Skype_213.199.179.0/24" 213.199.179.0 255.255.255.0

Blocking your hosts

 The following ACL will deny all hosts in the Trust zone from accessing the Skype servers. If you want to block specific hosts then change/add the source addresses/zones in the policy. For multiple specific hosts you will need to add a line similar to set src-address "192.168.1.1/32".

set policy top from "Trust" to "Untrust" "Any" "Skype_64.4.23.0/24" "ANY" deny log
set dst-address "Skype_65.55.223.0/24"
set dst-address "Skype_111.221.74.0/24"
set dst-address "Skype_111.221.77.0/24"
set dst-address "Skype_157.55.56.0/24"
set dst-address "Skype_157.55.130.0/24"
set dst-address "Skype_157.55.235.0/24"
set dst-address "Skype_157.56.52.0/24"
set dst-address "Skype_213.199.179.0/24"

Packet Profiling on ScreenOS

Occasionally I've had clients report high latency or slowness. I've gone over bandwidth reports and can see long peaks of high usage and their pings come back well over 200ms. Now on a Cisco device you can turn on NetFlow and see who the top talkers are. Unfortunately a lot of people don't know how to do this on a Juniper (ScreenOS).

Recon

The first thing you'll want to do is log into the device, if there is a lot of traffic response times in the terminal may be slow so bare with it. You'll need to enable packet profile then start it up. If packet profiling has been run on the device before it'd be a good idea to clear the existing information as well.

set fprofile packet enable
clear fprofile
set fprofile packet start

By defualt, the profiling buffer is set to nowrap so that the packet profiling will automatically halt when the buffer is full. If you wish to disable this use the command set fprofile packet wrap; this will cause the profiling to continually run until it's manually stopped. Be advised that it will overriding the existing buffer with new information (I believe NetFlow on Cisco operates in a similar fashion)

Now that you have it running, give it some time to gather traffic information.

Analysis

If you decided to turn on wrapping, issue the command set fprofile packet stop. Otherwise you should be good to go. To display the gathered information issue the command get fprofile packet. This will give you the default output, as seen below.

ssg5-> get fprofile packet
packet buffer size(in kilo-packets): 4
total ip packet: 4090
total ip packet time(us): 349668
total none-ip packet: 6
total none-ip packet time(us): 206
    Id  Type    Protocol    Source                Destination        Sport    Dport    Time    Percentage
    1  ip        0x06        192.168.0.1            192.168.1.254    80        2917    71099    20.32%
    2  ip        0x06        4.2.2.2                192.168.1.254    80        2237    52399    14.97%  
    3  ip        0x06        192.168.1.2            192.168.1.254    80        2800    51627    14.75%  
    4  ip        0x06        192.168.1.1            192.168.0.1        49966    80        42703    12.20%  
    5  ip        0x06        4.2.2.1                192.168.1.254    80        1224    34008    9.72%  
    6  ip        0x06        192.168.1.1            4.2.2.2            49949    80        26675    7.62%  
    7  ip        0x06        192.168.1.1            4.2.2.2            49900    80        26235    7.49%  
    8  ip        0x06        192.168.1.1            4.2.2.1            49935    80        17235    4.92%  
    9  ip        0x01        192.168.1.2            192.168.1.254    8        0        3467    0.00%  
    10 ip        0x32        192.168.1.2            192.168.1.254    44562    48388    2527    0.00%  

Blogger isn`t wide enough to display this properly. I should find a new theme...I`ve also changed the IPs to meaningless one for the sake of this post. Don`t want anyone`s networks getting ID`d ;)

So take a look at the top users and see if you can see any patterns, in the example below we can see that 192.168.1.1 has a session open to 192.168.0.1. At the same time there is a session open from 192.168.0.1 to 192.168.1.254(which happens to be our modem).

Now we'll want to look at the ARP for our suspected culprit ( 192.168.1.1) and do a look up on both the MAC and the remote IP (192.168.0.1). I use Wireshark`s OUI Lookup Tool.

From here we can trace the MAC and IP through the our MAC and ARP tables to find which switch (or AP, usually) it`s hanging off of.

Once stopped the packet profiling settings will still be in the configuration (much like NetFlow), however if you wish to remove it completely use the unset fprofile packet enable command.

Reference

clear fprofile

get fprofile packet ip proto top <NUMBER>
get fprofile packet ip proto all
get fprofile packet ip proto
get fprofile packet ip src-ip top <NUMBER>
get fprofile packet ip src-ip all
get fprofile packet ip src-ip
get fprofile packet ip dst-ip top <NUMBER>
get fprofile packet ip dst-ip all
get fprofile packet ip dst-ip
get fprofile packet ip sport top <NUMBER>
get fprofile packet ip sport all
get fprofile packet ip sport
get fprofile packet ip dport top <NUMBER>
get fprofile packet ip dport all
get fprofile packet ip dport
get fprofile packet ip top <NUMBER>
get fprofile packet ip all
get fprofile packet ip
get fprofile packet none-ip proto top <NUMBER>
get fprofile packet none-ip proto all
get fprofile packet none-ip proto
get fprofile packet none-ip src-mac top <NUMBER>
get fprofile packet none-ip src-mac all
get fprofile packet none-ip src-mac
get fprofile packet none-ip dst-mac top <NUMBER>
get fprofile packet none-ip dst-mac all
get fprofile packet none-ip dst-mac
get fprofile packet none-ip top <NUMBER>
get fprofile packet none-ip all
get fprofile packet none-ip
get fprofile packet top <NUMBER>
get fprofile packet all
get fprofile packet
get fprofile

set fprofile packet enable

Implementing NSRP

NetScreen Redundancy Protocol (NSRP) is a proprietary protocol that provides configuration, run time object (RTO) redundancy, and device failover for NetScreen devices in a high availability (HA) cluster.

Connection

Juniper has pre-configured their more powerful devices with an HA zone. This zone allows the devices in the cluster to transfer and receive NSRP data and information from one another.

The SSG140 and above have this zone pre-installed. For devices that do not natively support it, a license from Juniper and manual configuration is required.

On some NetScreen devices, there are multiple dedicated (physical) HA interfaces. Each interface handles different kinds of HA communication as well as act as a back-up interface should one fail. By default, HA1 handles control messages and H2 handles data messages.

On NetScreen devices that do not have dedicated HA interfaces, you must bind one or two physical ethernet interfaces to the HA zone. For this demonstration we'll be using ethernet1/4.

set int eth1/4 zone "HA"

The devices will now know which interface to listen for NSRP messages. Input the NSRP commands to set up the cluster; the cluster ID must be identical on both devices. An NSRP cluster acts similar to a cluster in any other technology; it simply groups devices together.

set nsrp cluster id <#>
set nsrp cluster name <name>

Priority

A VSD group is a set of physical devices that make up a single virtual security device (VSD). One physical device acts as the primary of the VSD group. The virtual security interface (VSI) of the VSD is bound to the physical interface of the primary device. The other physical device acts as the backup. A VSD acts similar to a RAID array; a single virtual device made up of a cluster of physical devices.

We need to tell the firewalls which one is the master, and which one is the backup. The priority of the preferred backup should be a higher value, as the lower priority takes precedence. We want the device we're configuring to be the master but because we don't want it to take over until we're ready, we'll go ahead and set the priority to 200.

set nsrp vsd-group id 0 priority 200

Ctrl-S

At this point we'll want to save the configurations we've made so they don't conflict when loading the mirror configuration over.

save

Ctrl-C

Because we're configuring a brand new ISG, no extensive config exists. But we've set up NSRP already, and our backup has a configuration, so lets just copy that over.

exec nsrp sync global-config save

NOTE: Because this is an exec command, it has to be issued via a console connection

After this command is input, the device needs to be reset by simply issuing the reset command. Upon reboot, we should go through the configuration to make sure everything is correct. After POST it will tell you which commands (if any) failed, but it never hurts to be thorough.

Sync

Defining a NetScreen device as a member of a cluster and specifying RTO synchronization automatically enables the local device to send and receive RTOs. By default, NSRP cluster members do not synchronize RTOs. Before enabling RTO synchronization, you must first synchronize the configurations between the cluster members. Unless the configurations on both members in the cluster are identical, RTO synchronization might fail.

set nsrp rto-mirror sync

Run-time objects (RTOs) are code objects created dynamically in memory during normal operation. Some examples of RTOs are session table entries, ARP cache entries, DHCP leases, and IPSec security associations (SAs). In the event of a failover, it is critical that the current RTOs be maintained by the new master to avoid service interruptions. To accomplish this, RTOs are backed up by the members of an NSRP cluster. Working together, each member backs up the RTOs from the other, which allows RTOs to be maintained should the master of either VSD group in an active/active HA scheme step down.

Taking Control

Enable the preempt option for a device that you want to be master of the VSD group (which is the one we're configuring). Normally, that device also has the better priority number (closer to 1). In the event of a failover resulting in the new master having a lower priority than the previous master, when the previous master—with the preempt option set—becomes operable and eligible again, it automatically regains mastership of the VSD group. So basically, if our master fails and the backup takes over, but the master recovers it will regain control of the cluster. Because we are configuring a NEW master, once connected and configured it will automatically take over. We'll also want to lower the priority back down to 1.

WARNING: Before making this device the master we'll have to recable

set nsrp vsd-group id 0 priority 1
set nsrp vsd-group id 0 preempt 

Monitor

Now what we have configured the device for NSRP, we need to tell it which connection to monitor. The interface we choose will typically be the WAN interface, if this interface goes down the fail-over initiates and the back-up device takes over control of the VSD.

set nsrp monitor int eth1/3

Restoring Order

Everything is configured as it should be. Now we'll just want to make some tweaks.
First we would want to change the hostname of the device, so we can distinguish between the two.

set hostname <hostname>

If we want to have remote access to the device we'll need to setup management IP interfaces for us to use.

set interface ethernet1/1 manage-ip 192.168.1.2
set interface ethernet1/3 manage-ip 192.168.2.1

Now we'll be able to remote in through 192.168.1.2 and 192.168.2.1

We'll also need to change the speed and duplex settings on the interfaces as these do not get copied over

set int ethernet1/1 phy full 100mb
set int ethernet1/3 phy full 100mb

This will set eth1/1 and eth1/3 to full/100.

And that's it! We're finished and your device should be up and running as before.

Creating a VIP in ScreenOS

Port-forwarding in the Juniper world is done by creating MIPs, VIPs and DIPs. A virtual IP (VIP) address maps traffic received at one IP address to another address based on the destination port number in the TCP or UDP segment header. Mapped IP (MIP) is a direct one-to-one mapping of one IP address to another(public ip to private ip ) that means hiding some resources (server) from the public. A dynamic IP (DIP) address pool is a range of IP addresses from which the device can dynamically take addresses to use when performing NAT on the source IP address of outgoing or incoming IP packets.

You can link three types of interfaces to Dynamic IP (DIP) pools: physical interfaces and sub-interfaces for network and VPN traffic, and tunnel interfaces for VPN tunnels only

The most common use for a VIP is to map several DMZ intranet servers to a single public ip address on very small firewalls.

Setup

NOTE: a VIP must be created in the same network as the interface. If you want to forward from another subnet, you need to use NAT-DST

You can create a VIP under two conditions:
1. Your client's Public IP address is on the same network as the Firewall's Untrust interface IP address
2. Your client's Public IP address is the same IP address as the Firewall's Untrust interface IP address

You can assign the IP for the VIP in three ways.
1. Interface IP
2. Zone IP (Untrust)
3. Statically assign it

The address you assign your VIP must be on the same subnet as your Untrust (or the same address entirely), this only comes in to play when using option 3

interface-ip is your best bet for a dynamic address but will only work on ver 6.1 and up
untrust-ip is your next best alternative for use with a dynamic address, but if you have multiple interfaces in the untrust zone, it will choose the default (usually e0/0)
static is if you have the privledge of having a static IP adddress on the interface

For every port you wish you forward, you have to create a unqiue VIP
For example, if you want IMAP and SMTP traffic forwarded to your server at 192.168.1.101 you'll need to set up two VIPs on your outside interface:

set int e0/0 vip interface-ip 143 "IMAP" 192.168.1.101
set int e0/0 vip interface-ip 25 "SMTP" 192.168.1.101

Switcharoo

Sometimes you will need to forward unconventional ports; usually it's either to hide which ports you have open, or simply to accommodate software.
To do this you will need to explicitly define the service.

Say I want to use port 15011 for my BitTorrent traffic because the standard 69xx ports are being blocked; well Juniper doesn't know what operates on port 15011 because it's a non-standard port, therefore I'll have to define it. Because I know BitTorrent operates on 6881-6999, I can narrow down what traffic is forwarded.

set service "BitTorrent_15011" protocol tcp src-port 6881-6999 dst-port 15011-15011

Execution

Now we'll be able to apply this service to a policy (ACL on Cisco appliances)

set policy id 100 from "Untrust" to "Trust" "Any" "VIP(ethernet0/0)" "HTTP" permit log
set policy id 100
set service "BitTorrent_15011"

This will allow all traffic inbound to port 6881-6999 to be forwarded to my 192.168.1.101 client on port 15011.

Mind you, whatever your destination client is, has to be configured to be listening on the port the traffic is being forwarded to. In this case 15011.

Bouncing a tunnel on ScreenOS

So the tunnels down and the head resides on an SSG520 and you have no idea how to bounce it. Well you're in luck, this'll show you how to do it!

First! Connect to the SSG520. Make sure you don't muck around in this box because you can break many many things if you're not careful.

You'll need to connect via telnet or SSH depending on what's configured

Information Gathering

You'll need three commands to find VPN Tunnel information.

The first is:

get ike gateway

You'll be shown the IKE gateway configurations and the Phase 1 proposals as seen below.

SSG520-1(M)-> get ike gateway
 Id  Name            Gateway Address Gateway ID      Mode Proposals
---- --------------- --------------- --------------- ---- ---------
   2 foobardevice    192.168.1.2                     Main pre-g2-3des-sha

The second is:

get vpn

To see the VPN association with the IKE gateway and the Phase 2 proposals

SSG520-1(M)-> get vpn
Name            Gateway                  Mode RPlay 1st Proposal         Monitor Use Cnt Interface 
--------------- ----------------------- ---- ----- -------------------- ------- ------- ----------
foobardevice    foobardevice-isr        tunl No    g2-esp-3des-sha      on            0 eth3/0    

And lastly;

get sa

To examine the security association information.

SSG520-1(M)-> get sa | i 192.168.1.2

00000007<    192.168.1.2   500 esp:3des/sha1 7b0f24a1  2668 unlim A/U    -1 0
00000007>    192.168.1.2   500 esp:3des/sha1 4d512b11  2668 unlim A/U    -1 0

Insight

Now we have a plethora of information, but we still haven't bounced the tunnel. Lets use the information we've gathered to do that.

There's two things you'll need to clear, Phase 1 and Phase 2.

Since the editors at Wikipedia can explain this better than I can, I've provided a snippet below detailing Phase 1 and 2 for those who are unfamiliar with the process:

IKE consists of two phases: phase 1 and phase 2. IKE phase 1's purpose is to establish a secure authenticated communication channel by using the Diffie–Hellman key exchange algorithm to generate a shared secret key to encrypt further IKE communications. This negotiation results in one single bi-directional ISAKMP Security Association (SA). The authentication can be performed using either pre-shared key (shared secret), signatures, or public key encryption. Phase 1 operates in either Main Mode or Aggressive Mode. Main Mode protects the identity of the peers; Aggressive Mode does not. During IKE phase 2, the IKE peers use the secure channel established in Phase 1 to negotiate Security Associations on behalf of other services like IPsec. The negotiation results in a minimum of two unidirectional security associations (one inbound and one outbound). Phase 2 operates only in Quick Mode.

Tear Down

So you're a little bit smarter, and know what we'll be clearing. Let us proceed!

Phase 1 comes first.

The first command we issued provided us with an "IKE Gateway". This is just the public address of the peer (a peer is the other end of the tunnel).

Phase 1 is stored in an IKE cookie (not chocolate chip, think a browser cookie and you'll have a better understanding of how it works). We'll have to get rid of this cookie to wipe out Phase 1 information for the specific peer.

clear ike-cookie 192.168.1.2 

Sometimes just clearing Phase 1 will cause the tunnel to rebuild. If it does not we'll have to clear Phase 2 information (it's usually safer to tear the entire tunnel down anyway).
Onward to Phase 2!

We need to clear the security association for the tunnel.

If you remember when we input get sa, on the left-hand column we saw a bunch of numbers. These are hexidecimal labels used to identify a specific association.

SSG520-1(M)-> get sa | i 192.168.1.2 
00000007<    192.168.1.2   500 esp:3des/sha1 7b0f24a1  2668 unlim A/U    -1 0
00000007>    192.168.1.2   500 esp:3des/sha1 4d512b11  2668 unlim A/U    -1 0

No we won't be doing hex conversions, don't worry. But you will notice that there are two associations for one peer. One is for inbound, and the other for outbound. You can see which is which by looking at the arrow next to the hex ID.

We'll be using that hex ID to clear that specific association.

clear sa 0x07

If you've never used hex codes before, the preceeding 0x just identifies what proceeds as hexidecimal. We don't need to provide the entire ID as it's all zeros.

And that's it! You've successfully bounced the tunnel from an SSG520.

Rebuild

We tore down the tunnel but it's not coming back up. Probably because the user thinks it's down and isn't trying to use it. A tunnel won't be established until we flood it with interesting traffic. And what could be more interesting than pings!

ping 192.168.1.10 from e3/0

Where the IP address is the VPN address at the remote site, and the interface is the one used with the tunnel.

You can find the tunnel's interface in the output from get vpn command we input earlier.

SSG520-1(M)-> get vpn
Name            Gateway                  Mode RPlay 1st Proposal         Monitor Use Cnt Interface 
--------------- ----------------------- ---- ----- -------------------- ------- ------- ----------
foobardevice    foobardevice-isr         tunl No    g2-esp-3des-sha      on            0 eth3/0