Showing posts with label SSG. Show all posts
Showing posts with label SSG. Show all posts

Tuesday, August 5, 2014

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.

Thursday, May 29, 2014

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

Tuesday, February 25, 2014

Policy-based NATing on ScreenOS

Source NATing

I recently had to deploy a firewall for a home user where the VPN address space was limited, and it would be best to not re-IP the LAN devices as only specific destinations would be accessed through the VPN. To accomplish this, I employed some simple static routing and source NATing.

When sending traffic from the LAN through the VPN, because we're using the same addressing space (for this example 10.10.0.0/16) source NATing allows us to have a neutral address for both the source and destination.

If you would like to have more than one host connecting with unique IP addresses, it's best to utilize a DIP pool to use with your NATing; this acts much like a DHCP pool. You can additionally enable PAT (Port Address Translation) which supports up to 64,500 hosts simultaneously. However, a DIP pool is best used (with PAT disabled) when the source port number must remain fixed. When done in this fashion, the SSG will issue one address for the same host for all of it's sessions. Whereas with PAT enabled, each session might receive a unique source address.

If you do not specify a DIP pool, the SSG will translate the source address to the egress (outgoing) interface. When you do this, PAT is automatically enabled. I find this way much easier for our purpose.

So first thing's first, lets define our hosts; because we're connecting from a handful of possible devices who are utilizing DHCP, we're going to just define the entire subnet:
set address "Trust" "192.168.1.0/24" 192.168.1.0 255.255.255.0
set address "DMZ" "10.10.0.0/16" 10.10.0.0 255.255.0.0
The DMZ address here is our remote network.

Now for the routing:
set route 10.10.0.0/16 interface tunnel.1
So anything destined for 10.10.0.0/16 will be routed through the tunnel interface; which just so happens to have an address in that scheme.

Now for the policy and NAT:
set policy from "Trust" to "DMZ" "192.168.1.0/24" "10.10.0.0/16" "ANY" nat src permit log
Any traffic from our local subnet of 192.168.1.0/24 destined for 10.10.0.0/16 will be routed through the tunnel interface after being NATed to the egress interface's IP address; our tunnel interface, which as stated earlier holds an IP in the 10.10.0.0/16 scheme!

For those of you who wish to use a DIP pool, I've got you covered!
set interface ethernet0/1 dip 1 10.10.1.1 10.10.1.254 fix-port
set policy from "Trust" to "DMZ" "192.168.1.0/24" "10.10.0.0/16" "ANY" nat src dip-id 1 permit log
 
For this to work, because the 10.10.0.0/16 network lives on both ends of the tunnel, a route on the head will have to be set to route anything destined for the 10.10.1.0/24 range through the tunnel to our LAN.

The fix-port option in the DIP denotes that PAT will not be used.; remove this option to enable PAT.


To be continued with destination NATs, MIPs and VIPs...


Thursday, November 28, 2013

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"

Friday, November 22, 2013

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

Monday, May 27, 2013

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