Tuesday, 10 December 2013

JUNOS : JTAC Recommended Junos Software Versions for SRX - Dec 2013

SRX Series Services Gateways

Platform JTAC Recommended Junos Software by Platform Release
Type
Last
updated
SRX100B/H Junos 11.4R9.4 Standard 25 Sep 2013
SRX100H2 Junos 12.1X44-D20.3 Standard 05 Aug 2013
SRX110H Junos 11.4R9.4 Standard 25 Sep 2013
SRX110H2 Junos 12.1X44-D20.3 Standard 05 Aug 2013
SRX210B/H/BE/HE Junos 11.4R9.4 Standard 25 Sep 2013
SRX210H2 Junos 12.1X44-D20.3 Standard 05 Aug 2013
SRX220H Junos 11.4R9.4 Standard 25 Sep 2013
SRX220H2 Junos 12.1X44-D20.3 Standard 05 Aug 2013
SRX240B/H/B2/H2 Junos 11.4R9.4 Standard 25 Sep 2013
SRX550 Junos 12.1X44-D20.3 Standard 05 Aug 2013
SRX650 Junos 11.4R9.4 Standard 25 Sep 2013
SRX1400 (*1) Junos 11.4R9.4 Standard 25 Sep 2013
SRX3400 Junos 11.4R9.4 Standard 25 Sep 2013
SRX3600 Junos 11.4R9.4 Standard 25 Sep 2013
SRX5600 Junos 11.4R9.4 Standard 25 Sep 2013
SRX5600 w/NG-SPC (*2) Junos 12.1X44-D22 Standard 04 Sep 2013
SRX5800 Junos 11.4R9.4 Standard 25 Sep 2013
SRX5800 w/NG-SPC (*2) Junos 12.1X44-D22 Standard 04 Sep 2013
(*1) SRX 1400 deployment as a Chassis Cluster requires Junos 11.1 or above.
(*2) TSB16197 - Intermittent PHY or MAC layer link failure on SRX5600 and SRX5800 with SRX5K-SPC-4-15-320.

Saturday, 7 December 2013

Configuring a Route-Based VPN

This example uses the following hardware:
  • SRX240 device
  • SSG140 device
Figure 1 shows an example of a route-based VPN topology. In this topology, the SRX Series device is located in Sunnyvale, and an SSG Series device (or a third-party device) is located in Chicago.
Figure 1: Route-Based VPN Topology
 Route-Based VPN Topology
In this example, you configure interfaces, an IPv4 default route, security zones, and address books. Then you configure IKE Phase 1, IPsec Phase 2, security policy, and TCP-MSS parameters. See Table 1 through Table 5 for specific configuration parameters used in this example.
Table 1: Interface, Static Route, Security Zone, and Address Book Information
Feature
Name
Configuration Parameters
Interfaces
ge-0/0/0.0
10.10.10.1/24
 
ge-0/0/3.0
1.1.1.2/30
 
st0.0 (tunnel interface)
10.11.11.10/24
Static routes
0.0.0.0/0 (default route)
The next hop is 1.1.1.1.
 
192.168.168.0/24
The next hop is st0.0.
Security zones
trust
  • All system services are allowed.
  • The ge-0/0/0.0 interface is bound to this zone.
 
untrust
  • IKE is the only allowed system service.
  • The ge-0/0/3.0 interface is bound to this zone.
 
vpn-chicago
The st0.0 interface is bound to this zone.
Address book entries
sunnyvale
  • This address is an entry in the address book book1, which is attached to a zone called trust.
  • The address for this address book entry is 10.10.10.0/24.
 
chicago
  • This address is an entry in the address book book2, which is attached to a zone called vpn-chicago.
  • The address for this address book entry is 192.168.168.0/24.
Table 2: IKE Phase 1 Configuration Parameters
Feature
Name
Configuration Parameters
Proposal
ike-phase1-proposal
  • Authentication method: pre-shared-keys
  • Diffie-Hellman group: group2
  • Authentication algorithm: sha1
  • Encryption algorithm: aes-128-cbc
Policy
ike-phase1-policy
  • Mode: main
  • Proposal reference: ike-phase1-proposal
  • IKE Phase 1 policy authentication method: pre-shared-key ascii-text
Gateway
gw-chicago
  • IKE policy reference: ike-phase1-policy
  • External interface: ge-0/0/3.0
  • Gateway address: 2.2.2.2
Table 3: IPsec Phase 2 Configuration Parameters
Feature
Name
Configuration Parameters
Proposal
ipsec-phase2-proposal
  • Protocol: esp
  • Authentication algorithm: hmac-sha1-96
  • Encryption algorithm: aes-128-cbc
Policy
ipsec-phase2-policy
  • Proposal reference: ipsec-phase2-proposal
  • PFS: Diffie-Hellman group2
VPN
ike-vpn-chicago
  • IKE gateway reference: gw-chicago
  • IPsec policy reference: ipsec-phase2-policy
  • Bind to interface: st0.0
Table 4: Security Policy Configuration Parameters
Purpose
Name
Configuration Parameters
The security policy permits traffic from the trust zone to the vpn-chicago zone.
vpn-tr-chi
  • Match criteria:
    • source-address sunnyvale
    • destination-address chicago
    • application any
  • Action: permit
