Tuesday, January 22, 2013

Chapter 7 VPNs

Juniper Chapter 7 - VPNs


lab@srxA-1# set security ike proposal ike_proposal dh-group ?
Possible completions:
  group1               Diffie-Hellman Group 1
  group14              Diffie-Hellman Group 14
  group2               Diffie-Hellman Group 2
  group5               Diffie-Hellman Group 5


Ok.

Diffie-Helman
So in order to exchange a key from one device to another over the public web you can use
the DH way. The way is basically a nice way of exchanging a secret.

The possible completions are groups 1 2 5 and 14. I think the exam only uses 1 2 5.
The higher the number the more secure the exchange is.

In order to start set up the group. It needs to match for both devices.

set security ike proposal NAME_OF_PROPOSAL  dh-group  group1


The Diffie-Helman will simply exchange the keys.
In order to make SURE that the other device is who he says he is and not just some random device.
We need to be able to authenticate him.
There are two ways of doing this.
1. Is using Certificates, you remember certificates with a CA. Most people don't use this as it
is very complex.
2. The second way which is more common is using the authentication-algorithm
along with a pre-shared-key.
The pre-shared-key on both devices must match. So the only way to do this is to
verbally exchange the key with the person configuring the other device.

To configure it we will select
lab@srxA-1# .set security ike proposal ike_proposal authentication-method
Possible completions:
  dsa-signatures       DSA signatures
  pre-shared-keys      Preshared keys
  rsa-signatures       RSA signatures

We will choose the preshared keys
set security ike proposal NAME_OF_PROPOSAL     authentication-method pre-shared-keys

This is the algorithm to generate the keys using a Hash.
lab@srxA-1# set security ike proposal ike_proposal authentication-algorithm

Possible completions:
  md5                  MD5 authentication algorithm
  sha-256              SHA 256-bit authentication algorithm
  sha1                 SHA1 authentication algorithm

for example the MD5 hash for
MD5("The quick brown fox jumps over the lazy dog.")
is    = e4d909c290d0fb1ca068ffaddf22cbd0
set security ike proposal NAME_OF_PROPOSAL   authentication-algorithm md5

Now the SRX will compare my Hash   to  the other SRXs Hash
and if they match it will consider them to be  authenticated one to the other.

The way it sends them is using the Diffie-Helman
So the MD5 key I generated will be the "common paint" in this wikipedia DH example.



Diffie-Helman
Illustration of the Diffie-Hellman Key Exchange





So
we will use pre-shared-keys
we will Hash them
and use DH as the transport to exchange them.

Ok.
Once the keys are established and both parties are authenticated.
lab@srxA-1# security ike proposal ike_proposal encryption-algorithm ?
Possible completions:
  3des-cbc             3DES-CBC encryption algorithm
  aes-128-cbc          AES-CBC 128-bit encryption algorithm
  aes-192-cbc          AES-CBC 192-bit encryption algorithm
  aes-256-cbc          AES-CBC 256-bit encryption algorithm
  des-cbc              DES-CBC encryption algorithm


The traffic itself will be encrypted by encapsulating the WHOLE packet in ESP.
The level of encapsulation will be determined.
Again they need to match.
set security ike proposal   NAME_OF_PROPOSAL     encryption-algorithm 3des-cbc


these are the tools that will be used.
Now we bond them into a policy.
IKE is flexible so we can create many proposals.
for example the SRX might support the mixture of   3des-MD5-DH(group5)
but the   older PIX might only accept 3des-MD5-DH(group1)
So you can create Two proposals. If the first one does not work, the SRX will try the second one.
Or you can use the same proposal to connect to two different types of devices.
set security ike policy ike_policy_name  proposal     NAME_OF_PROPOSAL
you can repeat the same command to add another one.
set security ike policy ike_policy_name  proposal     NAME_OF_PROPOSAL0002

If you can't be bothered to set up a specific proposal SRX has some built in proposals.
The predefined Phase 1 proposals that JUNOS software provides are as follows:

Standard—pre-g2-aes128-sha and pre-g2-3des-sha
Compatible—pre-g2-3des-sha, pre-g2-3des-md5, pre-g2-des-sha, and pre-g2-des-md5
Basic—pre-g1-des-sha and pre-g1-des-md5

So they are all pre-shared-keys   , the basic is DH group 1  the rest are Group2. Etc.
So Compatible is made up from 4 proposals which will all be tried in order to get a match.

Ok
Two types of policies exist.
MAIN and Aggressive.

lab@srxA-1# set security ike policy ike_policy mode ?
Possible completions:
  aggressive           Aggressive mode
  main                 Main mode

MAIN is for site to site   so memorize that.
Aggressive is for home users or where the IP of the other side changes.

