Friday, February 8, 2013

JNCIS-SEC

Passed.

Before I started labbing I failed.
After the labs I passed.

So buy some SRXs.


Good luck.
1234567891012345678910123456789101234567891012345678910123456789101234567891012345678910123456789101234567891012345678910
Saar

Monday, January 28, 2013

UTM features all last 4 chapters

This summary is not available. Please click here to view the post.

Chapter 9 High Availability

High Availability


Yes, this is proprietary.
Yes, it is on the exam. Something like 5-10 questions.

Ok.
So basically if you get two identical devices.
With identical memory.
With identical I/O , SPC and NPC s all in the same identical spot.

You can create a high availability cluster.
This is a big selling point, as the "proprietary" software does most of the work
for the IT manager and you can live up to the "redundant" devices creed.

This is pretty much it.




First off, the bigger devices (the non- branch) devices are usually set up with an external IP to manage them.
This IP will usually be on a separate network. Called a "management network" this is desinged so you can troubleshoot the network even when the network is under load.
Juniper calls this interface the FXP0

The second thing is configuring the Control Link.
This link will maintain the High Availability keep alive.
In the bigger devices this is done from one SPC to another SPC.
This is called the FXP1

The third thing is the DATA LINK.
This is a data link that on it will run the updates.
State and session will be sent to the "backup" device every time there is a change.
Juniper calls these objects   RTO real time object.
This is the FAB0 and FAB1

The fourth this is the RETH. This is the code name for Redundant Ethernet.
Each device that goes into the firewall cluster should have TWO links.
One per each firewall, the reason is so if one link fails the other one is still alive.
This is similar to LAG, MLAG.
The idea is you configure an interface on each chassis as a child of the RETH.
Then configure the RETH with an IP. In case of one child failing the other one still works.

The final thing to configure is the "redundancy-group".
A redundancy group allows you to set up a logical group.
That will have interfaces in it.
For example.
RG1 will have   RETH1 and RETH2.
Now you can set up one SRX0001 as the primary and the second as backup.
In RG2  you will have RETH 3 and RETH4  and in it SRX0002 is the primary.

Now the reason to use it, is so you can load balance the traffic.
Now half of my traffic  (from RETH1 and RETH2)  will flow using the resources of SRX001
The other half will flow using the resources of SRX002.

A sub part of this is that the redundant-group can monitor certain interfaces  for example (the one to ISP2)
and if that interface fails. It can move over the RETH3/4 to use the other SRX001 as their point of exit.
For example if the other guy becomes a shorter exit.
The SRXs are set up with a prioirty of 1-255  and you need to specify the word preempt
for a change in seniority to actually happen.


So let's put it in code.
> set chassis cluster cluster-id  1  node 0         up to 15 cluster ID  --- node 0 or 1 only.
reboot
Then

This is the same as ITEM 2 on my list.
You set up which ports will be the Control ports.
Then on the SRX002
> set chassis cluster cluster-id  1  node 1         this one will be node 1.
reboot.

So now you have a clustered chassis sending control from one to another.
Now
Set up the management ports FXP0

To set this up you need to use the "apply-groups"  this is the only part that uses this, so memorize it for now.


Now you can set up the ports that will send the RTO objects over the data link
basically the sessions and flow information so they can keep in sync.
FAB 0 and FAB1
set interface FAB0    fabric-options     member-interfaces    (interface from node0)
set interface FAB1    fabric-options     member-interfaces    (interface from node1)

pretty easy no ?. The interfaces must be the same bandwidth etc.

So we have the FXP0 mangement IP on it.
The FXP1  control
The FAB0 /1   data link.


Now depending on how many devices you plan on connecting you set up the number of RETHs
you will need.
So if I will have 4 devices.
set chassis cluster  reth-cout  4

then I can set up each reth group.
set interface ge-x/y/z   gigether-options      redundant-parent RETH1
set interface ge-x+12/y/z   gigether-options      redundant-parent RETH1
so I took one interface from one node and another from the other node and added them to RETH1

