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
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.....
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
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.
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.
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.
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
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
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 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 :).
You can try the lab I set up.
Sorry.
don't blame me :).
You are amazing mate
ReplyDelete