The security policy permits traffic from the vpn-chicago zone to the trust zone.
vpn-chi-tr
  • Match criteria:
    • source-address chicago
    • destination-address sunnyvale
    • application any
  • Action: permit
Table 5: TCP-MSS Configuration Parameters
Purpose
Configuration Parameters
TCP-MSS is negotiated as part of the TCP three-way handshake and limits the maximum size of a TCP segment to better fit the MTU limits on a network. For VPN traffic, the IPsec encapsulation overhead, along with the IP and frame overhead, can cause the resulting ESP packet to exceed the MTU of the physical interface, which causes fragmentation. Fragmentation increases bandwidth and device resources.
Note: We recommend a value of 1350 as the starting point for most Ethernet-based networks with an MTU of 1500 or greater. You might need to experiment with different TCP-MSS values to obtain optimal performance. For example, you might need to change the value if any device in the path has a lower MTU, or if there is any additional overhead such as PPP or Frame Relay.
MSS value: 1350

Configuration

Configuring Interface, Static Route, Security Zone, and Address Book Information

CLI Quick Configuration

To quickly configure this section of the example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level.
set interfaces ge-0/0/0 unit 0 family inet address 10.10.10.1/24set interfaces ge-0/0/3 unit 0 family inet address 1.1.1.2/30set interfaces st0 unit 0 family inet address 10.11.11.10/24 set routing-options static route 0.0.0.0/0 next-hop 1.1.1.1set routing-options static route 192.168.168.0/24 next-hop st0.0set security zones security-zone untrust interfaces ge-0/0/3.0set security zones security-zone untrust host-inbound-traffic system-services ike set security zones security-zone trust interfaces ge-0/0/0.0set security zones security-zone trust host-inbound-traffic system-services all set security zones security-zone vpn-chicago interfaces st0.0set security address-book book1 address sunnyvale 10.10.10.0/24 set security address-book book1 attach zone trust set security address-book book2 address chicago 192.168.168.0/24 set security address-book book2 attach zone untrust

Step-by-Step Procedure

To configure interface, static route, security zone, and address book information:
  1. Configure Ethernet interface information.
    [edit]user@host# set interfaces ge-0/0/0 unit 0 family inet address 10.10.10.1/24user@host# set interfaces ge-0/0/3 unit 0 family inet address 1.1.1.2/30user@host# set interfaces st0 unit 0 family inet address 10.11.11.10/24
  2. Configure static route information.
    [edit]user@host# set routing-options static route 0.0.0.0/0 next-hop 1.1.1.1user@host# set routing-options static route 192.168.168.0/24 next-hop st0.0
  3. Configure the untrust security zone.
    [edit ]user@host# edit security zones security-zone untrust
  4. Assign an interface to the security zone.
    [edit security zones security-zone untrust]user@host# set interfaces ge-0/0/3.0
  5. Specify allowed system services for the security zone.
    [edit security zones security-zone untrust]user@host# set host-inbound-traffic system-services ike
  6. Configure the trust security zone.
    [edit]user@host# edit security zones security-zone trust
  7. Assign an interface to the trust security zone.
    [edit security zones security-zone trust]user@host# set interfaces ge-0/0/0.0
  8. Specify allowed system services for the trust security zone.
    [edit security zones security-zone trust]user@host# set host-inbound-traffic system-services all
  9. Configure an address book and attach a zone to it.
    [edit security address-book book1]user@host# set address sunnyvale 10.10.10.0/24 user@host# set attach zone trust
  10. Configure the vpn-chicago security zone.
    [edit]user@host# edit security zones security-zone vpn-chicago
  11. Assign an interface to the security zone.
    [edit security zones security-zone vpn-chicago]user@host# set interfaces st0.0
  12. Configure another address book and attach a zone to it.
    [edit security address-book book2]user@host# set address chicago 192.168.168.0/24user@host# set attach zone vpn-chicago

Results

From configuration mode, confirm your configuration by entering the show interfaces, show routing-options, show security zones, and show security address-book commands. If the output does not display the intended configuration, repeat the configuration instructions in this example to correct it.
[edit]user@host# show interfaces
ge-0/0/0 {unit 0 {family inet {address 10.10.10.1/24;}}}
ge-0/0/3 {unit 0 {family inet {address 1.1.1.2/30 }}}
st0{unit 0 {family inet {address 10.11.11.10/24}}}
[edit]user@host# show routing-options
static {route 0.0.0.0/0 next-hop 1.1.1.1;route 192.168.168.0/24 next-hop st0.0;}
[edit]user@host# show security zones
security-zone untrust {host-inbound-traffic {system-services {ike;}}interfaces {ge-0/0/3.0;}}
security-zone trust {host-inbound-traffic {system-services {all;}}interfaces {ge-0/0/0.0;}}
security-zone vpn-chicago {host-inbound-traffic {}interfaces {st0.0;}}
[edit]user@host# show security address-book
book1 {address sunnyvale 10.10.10.0/24;attach {zone trust;}}book2 {address chicago 192.168.168.0/24;attach {zone untrust;}}
If you are done configuring the device, enter commit from configuration mode.