now I can give RETH1 an IP
set interface reth1  redundant-ether-options redundancy-group 1
set interface reth1  unito 0 family inet address   192.168.1.1/24



Pretty much now I have a working firewall connected to one device with two links.
If one child link dies the other one will still send data.

redundant-groups
now if you remember we talked about the redundant-group which can be used to load balance
traffic.

set chassis cluster   redundancy-group 1
set chassis cluster   redundancy-group 1   node 0 priority 250     #this one is higher so he wins
set chassis cluster   redundancy-group 1   node 1 priority 50   
set chassis cluster   redundancy-group 1    preempt         # without this command nothing will change.
set chassis cluster   redundancy-group 1   interface-monitor  ge-0/0/2 weight 250

The last one is the weight, you set it up so if interface ge-0/0/2 fails  then the primary (in this case node 0)
will get deducted a weight of 250 which means he will not longer have the higher priority
and will then become the secondary.


to go back to normal
set chassis cluster disable reboot


I forgot if a cluster control link fails on one side, the other device will be disabled and will need to be restarted.
If BOTH links fail at the same time, then they will split into two separate devices.

Wednesday, January 23, 2013

Lab3 VPN site to site


IPSEC VPN LAB

Very simple.
Point to Point.
(Simple is an overstatement).


root@srx101# show
## Last changed: 2013-01-22 22:45:56 UTC
version 12.1R1.9;
system {
    root-authentication {
        encrypted-password "$1$FfXnmjya$RYPXZFcgPFjwa4b26sIFp/"; ## SECRET-DATA
    }
}
interfaces {
    fe-0/0/1 {
        unit 0 {
            family inet {
                address 11.0.0.1/24;                       ##this is the WAN interface
            }
        }
    }
    fe-0/0/7 {
        unit 0 {
            family inet {
                address 192.168.0.1/24;                     ##this is out LAN interface
            }
        }
    }
    st0 {
        unit 0 {
            family inet {
                address 15.15.15.2/24;                          ##this is the IP of the VPN interface
            }
        }
    }
}
protocols {
    ospf {
        area 0.0.0.0 {
            interface st0.0 {
                interface-type p2p;
                neighbor 15.15.15.1;                          ##I needed somehow to send the routes
            }                                                                   so OSPF is easier than static routes
            interface fe-0/0/7.0;                                       the OSPF is from each ST0.0 interface to the other
        }
    }
}
security {
    ike {
        proposal IKE_Proposal {
            authentication-method pre-shared-keys;                   ##this is the IKE proposal
            dh-group group2;
            authentication-algorithm sha1;
            encryption-algorithm 3des-cbc;
        }
        policy ike_policy {
            mode main;                                                       ## Ike Policy which calls up proposal
            proposals IKE_Proposal;
            pre-shared-key ascii-text "$9$IQNceWLX-Vb2WL"; ## SECRET-DATA
        }
        gateway ike_gateway {
            ike-policy ike_policy;                                        ##IKE gateway which uses the policy and WAN
            address 11.0.0.2;
            dead-peer-detection {
                interval 10;
                threshold 3;
            }
            no-nat-traversal;                            ## since I don't have a NAT in my cloud I added this
            external-interface fe-0/0/1.0;                          
        }
    }
    ipsec {
        proposal remote_ipsec {                                        ##ipsec marriage proposal
            protocol esp;
            authentication-algorithm hmac-sha1-96;
            encryption-algorithm aes-128-cbc;
        }
        policy ipsec_policy {                                          ##Ipsec policy calls up the proposal
            proposals remote_ipsec;
        }
        vpn remote_vpn {                             ##VPN setup
            bind-interface st0.0;
            ike {
                gateway ike_gateway;
                proxy-identity {
                    local 0.0.0.0/0;
                    remote 0.0.0.0/0;
                    service any;                                          ##proxy identity is good if you are connecting to ASA
                }
                ipsec-policy ipsec_policy;
            }
        }
    }
    nat {
        source {
            rule-set nat {                                                ##I set up a NAT for the ping to work from
                from zone LAN;                                          192.168.0.0 range to   192.168.1.0
                to zone VPN;
                rule 1a {
                    match {
                        source-address 192.168.0.0/24;
                        destination-address 192.168.1.0/24;
                    }
                    then {
                        source-nat {
                            interface;
                        }
                    }
                }
            }
        }
    }
    policies {
        from-zone LAN to-zone VPN {                                             ##security policy to allow traffic
            policy remote-office {
                match {
                    source-address any;
                    destination-address any;
                    application any;
                }
                then {
                    permit;
                    log {
                        session-init;
                        session-close;
                    }
                }
            }
        }
        from-zone VPN to-zone LAN {                               ##security policy back
            policy Remote_office {
                match {
                    source-address 15.15.15.0/24;
                    destination-address 192.168.0.0/24;
                    application any;
                }
                then {
                    permit;
                    log {
                        session-init;
                        session-close;
                    }
                }
            }
        }
    }
    zones {
        security-zone LAN {
            address-book {
                address 192.168.0.0/24 192.168.0.0/24;
            }
            interfaces {
                fe-0/0/7.0 {
                    host-inbound-traffic {
                        system-services {
                            all;
                        }
                    }
                }
            }
        }
        security-zone WAN {
            interfaces {
                fe-0/0/1.0 {
                    host-inbound-traffic {
                        system-services {
                            ike;                                       ##important to allow IKE
                            ping;
                        }
                    }
                }
            }
        }
        security-zone VPN {
            address-book {
                address 15.15.15.0/24 15.15.15.0/24;
            }
            interfaces {
                st0.0 {
                    host-inbound-traffic {
                        system-services {
                            ike;
                        }
                        protocols {
                            ospf;                                 ## important to allow OSPF
                        }
                    }
                }
            }
        }
    }
}

