Thursday, December 27, 2007

Juniper VPN IPSec Tunnel Theory and Terminology

IPSec is the framework consisting of several protocols for securing communications at the IP Layer.

IPSec was created to provide the following three key services:

- Privacy and Confidentiality - Encrypting data so that a man in the middle cannot intercept and read data.
- Integrity and Origin Authentication - Authentication so that it can be confirmed that both ends are who they say they are and that the data has not been tampered with.
- Protection against Replay Attacks - This ensures that the communications cannot be captured and retransmitted at a later time.

IPSec consists of two modes, Transport and Tunnel.
IPSec consists of two protocols, Encapsulating Security Payload (ESP) and Authentication Headers (AH).
IPSec allows for the manual or automatic negotiation of security assocations (SAs).
All of the information makes up the domain of interpretation (DOI) for IPSec, which is used to establish SAs and Internet Key Exchange (IKE).

IPSec Modes
As stated previously, IPSec uses two modes, Transport and Tunnel.
Transport mode requires that both ends of the VPN Tunnel be hosts. Only the payload of he packet is encrypted, the header of the packet remains unaltered. An analogy for this would be an enevelope, you can see the source and destination address, but cannot see what is inside the envelope.
Tunnel mode requires that at least one endpoint of the tunnel be a Juniper Security Device such as a Firewall or Router. The entire packet is encapsulated into another packet. This packet has it's own header.

Protocols
Two protocols are used by IPSec to verify the source and integrity of a packet thas has been recieved. They are Authentication Headers and Encapsulation Security Payload.

Authentication Headers provide a means to verify the source of an IP Packet. It is also used to verify data integrity of the payload of the packet. AH can also protect against replay attempts.

Encapsulating Security Payload provides methods to ensure data privacy, source authentication, and payload integrity. ESP may also protect against replay attacks. ESP is used in tunnel mode to encrypt the entire packet and attach a new ip header to the packet so that the packet can be routed. In transport mode ESP only encrypts the payload. ESP can optionally authenticate the packet.

Internet Key Exchange
In manual key configurations, both ends of the tunnel are manually configured no negotiations are required. The key is never changed unless the administrator of the network chooses to change it, this process can be quite cumbersome since each endpoint must be reconfigured.
The Internet Key Exchange (IKE) system generates and negotiates keys and SAs automatically based on preshared secrets or digital certificates. A preshared secret is nothing more then a key both parties have prior to initiating the negotiations. IKE can set an expire time on the key and re-negotiate the key when the key expires. This helps secure the data from replay attacks.

Security Associations
Security Associations (SAs) are the concept used by IPSec to manage all the parameters required to establish a VPN tunnel. In simple terms, SA is a set of paramters describing how communications are to be secured. An SA can contain the following items: Security Keys and Algorithms, mode of operation (transport or tunnel), key management method (IKE or manual key), and lifetime of the SA. All active SAs are stored in a database called the Security Association Database (SAD). The SAD contains all paramters needed for IPSec operation. In order for bidirectional communication, you must have at least two SAs, one for each direction.

NTP Servers

NTP (Network Time Protocol) is a useful service to enable on your devices so that they can accurately update the date/time on their systems. This is essential for accurate logging.

The following are the NTP servers currently running at the University of Toronto (-5 GMT) which are accessible by the public.

Hostname / IP address
chime.utoronto.ca / 128.100.102.201
tock.utoronto.ca / 128.100.100.128
tick.utoronto.ca / 128.100.56.135
tyme.utoronto.ca / 128.100.18.14

Further information regarding NTP at UofT can be found here:
http://madhaus.utcs.utoronto.ca/cns/UTORtime.html

Further information regarding the NTP Project can be found here:
http://www.ntp.org/

Resetting a Juniper Netscreen to Factory Defaults

If you run into a situation where you are unable to access your netscreen (forgotten password etc) you can reset the unit to factory defaults if you have physical access to the device.

Doing this is a bit easier then with a cisco device, mostly beacause there is a pinhole button on the back of the unit, sometimes labelled "Asset Recovery". You can push this button with a thin firm wire such as a straightened paper-clip.

Here are the steps to resetting your device:
1. Connect your console cable to the device and start an active serial connection.
2. Power on your device.
3. Wait for your device to complete it's boot process.
4. Push and hold the pinhole button with the paper-clip. When the button is pressed you should see the following message pop-up on the console:
Configuration Erasure Process has been initiated.
5. Continue to hold the button in until the following message is displayed on the console:
Waiting for 2nd confirmation.
Then release the button.
6. Wait 3-4 seconds then push the button again and hold until the following message appears on the console:
2nd push has been confirmed.
Configuration Erase sequence accepted, unit reset
7. Release the button, the unit will now reboot with it's factory default configuration.

Don't forget that after your netscreen reboots it's username/passsword will be netscreen/netscreen.

Tuesday, December 25, 2007