Configuring IKE

CLI Quick Configuration

To quickly configure this section of the example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level.
set security ike proposal ike-phase1-proposal authentication-method pre-shared-keysset security ike proposal ike-phase1-proposal dh-group group2 set security ike proposal ike-phase1-proposal authentication-algorithm sha1 set security ike proposal ike-phase1-proposal encryption-algorithm aes-128-cbc set security ike policy ike-phase1-policy mode main set security ike policy ike-phase1-policy proposals ike-phase1-proposal set security ike policy ike-phase1-policy pre-shared-key ascii-text 395psksecr3t set security ike gateway gw-chicago external-interface ge-0/0/3.0 set security ike gateway gw-chicago ike-policy ike-phase1-policy set security ike gateway gw-chicago address 2.2.2.2

Step-by-Step Procedure

To configure IKE:
  1. Create the IKE Phase 1 proposal.
    [edit security ike]user@host# set proposal ike-phase1-proposal
  2. Define the IKE proposal authentication method.
    [edit security ike proposal ike-phase1-proposal]user@host# set authentication-method pre-shared-keys
  3. Define the IKE proposal Diffie-Hellman group.
    [edit security ike proposal ike-phase1-proposal]user@host# set dh-group group2
  4. Define the IKE proposal authentication algorithm.
    [edit security ike proposal ike-phase1-proposal]user@host# set authentication-algorithm sha1
  5. Define the IKE proposal encryption algorithm.
    [edit security ike proposal ike-phase1-proposal]user@host# set encryption-algorithm aes-128-cbc
  6. Create an IKE Phase 1 policy.
    [edit security ike]user@host# set policy ike-phase1-policy
  7. Set the IKE Phase 1 policy mode.
    [edit security ike policy ike-phase1-policy]user@host# set mode main
  8. Specify a reference to the IKE proposal.
    [edit security ike policy ike-phase1-policy]user@host# set proposals ike-phase1-proposal
  9. Define the IKE Phase 1 policy authentication method.
    [edit security ike policy ike-phase1-policy]user@host# set pre-shared-key ascii-text 395psksecr3t
  10. Create an IKE Phase 1 gateway and define its external interface.
    [edit security ike]user@host# set gateway gw-chicago external-interface ge-0/0/3.0
  11. Define the IKE Phase 1 policy reference.
    [edit security ike gateway gw-chicago]user@host# set ike-policy ike-phase1-policy
  12. Define the IKE Phase 1 gateway address.
    [edit security ike gateway gw-chicago]user@host# set address 2.2.2.2

Results