Tuesday, January 22, 2013

Chapter 8 IPS IDP - same thing for Juniper


One IDP policy per the whole device.
You can have many policies but only ONE is active.

Rulebase   and a rulebase for exempt.


Ok.
One IDP policy can be active only.
That is the start.

Set security idp  active-policy      idp_policy_name

Ok.
That will be the active policy for the whole of the SRX.

Now.
IPS IDP takes resources like CPU and memory.
So you don't want to waste your resources applying it everywhere.
For example.
You don't need it from the LAN to the WAN or similar.

So
Let's say we have a security policy from the WAN to the DMZ.
So there we would like to scan traffic.
Set security policy from zone WAN to zone DMZ  policy  scan_traffic    match xxxxxxx
Set security policy from zone WAN to zone DMZ  policy  scan_traffic    THEN    application-services      idp

So on the traffic from WAN to DMZ    we  tell the SRX to wake up the application-service idp  and scan the traffic.

Now to scan the traffic, it will use the idp .
Since there is only one ACTIVE policy  called   idp_policy_name
 that is the policy it will call up

So to reiterate it.
Policy   has a THEN -->  the THEN will call up   application-services  idp  -->  which will use the active policy --> idp_policy name



Now to configuring the actual active policy.

So let's start with the exempt part.
Set security idp idp-policy    idp_policy_name        rulebase-exempt     

Set security idp idp-policy     idp_policy_name   rulebase-exempt rule 1a match source-address 11.11.11.0/24 

So here we matched up the source-address  of  our  sister company  and exempted them.

We can also be more granular and exempt only specific attacks.
Set security idp idp-policy     idp_policy_name   rulebase-exempt rule 1a match attacks  
attacks {
custom-attacks [ attack-name ];
predefined-attack-groups [ attack-name ];
predefined-attacks [ attack-name ];

So we can set up as many exempts as we want, each one will be a rule
Rule 1a   rule 2a  etc.

Now.
We finished the exempt stuff.
We can move to mark the stuff we WANT to scan.
Set security idp idp-policy     idp_policy_name   rulebase-ips     rule 1a match      from-zone/address/destination etc  attacks(if you want to be granular)

Now the scan here will result in an action which we must do. (in the exempt there was no action)
 THEN
Set security idp idp-policy     idp_policy_name   rulebase-ips     rule 1a then         now we have some options here.

  1. Take ACTION      the normal action is recommended  (which is what the Juniper experts decided)
    1. You can also take  no-action   
    2. You can  drop-packet    -    # this means that If the next packet comes around it will reprocess it.
      this is good for UDP for example. That way you won't get a DDoS on your UDP traffic
      as each UDP could be different.
    3. You can close-client       #  this will send the sender a  RST       an RST basically kills the connection
    4. You can close-server     # this will send the  recipient  a RST
    5. You can close-client-and-client      # this obviously sends that RST to both
    6. You can mark-diffserv            # let's say you want that traffic to get a higher priority on DSCP

Again Juniper recommends the recommended action as the action to take.
Then they will decide what to do based on the attack.

  1. Notification    here you can send it to syslog for example   
  1. Set security idp idp-policy     idp_policy_name   rulebase-ips     rule 1a then    notification          log-attacks

The last big one is   ip-action    and then you can create logs, block that pool or what ever


So we made rules  , we made exempt rules    we  set up the active idp policy      and applied it to the  policy traffic.

Eh Voila.
No.
Sorry.
For IDP/IPS you have to pay an extra license.
The reason is that IPS signatures change over time and different attacks are created by crackers.
So Juniper charges you extra but in exchange you can download the signatures.
This is the same as the border police getting updates on new terrorists or criminals.

So first add the license.
This is done from the operational mode  which is the >  you have before the configure  #   so
  • Request system license add          filename
  • Show system license     will verify you added it.

  • show security idp     security-package-version                                          checks what version you have.
  • Request security idp    security-package  download   check-server      checks what version is available

     
  • Request security idp    security-package  download   full-update       downloads it
  • Request security idp    security-package  download   status                   checks how is the download going?

  • Request security idp    security-package  install            so you donwnload it now you install it
  • Request security idp    security-package  install   status                   checks how is the installation  going?


Ok, remember the recommended thing.  THEN   recommended , you need to update the recommendations too.
This is done by downloading what Juniper calls    templates.
  • Request security idp    security-package  download   policy- templates       downloads templates
  • Request security idp    security-package  download   status                   checks how is the download going?
  • Request security idp    security-package  install  policy- templates       install templates
  • Request security idp    security-package  install   status                   checks how is the installation going?

Ok god.
So add a license
Check to see you have it.

check the version you have
Check the version on the server

Download the full-update
Check the status of the download
Install the full-update
Check the status of the  installation

Download the policy-templates
Check the download
Install the policy-templates
Check the status of the install.


Show security idp status
Show security idp counters
Show security idp memory
Status will show it on
Counters will give you data.
and memory will show you how well the damn SRX is doing, this is good for DDoS.






  

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 :).




Monday, January 21, 2013

Chapter 6 - Nat

NAT

Source NAT :



user@host > show security flow session
Session ID 45454 , policy name   default-permit/4   
In :   192.168.0.10/1739   --->       11.11.11.11/80 tcp    If: ge-0/0/2.0
Out:     11.11.11.11/80    --->        12.12.12.12/5454       if: ge-0/0/3.0

Ok.
So based on the source the SRX will change the IP address of the outgoing flow.

