JNCIS-SEC

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.

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.

Take ACTION the normal action is recommended (which is what the Juniper experts decided)

You can also take no-action
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.
You can close-client # this will send the sender a RST an RST basically kills the connection
You can close-server # this will send the recipient a RST
You can close-client-and-client # this obviously sends that RST to both
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.

Notification here you can send it to syslog for example

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

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

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.