Creating a MIP in a Juniper Netscreen

When an ISP routes a block of IPs to a particular site, one ip will be utilized for the edge (outside) interface and the rest of the subnet will be available for routing towards hosts on at the site.

In this post we are going to be looking at a Mapped IP address (MIP) on a Juniper Netscreen. We will be mapping a outside internet routable ip (186.27.45.2) to a server on our trusted LAN segment (192.168.1.100).

The first thing we have to do is create the MIP mapping. To do this we log into the Netscreen GUI. Click on Network->Interfaces-> and then click "edit" on the row contains your outside (untrust) interface.

On the page you are directed to, you should see a row that says "Properties" click "MIP" and then click the "New" button.

There will then be four dialog boxes which you must fill out. The options are below.

Mapped IP: 186.27.45.2 - the outside address you are mapping to your internal host
Netmask: 255.255.255.255 - subnet mask reflecting a 1to1 mapping
Host IP Address: 192.168.1.100 - the inside address of your host.
Host Virtual Router Name: trust-vr - the virtual router where your inside host is attached to

After you have your MIP configured and set up, you must then create a policy to allow data to flow from the outside to your internal host.

In your Netscreen GUI, click Policies then select from the dropdown boxes at the top of the screen. "From: Untrust" and "To:Trust". Then click the "New" Button.

Configure the Policy as follows, if an option is left out below, leave it to the default setting.

Source Address: Any
Destination Address: MIP(186.27.45.2)
Service: HTTP - (you will need to select whatever services you require)
Action: Permit
Logging: Enabled

Click "OK" and everything is now setup.

I like to enable PING and TRACEROUTE as some of the services just for testing purposes. The policy can later be edited to remove the services.

I found the following links useful for testing my MIP setups:
http://www.fifi.org/services/ping
http://www.fifi.org/services/traceroute

Monday, December 24, 2007

CISCO 827 Router Config

The first device I am going to configure on my new test lab is the Cisco 827 which will be used to connect to ADSL internet provider.

The Cisco 827 has a ADSL (modem) interface along with a single Ethernet interface.

The flash image on this router is a bit old but we will upgrade it later. For now lets get the damn thing up and running.

Below is the config I have entered into the device. Comments will be in italic.

MarkyZ_Home_827#sh run
Building configuration...

Current configuration:
!
version 12.1
no service pad
service timestamps debug uptime
service timestamps log uptime
no service password-encryption
!
hostname MarkyZ_Home_827
!
!
!
!
!
!
ip subnet-zero
!
vpdn enable
no vpdn logging
! VPDN referrs to Virtual Private Dial-Up Network.
!
vpdn-group pppoe
request-dialin
protocol pppoe
! Declaring that the type of VPDN is going to be PPPoE
! "Request-Dialin" is stating that the router is to dial in to a Carrier Device.
! The protocol that is going to be used is PPPoE (Peer to Peer over Ethernet)
!
interface Ethernet0
ip address 192.168.2.1 255.255.255.0
ip nat inside
shutdown
! The above is just LAN segment junk.
!
interface ATM0
no ip address
no atm ilmi-keepalive
bundle-enable
dsl operating-mode auto
hold-queue 224 in
!
! ATM0 referrs to the ADSL interface of the router.
! Defaults are being used.
!
interface ATM0.1 point-to-point
pvc 0/35
pppoe-client dial-pool-number 1
!
! 0/35 referrs to the VPI/VCI value set by the isp.
!
interface Dialer1
ip address negotiated
ip mtu 1492
ip nat outside
encapsulation ppp
dialer pool 1
ppp authentication chap callin
ppp chap hostname username@carrrier.com
ppp chap password p@$$w0rd
!
! Setting up the Dialer Interface. If the carrier uses PAP rather then CHAP, the CHAP commands must be removed and the appropriate PAP commands must be added.
!
! Ethernet MTU is 1500 by default. By setting the default here to 1492 we allow the PPPoE headers to not overrun the default size.
!
ip nat inside source list 1 interface Dialer1 overload
ip classless
ip route 0.0.0.0 0.0.0.0 Dialer1
no ip http server
!
! NAT stuff, yay.
! The default route is pointing to the name of the Dialer1 interface rather then the ip since the ip COULD be dynamic. In our case it won't since i own a /30 from the ISP. :)
!
access-list 1 permit 192.168.1.0 0.0.0.255
access-list 1 permit 192.168.2.0 0.0.0.255
access-list 1 permit 192.168.3.0 0.0.0.255
access-list 1 permit 192.168.4.0 0.0.0.255
!
line con 0
transport input none
stopbits 1
line vty 0 4
!
scheduler max-task-time 5000
end

First Blog Post

This is the first post on the MarkyZ Networking Brain Dump Blog.

This purpose of this blog is to dump any kind of networking knowledge, notes or just useful information that I need to remember or access quickly.