To configure this you can use.
 set security NAT source rule-set 1
          from zone  LAN
         to zone  WAN
     rule 1A
             match   {
                     source-address 0.0.0.0/0
                }
              then {
                 source-nat interface

So very simply this said. Create a NAT source .
Inside it we can have many rules. So we first create the Rule-set which  will house the rules.

The first rule in the rule-set is   rule 1A.
We want to MATCH anything that comes from zone   LAN to WAN.
Those packets will get source-natted.  
The IP that will be placed in the packet will be the one on the outgoing interface (source-nat interface)

So for example.

If the packet goes out interface GE-0/0/0.0   the SRX will place the IP 11.11.11.11
if it goes out the other interface   then it will place the IP 11.11.11.12



Sometimes you want to dictate what IP will be placed in the outgoing packet.
For that you can use an IP pool.
You create an IP pool under the source NAT stanza  and then invoke it in the
source NAT rule-set rule statement.
set security nat source pool A address 11.11.11.13/32

now I can invoke it.
rule-set 1A 
    from zone LAN
    to zone WAN
    rule 1
      match 
       source-address 0.0.0.0/0
     then
             source-nat   pool A

as you can see we simply replaced the interface option with a  POOL called A.


both of the above use PAT.
Port Address translation.
Which means, they will all go out with one IP and each flow will have a different port.

Sometimes though you want to have a Direct NAT. So that the port does not change.
To do that simply configure a pool address that will allocate a new ip to every flow.
Till it runs out of IPs and then it will drop them.
pool B {
       address  {
             11.11.11.1/32 to 11.11.11.254/32       #I set up 254 IPs
             }
             port no-translation

There we are 254 IPs and don't do PAT.
only problem is if we run out of IPs, it will drop the packets   :(((.

To solve the dropped packets you can OVERFLOW.
pool C {
       address  {
             11.11.11.1/32 to 11.11.11.254/32       #I set up 254 IPs
             }
             port no-translation
              overflow-pool  Z
so basically now if I run out of IPs I can use another backup pool.



In general it is a good idea to know if this is happening.
You can set up an alarm to tell you
set security nat source pool-utilization-alarm   raise-threshold 50 clear-threshold 40
so if it reaches   50%  it will send a trap
and when it drops back to 40%  it will send another trap.


Sometimes you might want to be able to match the PUBLIC IP to the LAN IP.
For that you can use address shifting.
pool D {
       address  {
             11.11.11.1/32 to 11.11.11.254/32       #I set up 254 IPs
             }
            host-address-base   192.168.0.1/32
so now
192.168.0.1   will always get ip 11.11.11.11
192.168.0.2    will always get ip  11.11.11.12
etc, etc
The pool sizes should match.

Last thing is an exception.
You can set one up for a sepcific destination   and then turn off the NAT
then {
      source-nat off;
}


OK.
Same thing the other way around
Destination NAT.
Destination NAT will happen before the ZONES , simply because the destination it needs to go to
will affect which zone handles the security.

rule-sets work from a zone.
Set security nat destination pool a   address 192.168.0.1/32


rule-set 1
      from zone WAN
     rule 1A
         match {
                 destination-address  11.11.11.11/32
         }
        then {
                 destination-nat   pool A;

so very simply. In destnation NAT the pool is the LAN host.
 The destination    address in the rule    is the WAN interface
if you get a hit on it then convert it to the LAN one.

Same thing can be done with a pool of IPs.
Set security nat destination pool a   address 192.168.0.1/32 to 192.168.0.100/32

Yo ucan be more granular
and specify a destination port.
This is useful for PAT.
rule-set 1
      from zone WAN
     rule 2A
         match {
                 destination-address  11.11.11.11/32
                  destination-port 80
         }
        then {
                 destination-nat   pool C;

Set security nat destination pool C   address 192.168.0.1/32 port 8080

 so now we added a destination port on the rule    and a destination port on the POOL.





As you noticed each one had ONE direction   either  source or destination.
Instead of writing two rules, if we have a static NAT.
We can write one rule.
set security nat static rule-set R1
           from zone WAN
          rule A  {
                match  {
                      destination-address 11.11.11.11/32
              then {
                      static-nat prefix   192.168.0.1/32

so basically all IP in to 11.11.11.11 will translate and all IP out from 192.168.0.1 will be too.
The reverse is automatically enables.


Now,
You can drop untranslated traffic.
drop-translated;

commands for monitoring.
show security flow session     this will show you the translation if it happened.

show security nat source rule   rule1a           this will show a summary of a rule.
show security nat source pool    this shows info on the pool.
show security nat source summary.   a summary.