The last thing in the policy is you define the pre-shared-key we talked about that will be HASHED.
set security ike_policy pre-shared-key ascii-text       MY_Secret_KEY 
in the example I gave you above it was
MD5("The quick brown fox jumps over the lazy dog.")
but whatever you choose.

So Policy. Calls up the proposals
Sets up the pre-shared-key  which is a secret
and selects the mode of MAIN  for site to site.

Man, this is long.
All of this was how we will negotiate the Phase 1 of IKE.
To set up the address of the remote SRX.
We need to set up a Phase 1 IKE gateway.
set security ike gateway 
lab@srxA-1# set security ike gateway remote_SRX_device  ?
to complete this we need to tell it.
What interface to use when trying to set up the gateway. This will be the WAN interface that allows
you to reach that gateway using routing protocols. (You should be able to ping the other side) from this interface
lab@srxA-1# set security ike gateway remote_SRX_device external-interface   GE-0/0/1

then
lab@srxA-1# set security ike gateway remote_SRX_device ike-policy    ike_policy
we will call up the policy that took so long to set up.

Then
we will type in the IP of the remote SRX public interface.

lab@srxA-1# set security ike gateway remote_SRX_device remote-identity ?      
Possible completions:
> hostname             Use a fully-qualified domain name
> inet                 Use an IPv4 address
> inet6                Use an IPv6 address

Now as you can see there are a few options.  INET would be an IP  or you can use DNS.
(the assumption here is you configured the SRX to use DNS)


So to sum the phase 1 up.
The IKE gateway calls up a policy which has proposals in it.
It says which interface it will use to reach the other guy
it says what is the IP of the other guy will have.

The policy calls up proposals, sets up the type as MAIN(sitetosite)  and sets up the "secret" between them.

The proposal sets up the security for the exchange, the encryption and the authentication.

Voila
Phase 1 is done.
Now both devices are in sync
And either one can start up a    Phase 2  which is the actual VPN negotiation.




Part 2
Phase 2 of   IPSEC VPN.
For this phase we will use the Stanza/
set security   ipsec         remember the last one was ike.   This is ipsec.

This will also follow the same procedure.
proposal --> policy -->  vpn
well, almost the same.

proposal

lab@srxA-1# ...set security ipsec proposal ipsec_proposal authentication-algorithm ?            
Possible completions:
  hmac-md5-96          HMAC-MD5-96 authentication algorithm
  hmac-sha-256-128     HMAC-SHA-256-128 authentication algorithm
  hmac-sha1-96         HMAC-SHA1-96 authentication algorithm


Ok, same as before. For each side to know the other one is who he says he is.
The pre-shared-key  will be   HASHED again.
The difference here is that they added the hmac-xxx-xx
This and the ipsec stanza should help you know this is different than the other one.
set security ipsec proposal ipsec_proposal authentication-algorithm  hmac-md5-96

Ok, now remember we wrapped the whole packet with IPSEC ESP using the encryption.
lab@srxA-1# ...osal ipsec_proposal encryption-algorithm ?
Possible completions:
  3des-cbc             3DES-CBC encryption algorithm
  aes-128-cbc          AES-CBC 128-bit encryption algorithm
  aes-192-cbc          AES-CBC 192-bit encryption algorithm
  aes-256-cbc          AES-CBC 256-bit encryption algorithm
  des-cbc              DES-CBC encryption algorithm

So same thing, we will wrap the data with an encrypted envelope.
The levels are  des,3des  and aes.
This looks the same as we did in the IKE before .
set security ipsec proposal ipsec_proposal encryption-algorithm 3des-cbc
this also can be different than the one in phase-1  but must match the one on the other side.

OK. That was ONE proposal. Again you can set up 2-3 if you want and then call them from the policy.

Policy.
set security ipsec  policy
lab@srxA-1# set security ipsec policy ipsec_policy_NAME       proposals         ipsec_proposal

so let's recup. I just created a policy and called it "ipsec_policy_name"    and in it I called for it
to use the proposal we created    "ipsec_proposal".
set security ipsec policy ipsec_policy_NAME       proposals         ipsec_proposal


Now if you are a security nut.
Then because you already sent data in phase-1 there is an option to regenerate a DH communication
a new one. Sort of a double double security.   This is called.
PFS perfect forwarding secrecy


lab@srxA-1# .set security ipsec policy ipsec_policy        perfect-forward-secrecy keys ?
Possible completions:
  group1               Diffie-Hellman Group 1
  group14              Diffie-Hellman Group 14
  group2               Diffie-Hellman Group 2
  group5               Diffie-Hellman Group 5