From configuration mode, confirm your configuration by entering the show security ike command. If the output does not display the intended configuration, repeat the configuration instructions in this example to correct it.
[edit]user@host# show security ike
proposal ike-phase1-proposal {authentication-method pre-shared-keys;dh-group group2;authentication-algorithm sha1;encryption-algorithm aes-128-cbc;}
policy ike-phase1-policy {mode main;proposals ike-phase1-proposal;pre-shared-key ascii-text "$9$9VMTp1RvWLdwYKMJDkmF3ylKM87Vb2oZjws5F"; ## SECRET-DATA}
gateway gw-chicago {ike-policy ike-phase1-policy;address 2.2.2.2;external-interface ge-0/0/3.0;}
If you are done configuring the device, enter commit from configuration mode.

Configuring IPsec

CLI Quick Configuration

To quickly configure this section of the example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level.
set security ipsec proposal ipsec-phase2-proposal protocol espset security ipsec proposal ipsec-phase2-proposal authentication-algorithm hmac-sha1-96 set security ipsec proposal ipsec-phase2-proposal encryption-algorithm aes-128-cbc set security ipsec policy ipsec-phase2-policy proposals ipsec-phase2-proposalset security ipsec policy ipsec-phase2-policy perfect-forward-secrecy keys group2set security ipsec vpn ike-vpn-chicago ike gateway gw-chicagoset security ipsec vpn ike-vpn-chicago ike ipsec-policy ipsec-phase2-policyset security ipsec vpn ike-vpn-chicago bind-interface st0.0

Step-by-Step Procedure


To configure IPsec:
  1. Create an IPsec Phase 2 proposal.
    [edit]user@host# set security ipsec proposal ipsec-phase2-proposal
  2. Specify the IPsec Phase 2 proposal protocol.
    [edit security ipsec proposal ipsec-phase2-proposal]user@host# set protocol esp
  3. Specify the IPsec Phase 2 proposal authentication algorithm.
    [edit security ipsec proposal ipsec-phase2-proposal]user@host# set authentication-algorithm hmac-sha1-96
  4. Specify the IPsec Phase 2 proposal encryption algorithm.
    [edit security ipsec proposal ipsec-phase2-proposal]user@host# set encryption-algorithm aes-128-cbc
  5. Create the IPsec Phase 2 policy.
    [edit security ipsec]user@host# set policy ipsec-phase2-policy
  6. Specify the IPsec Phase 2 proposal reference.
    [edit security ipsec policy ipsec-phase2-policy]user@host# set proposals ipsec-phase2-proposal
  7. Specify IPsec Phase 2 PFS to use Diffie-Hellman group 2.
    [edit security ipsec policy ipsec-phase2-policy]user@host# set perfect-forward-secrecy keys group2
  8. Specify the IKE gateway.
    [edit security ipsec]user@host# set vpn ike-vpn-chicago ike gateway gw-chicago
  9. Specify the IPsec Phase 2 policy.
    [edit security ipsec]user@host# set vpn ike-vpn-chicago ike ipsec-policy ipsec-phase2-policy
  10. Specify the interface to bind.
    [edit security ipsec]user@host# set vpn ike-vpn-chicago bind-interface st0.0

Results

From configuration mode, confirm your configuration by entering the show security ipsec command. If the output does not display the intended configuration, repeat the configuration instructions in this example to correct it.
[edit]user@host# show security ipsec
proposal ipsec-phase2-proposal {protocol esp;authentication-algorithm hmac-sha1-96;encryption-algorithm aes-128-cbc;}
policy ipsec-phase2-policy {perfect-forward-secrecy {keys group2;}proposals ipsec-phase2-proposal;}
vpn ike-vpn-chicago {bind-interface st0.0;ike {gateway gw-chicago;ipsec-policy ipsec-phase2-policy;}}
If you are done configuring the device, enter commit from configuration mode.

Configuring Security Policies

CLI Quick Configuration

To quickly configure this section of the example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level.
set security policies from-zone trust to-zone vpn-chicago policy vpn-tr-chi match source-address sunnyvaleset security policies from-zone trust to-zone vpn-chicago policy vpn-tr-chi match destination-address chicago set security policies from-zone trust to-zone vpn-chicago policy vpn-tr-chi match application any set security policies from-zone trust to-zone vpn-chicago policy vpn-tr-chi then permit set security policies from-zone vpn-chicago to-zone trust policy vpn-chi-tr match source-address chicagoset security policies from-zone vpn-chicago to-zone trust policy vpn-chi-tr match destination-address sunnyvale set security policies from-zone vpn-chicago to-zone trust policy vpn-chi-tr match application any set security policies from-zone vpn-chicago to-zone trust policy vpn-chi-tr then permit

Step-by-Step Procedure

To configure security policies:
  1. Create the security policy to permit traffic from the trust zone to the vpn-chicago zone.
    [edit security policies from-zone trust to-zone vpn-chicago]user@host# set policy vpn-tr-chi match source-address sunnyvaleuser@host# set policy vpn-tr-chi match destination-address chicagouser@host# set policy vpn-tr-chi match application anyuser@host# set policy vpn-tr-chi then permit
  2. Create the security policy to permit traffic from the vpn-chicago zone to the trust zone.
    [edit security policies from-zone vpn-chicago to-zone trust]user@host# set policy vpn-chi-tr match source-address sunnyvaleuser@host# set policy vpn-chi-tr match destination-address chicagouser@host# set policy vpn-chi-tr match application anyuser@host# set policy vpn-chi-tr then permit

Results

From configuration mode, confirm your configuration by entering the show security policies command. If the output does not display the intended configuration, repeat the configuration instructions in this example to correct it.
[edit]user@host# show security policies
from-zone trust to-zone vpn-chicago {policy vpn-tr-vpn {match {source-address sunnyvale; destination-address chicago;application any;}then {permit;}}}
from-zone vpn-chicago to-zone trust {policy vpn-tr-vpn {match {source-address chicago;destination-address sunnyvale;application any;}then {permit;}}}
If you are done configuring the device, enter commit from configuration mode.

Configuring TCP-MSS

CLI Quick Configuration

To quickly configure this section of the example, copy the following command, paste it into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the command into the CLI at the [edit] hierarchy level.
set security flow tcp-mss ipsec-vpn mss 1350

Step-by-Step Procedure


To configure TCP-MSS information:
  1. Configure TCP-MSS information.
    [edit]user@host# set security flow tcp-mss ipsec-vpn mss 1350

Results

From configuration mode, confirm your configuration by entering the show security flow command. If the output does not display the intended configuration, repeat the configuration instructions in this example to correct it.
[edit]user@host# show security flow
tcp-mss {ipsec-vpn {mss 1350;}}
If you are done configuring the device, enter commit from configuration mode.

Configuring the SSG Series Device

CLI Quick Configuration

To quickly configure this section of the example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI.
set zone name vpn-chicagoset interface ethernet0/6 zone Trustset interface ethernet0/0 zone Untrustset interface tunnel.1 zone vpn-chicagoset interface ethernet0/6 ip 192.168.168.1/24set interface ethernet0/6 routeset interface ethernet0/0 ip 2.2.2.2/30set interface ethernet0/0 routeset interface tunnel.1 ip 10.11.11.11/24set flow tcp-mss 1350set address Trust “192.168.168-net” 192.168.168.0 255.255.255.0set address vpn-chicago "10.10.10-net" 10.10.10.0 255.255.255.0set ike gateway corp-ike address 1.1.1.2 Main outgoing-interface ethernet0/0 preshare 395psksecr3t sec-level standardset vpn corp-vpn gateway corp-ike replay tunnel idletime 0 sec-level standardset vpn corp-vpn monitor optimized rekeyset vpn corp-vpn bind interface tunnel.1set policy from Trust to Untrust “ANY” “ANY” “ANY” nat src permitset policy from Trust to vpn-chicago “192.168.168-net” “10.10.10-net” “ANY” permitset policy from vpn-chicago to Trust “10.10.10-net” “192.168.168-net” “ANY” permitset route 10.10.10.0/24 interface tunnel.1set route 0.0.0.0/0 interface ethernet0/0 gateway 2.2.2.1

Monday, 18 November 2013

Junos : Copy/Paste Configuration

Copying and Pasting a Configuration Section to Another Configuration

If you have a section of a configuration that you want include in another configuration, you can use the load merge terminal relative command to copy the configuration section from a file or an application window (for example, a Web browser) and paste the section in the CLI of the terminal window that you are using to configure a device.

To copy and paste a section of a configuration to another configuration:
  1. In the terminal window, navigate to the specific hierarchy where the data will be pasted (in this example, the system hierarchy).

  2. user@host# edit system
    [edit system]


  3. Enter the load merge terminal relative command:

  4. user@host# load merge terminal relative
    [Type ^D at a new line to end input]


  5. Copy the section of the configuration from a file or an application window.

  6. Paste the copied text into the CLI of the terminal window that you are using to configure the device.
  7. user@host# load merge terminal relative
    [Type ^D at a new line to end input]
    location building 2;
    ntp server 78.46.194.186 version 4;
  8. Press Enter once. Make sure that you perform this step before proceeding.

  9. Press Ctrl+d to indicate that the end of the pasted text. You see "load complete" in the terminal window.

  10. To verify the configuration but not activate it, use the show command. You can also use the commit check command to verify the correctness of the syntax for the commands that have been entered.

  11. If the validation is successful, go to the next step. Otherwise, review any error messages and use the CLI to change the configuration and resolve errors.

  12. Commit the configuration to activate it:

  13. user@host# commit
    commit complete

Sunday, 10 November 2013

Junos : Configuring Basic Settings with the CLI

Configuring Basic Settings with the CLI

In CLI configuration mode, you use the set command to enable features, and the delete command to disable them. The commands you enter do not update the active configuration on the router until you use the commit command.
To configure basic settings with the CLI:
  1. From the CLI, enter configuration mode:
      root> configure
      root#
  2. Set the IP addresses of the built-in Ethernet ports. For example:
      root# set interfaces ge-0/0/0 unit 0 family inet address 1.1.2.31/24
      root# set interfaces ge-0/0/1 unit 0 family inet address 1.6.2.1/24
      root# set interfaces ge-0/0/2 unit 0 family inet address 2.8.3.1/24
      root# set interfaces ge-0/0/3 unit 0 family inet address 9.1.4.1/24
    The unit number is the logical interface number. IP addresses are configured on the logical interface. Setting the protocol family to inet specifies the routing table of IPv4 addresses.
  3. Set a default route (default gateway) for IPv4 packets. For example:
      root# set routing-options static route 1.6.2.1/24 next-hop 10.1.1.50
  4. Configure one or more static routes:
      root# set routing-options static route destination-prefix next-hop address
  5. Set the hostname. For example:
      root# set system host-name Chicago
  6. Save your configuration settings and activate them on the Services Router:
      root# commit

Tuesday, 5 November 2013

Junos : ALG

JUNOS Software supports voice-over-IP Application Layer Gateways (VoIP ALGs) and basic data ALGs. (Note that supported ALG types vary depending on which hardware device you are using.)
VoIP ALGs provide stateful Application Layer inspection and Network Address Translation (NAT) capabilities to VoIP signaling and media traffic. The ALG inspects the state of transactions, or calls, and forwards or drops packets based on those states.
JUNOS Software supports the following VoIP ALGs:
  • H.323—The H.323 ALG provides support for the H.323 legacy VoIP protocol. The ALG lets you secure VoIP communication between terminal hosts, such as IP phones and multimedia devices. In such a telephony system, the gatekeeper device manages call registration, admission, and call status for VoIP calls. Gatekeepers can reside in the two different zones or in the same zone.
  • SIP—The SIP ALG provides support for the Session Initiation Protocol (SIP). SIP is an Internet Engineering Task Force (IETF)-standard protocol for initiating, modifying, and terminating multimedia sessions over the Internet. Such sessions might include conferencing, telephony, or multimedia, with features such as instant messaging and application-level mobility in network environments.
  • SCCP—The SCCP ALG provides support for Skinny Client Control Protocol (SCCP). SCCP is a Cisco proprietary protocol for call signaling. Skinny is based on a call-agent-based call-control architecture. The control protocol uses binary-coded frames encoded on TCP frames sent to well-known TCP port number destinations to set up and tear down RTP media sessions.
  • MGCP—The MGCP ALG provides support for Media Gateway Control Protocol (MGCP). MGCP is a text-based Application Layer protocol used for call setup and call control between the media gateway and the media gateway controller (MGC). .
JUNOS Software also supports the following data ALGs:
  • DNS—Provides an ALG for the Domain Name System. The DNS ALG monitors DNS query and reply packets and closes session if the DNS flag indicates the packet is a reply message.
  • FTP—Provides an ALG for the File Transfer Protocol (FTP).The FTP ALG monitors PORT, PASV, and 227 commands. It performs NAT on the IP, port, or both in the message and gate opening on the device as necessary. The FTP ALG supports FTP put and FTP get command blocking. When the FTP_NO_PUT or FTP_NO_GET command is set in the policy, the FTP ALG sends back a blocking command and closes the associated opened gate when the FTP STOR or FTP RETR command is observed.
  • TFTP—Provides an ALG for the Trivial File Transfer Protocol (TFTP). The TFTP ALG processes TFTP packets that initiate the request and opens a gate to allow return packets from the reverse direction to the port that sends the request.
  • PPTP—Provides an ALG for the Point-to-Point Tunneling Protocol (PPTP). The PPTP is a Layer 2 protocol that tunnels PPP data across TCP/IP networks. The PPTP client is freely available on Windows systems and is widely deployed for building Virtual Private Networks (VPNs).
  • REAL—Provides an ALG for the Real-Time Streaming Protocol.
  • MSRPC—Provides an ALG for the Microsoft Remote Procedure Call.
  • SUNRPC—Provides an ALG for the SUN Remote Procedure Call.
  • RSH—Provides an ALG for the Remote Shell (RSH). The RSH ALG handles TCP packets destined for port 514 and processes the RSH port command. The RSH ALG performs NAT on the port in the port command and opens gates as necessary.
  • SQL—Provides an ALG for the Structured Query Language (SQL). The SQLNET ALG processes SQL TNS response frame from the server side. It parses the packet and looks for the (HOST=ipaddress), (PORT=port) pattern and performs NAT and gate opening on the client side for the TCP data channel.
  • TALK—Provides an ALG for the TALK Protocol. The TALK protocol uses UDP port 517 and port 518 for control channel connections. The talk program consists of a server and a client. The server handles client notifications and helps to establish talk sessions. There are two types of talk servers: ntalk and talkd. The TALK ALG processes packets of both ntalk and talkd formats. It also performs NAT and gate opening as necessary.

Sunday, 27 October 2013

JUNOS : Configuring Layer 2 Logical Interfaces

J-Web Configuration

To configure a Layer 2 logical interface as a trunk port:
  1. Select Configure>CLI Tools>Point and Click CLI.
  2. Next to Interfaces, click Configure or Edit.
  3. In the Interface name column, select ge-3/0/0.
  4. Under Unit, in the Interface unit number column, click 0.
  5. Next to Family group, select Bridge and then click Configure.
  6. Next to Interface mode, select trunk.
  7. Next to Vlan list, select Vlan id list.
  8. In the Vlan id box, type 1–10.
  9. Click OK to return to the Family page.
  10. Click OK to return to the Unit page.
  11. Click OK to return to the Interface page.
  12. Click OK to return to the Interfaces page.
To configure a VLAN ID for untagged packets received on a physical interface:
  1. Select Configure>CLI Tools>Point and Click CLI.
  2. Next to Interfaces, click Configure or Edit.
  3. In the Interface name column, select ge-3/0/0.
  4. In the Native vlan id box, type 10.
  5. Next to Vlan tag mode, select Vlan tagging.
  6. Click OK to return to the Interfaces page.

CLI Configuration

To configure a Layer 2 logical interface as a trunk port:
user@host# set interfaces ge-3/0/0 unit 0 family bridge interface-mode trunk vlan-id-list 1–10
To configure a VLAN identifier for untagged packets received on a physical interface:
user@host# set interfaces ge-3/0/0 vlan-tagging native-vlan-id 10

Saturday, 19 October 2013

JUNOS: Features and Benefits

JUNOS software helps customers in specific, measurable ways to improve the availability and delivery of services, to reduce operations effort and errors, and to meet new business needs — with a long list of distinct attributes that set it apart from other network operating systems.
JUNOS Software Advantage JUNOS Software Attributes
Continuous Systems
Improve the availability, performance and security of services
  • Fault-tolerant modularity - enhances software stability and uptime with independent operation and restart of modules.
  • Dedicated resources for routing and packet forwarding - provide predictable performance as new services are activated and with a command-line interface (CLI) that doesn't lock-up.
  • High availability features - preserve forwarding and routing operations during device events with non-stop forwarding, Graceful Routing Engine Switchover, non-stop routing, etc.
  • Single release train - enables the development control and extensive regression testing that underlie the software stability.
  • Secure Operating System - protects with secure administration and advanced security features, including Stateful firewall, VPNs, etc. that deliver high throughput with many activated policies.
  • Automated operations (see row below) - prevent human errors and provide proactive measures to reduce the total number, severity and duration of events.
Automated Operations
Reduce operations effort and errors
  • Single implementation of each feature - provides a common user experience regardless of platform to simplify deployment and training.
  • Error-resilient configuration - prevents incomplete or incorrect configurations from becoming active in the network.
  • On-box, custom commit scripts - ensure that configurations are error-free and in compliance to each organization's policies to prevent outages and security vulnerabilities caused by human error.
  • On-box, custom operation (op) scripts and event policies - automate finding and proactively resolving issues from the first, leading indicators to reduce the number, severity and duration of events.
  • Single release train - removes significant risk and effort from network upgrades.
Flexible Innovation
Meet new business needs
  • Session Resource and Control portfolio and Open IP Service Creation Program - extend policy and control to applications and other systems to deliver a rich set of IP services.
  • NETCONF/XML interfaces - support flexible integration to management and operations systems.
  • JUNOScope IP Service Manager 413 KB and J-Web 86 KB provide central and web-based management of JUNOS-based platforms.
  • Systematic development process - predictably provides many new features each quarter to protect investment by meeting new service needs.

Friday, 11 October 2013

Google Malaysia Been Cracked.

Today 11 Oct 2013, 9:00 am Google Malaysia web site ( www.google.com.my) by cracked.

Sunday, 6 October 2013

Junos : Local Web filtering

To configure local Web filtering using the CLI, you must first create your custom objects.
  1. Configure a URL pattern list custom object by creating the list name and adding values to it as follows:
    Note: Because you use URL pattern lists to create custom URL category lists, you must configure URL pattern list custom objects before you configure custom URL category lists. The URL and IP address is added in this example.
    user@host# set security utm custom-objects url-pattern urllist3 value [http://www.juniper.net 1.2.3.4]
    user@host# set security utm custom-objects url-pattern urllist4 value [http://www.acmegizmo.com 1.2.3.4]
    Note: URL pattern wildcard support—The wildcard rule is as follows: \*\.[]\?* and you must precede all wildcard URLs with http://. You can only use “*” if it is at the beginning of the URL and is followed by a “.”. You can only use “?” at the end of the URL.
    The following wildcard syntax is supported: http://*.juniper.net, http://www.juniper.ne?, http://www.juniper.n??. The following wildcard syntax is NOT supported: *.juniper.net , www.juniper.ne?, http://*juniper.net, http://*.
  1. Configure a custom URL category list custom object by using the URL pattern list you created as follows:
    user@host# set security utm custom-objects custom-url-category custurl3 value urllist3
    user@host# set security utm custom-objects custom-url-category custurl4 value urllist4
Now that your custom objects have been created, you can configure the juniper-local Web filtering feature profile.
  1. If you are using included global whitelist and blacklist categories, select those global categories. This is the first filtering category that both integrated, redirect, and local Web filtering use. If no match is made, the configured default fallback action is performed. 
  2. user@host# set security utm feature-profile web-filtering url-blacklist custurl3
    user@host# set security utm feature-profile web-filtering url-whitelist custurl4
  3. Select juniper-local as your Web filtering engine as follows:
    user@host# set security utm feature-profile web-filtering type juniper-local
  4. Create a juniper-local profile by first creating a profile with a default action (permit, log and permit, block) for requests that experience errors as follows:
    user@host# set security utm feature-profile web-filtering juniper–local profile localprofile1 default permit
  5. Enter a custom message to be sent when HTTP requests are blocked.
    user@host# set security utm feature-profile web-filtering juniper-local profile localprofile1 custom-block-message “Access to this site is not permitted”
  6. Select fallback settings (block or log and permit) for this profile. The fallback actions are taken when errors in each configured category occur.
    user@host# set security utm feature-profile web-filtering juniper–local profile localprofile1 fallback-settings default block
    user@host# set security utm feature-profile web-filtering juniper–local profile localprofile1 fallback-settings too-many-requests block
  1. Configure a UTM policy for the Web filtering protocol and attach this policy to a profile. CLI commands for configuring a UTM policy for HTTP Web filtering, and attaching that policy to a profile you created earlier for content filtering are:
    user@host# set security utm utm-policy utmp5 web-filtering http-profile localprofile1
  2. Attach the UTM policy to a firewall security policy.
    user@host# set security policies from-zone trust to-zone untrust policy p5 match source-address any
    user@host# set security policies from-zone trust to-zone untrust policy p5 match destination-address any
    user@host# set security policies from-zone trust to-zone untrust policy p5 match application junos-http
    user@host# set security policies from-zone trust to-zone untrust policy p5 then permit application-services utm-policy utmp5

Tuesday, 24 September 2013

JTAC Recommended Junos Software Versions for SRX and M Series- Sep 2013

SRX Series Services Gateways

Platform JTAC Recommended Junos Software by Platform Release
Type
Last
updated
SRX100B/H Junos 11.4R7.5 Standard 8 April 2013
SRX100H2 Junos 12.1X44-D20.3 Standard 5 August 2013
SRX110H Junos 11.4R7.5 Standard 8 April 2013
SRX110H2 Junos 12.1X44-D20.3 Standard 5 August 2013
SRX210B/H/BE/HE Junos 11.4R7.5 Standard 8 April 2013
SRX210H2 Junos 12.1X44-D20.3 Standard 5 August 2013
SRX220H Junos 11.4R7.5 Standard 8 April 2013
SRX220H2 Junos 12.1X44-D20.3 Standard 5 August 2013
SRX240B/H/B2/H2 Junos 11.4R7.5 Standard 8 April 2013
SRX550 Junos 12.1X44-D20.3 Standard 5 August 2013
SRX650 Junos 11.4R7.5 Standard 8 April 2013
SRX1400 (*1) Junos 11.4R7.5 Standard 8 April 2013
SRX3400 Junos 11.4R7.5 Standard 8 April 2013
SRX3600 Junos 11.4R7.5 Standard 8 April 2013
SRX5600 Junos 11.4R7.5 Standard 8 April 2013
SRX5600 w/NG-SPC (*2) Junos 12.1X44-D22 Standard 4 September 2013
SRX5800 Junos 11.4R7.5 Standard 8 April 2013
SRX5800 w/NG-SPC (*2) Junos 12.1X44-D22 Standard 4 September 2013
(*1) SRX 1400 deployment as a Chassis Cluster requires Junos 11.1 or above.
(*2) TSB16197 - Intermittent PHY or MAC layer link failure on SRX5600 and SRX5800 with SRX5K-SPC-4-15-320.


M, T and MX Series Routers

Platform JTAC Recommended Junos Software by Platform Release
Type
Last
updated
M Series Junos 11.4R7.5 Standard 15 March 2013
T Series Junos 11.4R7.5 Standard 15 March 2013
MX Series Junos 11.4R7.5 Standard 15 March 2013
MX Series with Enhanced SCB Junos 11.4R7.5 Standard 15 March 2013
MX5, MX10, MX40 Series Junos 11.4R7.5 Standard 15 March 2013


Sunday, 15 September 2013

JUNOS : Configure Antivirus Full File-Based Scanning

Setting Up Automatic Updates

By default, the antivirus pattern database is configured to automatically update once every 60 minutes.  You also can specify the email notification sent to the administrator when the pattern update is complete.
  1. Configure the pattern-updates at a different interval for the Kaspersky scan engine.
user@host# set security utm feature-profile anti-virus kaspersky-lab-engine pattern-update url http://update.juniper-updates.net/AV/SRX240
user@host#
set security utm feature-profile anti-virus kaspersky-lab-engine pattern-update interval 120
Note: "SRX240” in the URL is the platform name. This part of the URL is different and platform specific for each platform. (Other than the platform name, you should not change this URL unless you are experiencing problems with it and have called for support.)
Alternately, you can configure the pattern update manually by entering the following operational command:
user@host> request security utm anti-virus kaspersky-lab-engine pattern-update
  1. Define the pattern-update email.
user@host# set security utm feature-profile anti-virus kaspersky-lab-engine pattern-update email-notify admin-email "admin@juniper.net"
user@host# set security utm feature-profile anti-virus kaspersky-lab-engine pattern-update email-notify custom-message "Pattern UPDATE Done"
user@host#
set security utm feature-profile anti-virus kaspersky-lab-engine pattern-update email-notify custom-message-subject "AV UPDATE COMPLETE"

CLI Configuration

To activate full file-based antivirus using the default antivirus profile:
  1. Define what scan engine you are going to use (in this example, Kaspersky Lab engine).
user@host# set security utm feature-profile anti-virus type kaspersky-lab-engine
  1. Define the UTM policy for the HTTP protocol to be scanned with the full file-based default profile.
user@host# set security utm utm-policy custom-utm-policy anti-virus http-profile junos-av-defaults
Note:  A separate anti-virus profile is needed for each protocol.  The available protocols include HTTP, SMTP, POP3, and IMAP.
  1. Apply the UTM policy to a security policy (in this example, security policy called web-access).
user@host# set security policies from-zone trust to-zone untrust policy web-access then permit application-services utm-policy custom-utm-policy

Sunday, 8 September 2013

Juniper SRX vs ScreenOS


The Juniper family of SRX services gateways are the replacement platforms for the SSG platforms, the ISG 1000 and
ISG 2000 as well as the NS 5000 Series (NS-5200 and NS-5400). The SRX family include a set of branch platforms
(SRX210, SRX240 and SRX650), and the high end platforms (SRX3000 and SRX5000).
The entire line of SRX platforms uses JUNOS, a very powerful networking platform that consolidates switching, routing,
security and applications into a single OS. JUNOS is very different than ScreenOS and as such, will place a significant
migration burden on Juniper, their customers and their partners.
Key points to consider:
The SRX Is not positioned as a firewall.
JUNOS is not a security OS and the SRX positioning reflects this based on the routing and switching emphasis
which Juniper uses as a means to compete with Cisco. Withthe SRX, security is merely a service that is enabled
along with switching. Juniper does not try to address the problem of the lack of innovation at the firewall which
resulted in the loss of visibility and control over applications, users and content.

Application visibility and control belongs in the firewall and the port based SRX platforms cannot deliver that
functionality.
Juniper has taken the Cisco approach to say they can do what we do using multiple devices (SRX with IDP, UAC
Controller, a UAC agent on every desktop and multiple management components). Even with this “everything-but-
the-kitchen-sink” approach, they cannot address the visibility and control (applications, users and content) problem.

Stuck on old technology
The SRX uses stateful inspection which relies on port and protocol for policy decisions, a technique that is ineffective
at controlling applications that use dynamic ports, encryption, or tunnel across often used/allowed ports to bypass
firewalls.
Full IDP is supported, and can block a very limited set of, mostly bad applications like
P2P and IM – currently at 126, an incremental improvement over the 118 from April 2007.
The threat focused approach is inadequate in detecting and positively enabling applications.
Applications are not threats. They should not be treated as such.
loading...