So you can redo another DH key exchange just to be completely secure.
They simply want to know what level of DH do you want to use. (let's say 5 this time)
set security ipsec policy ipsec_policy        perfect-forward-secrecy keys   group5


VPN
So finally we get to set up the VPN.

So first we call up the ipsec policy we created , that ipsec policy will call up the ipsec proposal

lab@srxA-1# set security ipsec vpn VPN_TO_REMOTE_SITE ike ipsec-policy     ipsec_policy


then we call up the gateway we created under IKE so it knows where to go IP wise.
 set security ipsec vpn VPN_TO_REMOTE_SITE ike gateway    remote_srx
see I already forgot the name of the gateway since it was so far back.....


Now, the tunnel will be set up the minute some traffic flows.
If you want it to be set up immediately

lab@srxA-1# set security ipsec vpn VPN_TO_REMOTE_SITE establish-tunnels ?
Possible completions:
  immediately          Establish tunnels immediately
  on-traffic           Establish tunnels on traffic


 set security ipsec vpn VPN_TO_REMOTE_SITE establish-tunnels immediately 

Ok.
Even with this establish-tunnels immediately you STILL won't have a tunnel up.

So there are two ways to bring the tunnel up.
1. Is policy based.
You will have  a policy that says for example.
When traffic comes from the LAN  and goes up to the VPN   then send that traffic through the tunnel.


edit security policies from-zone LAN to-zone VPN
set policy vpnpolicy-LAN-VPN     match source-address local-net
set policy vpnpolicy-LAN-VPN    match destination-address remote-net
set policy vpnpolicy-LAN-VPN     match application any
set policy vpnpolicy-LAN-VPN           then permit tunnel ipsec-vpn       VPN_TO_REMOTE_SITE
set policy vpnpolicy-LAN-VPN            then permit tunnel pair-policy VPN-LAN

So we created a policy from LAN to VPN
matched the LAN traffic   to the addresses of the IPs in the remote network
for example . My LAN might be 192.168.0.0/24     and theirs might be   172.16.0.0/24

Match the application to any.

THEN      we permit the traffic and funnel it to the tunnel which is an ipsec-vpn   - we funnel it to the one
we created.

In this case I also added a tunnel pair-policy.
A tunnel pair-policy  is the same policy but in the opposite way.
So

edit security policies from-zone VPN to-zone LAN
and you basically reverse everything.

set policy vpnpolicy-VPN-LAN     match source-address remote-net
set policy vpnpolicy-VPN-LAN    match destination-address local-net
set policy vpnpolicy-VPN-LAN     match application any
set policy vpnpolicy-VPN-LAN           then permit tunnel ipsec-vpn       VPN_TO_REMOTE_SITE
set policy vpnpolicy-VPN-LAN            then permit tunnel pair-policy vpnpolicy-LAN-VPN


So we basically created a pair of security policies allowing traffic - back and forth.


So let's review the process again.
We created an ike gateway  that called up an ike policy  which had many proposals.

Then we created an IPSEC VPN which called up an ipsec policy which had ipsec proposals.

Then we created 2 policies, back and forth.

OK.
I didn't get this yet.
But apparently you also need to set up a proxy.
proxy-identity {
            local 10.10.30.0/24;             #would be me
            remote 10.10.20.0/24;            # would be the remote device
            service any;    
SRX should work by default without this but anytime you connect an SRX to anohter device
you will need to set this up per vpn tunnel.


So.
Our policy VPN should be up right now.
Every time a packet matches the from zone to zone  then the VPN will go up and create a flow encapsulated by a VPN to the remote site.

There is another method of working.
This is called ROUTE 
Under the VPN we will establish a  fake virtual interface called  st0.x
set security ipsec vpn VPN_TO_REMOTE_SITE {
    bind-interface st0.6;

Then we need to configure interface st0.6
set interface st0 unit 6 family inet address   x.x.x.x/x b    
You can use private addressing for this

then you add that interface to the zone  you called VPN or Public
set security zone VPN interface st0.6   

last but not least.
Set up a nice Static Route or a routing protocol on that interface.
A static would be.
set routing-options static route   172.16.0.0/24 next-hop      ip_you_gave_otherside_st0.6
or
set protocols ospf area 0.0.0.0 interface st0.6 
then you can manually add in the neighbor on the other side as this is not a broadcast network.
set protocols ospf area 0.0.0.0 interface st0.6 neighbor 

If you do not use a routing protocol you can set up the dead peer detection which will detect if the VPN is down. You need the INTERVAL and the Number of times it will allow fail  THRESHOLD
Ok, the last parts are a bit sketchy. I am still labbing it.
You can try the lab I set up.
Sorry.
don't blame me :).




1 comment: