Friday, May 11, 2018

Policy-based VPN between Juniper SRX and Cisco ASA

ılılılı RouteXP ılılılı ılılılı
Policy-based VPN between Juniper SRX and Cisco ASA

One of the things that I am called upon to do fairly often in my current role is to configure remote access VPN devices for some site or another.  Often these sites are transient in nature, only staying active for weeks or months at the longest before disappearing forever–or at least until I don’t care any more.

Because I spend a fair amount of time setting these VPN tunnels up, I have gotten fairly good at the ins and outs of IPsec VPN tunnel configuration and troubleshooting.  I was even beginning to think of myself as a bit of a VPN whisperer.  That was about to change, however.

We use Cisco’s ASA product line everywhere for this type of thing, and as many of you no doubt know, if you use one vendor’s product for VPN tunnels you are generally in a good position.  You’ll likely still have problems from time to time–just enough to keep you honest–but it works itself out.  This is the model we’d been following for several years.  Until now.

For reasons passing interest here, we made the decision to start exploring the use of Juniper’s SRX product line for our remote, transient tunnel destinations and smaller offices.  We were not–and are not–prepared to rip-and-replace our entire ASA installed base, though, so these Juniper devices would have to integrate with the existing infrastructure.  This, as they say, is when the proverbial excrement hit the fan.

As anyone who deals in these things knows, mixing vendors on either side of a VPN tunnel is generally a recipe for trouble.  Depending on vendors, your troubles range from the “few drinks after work” type to the “move to Mexico and open a beach bar” kind.  I had heard from many people that I trust that the SRX to ASA configuration was this latter type.

Juniper SRX devices prefer a type of VPN tunnel known as a route-based VPN.  I’m not going to go into specifics here, but suffice it to say it’s a technique that makes sense and a lot of vendors work this way.  Cisco’s ASA, on the other hand, prefers a type of VPN tunnel known as policy-based.  Policy-based VPNs have some limitations and seem to be favored mostly by Cisco and anyone who wants to integrate with Cisco.  

I had to make things work without changing much on the HQ side (where the Corporate ASA units sit) outside of what we normally do, so that meant that the SRX at the remote site needed to be configured in a policy-based way.

The process I followed went something like this:
  • Spend a couple of days learning the Juniper SRX syntax.  This part was actually kind of fun.
  • Spend 5 minutes configuring new tunnel on corporate ASA.
  • Spend 3+ days trying to get Juniper to talk to ASA.  Spend only slightly more time configuring as banging head on desk.
  • Spend 5.5 hours spread over two more days with jTAC.  Bang head more while they can’t figure it out either.
  • Go home, relax, have eureka moment, race back to office, make one-line change, FIX EVERYTHING!
  • Go back home and drink.

As it turns out, the problem can best be described as something that every Cisco Engineer learns in infancy: Cisco is consistently inconsistent.  For example, when the ASA refers to SHA, do you suppose it’s refering to the old SHA-0 or the SHA-1 that corrected a flaw in the old SHA-0?  Dunno.  Since they, in some places, only say “SHA” and in others “SHA-1″ it’s anybody’s guess, really.

The main thing I re-learned from this experience is that the defaults–the little timers, identities, and various other little bits–that make up a successful negotiation for an IPsec tunnel are different across platforms.  Sometimes you really have to search to find what they’re called.  Sometimes you have to bang your head on the desk for a few days.

One more thing: this post was typed up quickly, with no editing, and way too much coffee.  If I’ve overlooked things, gotten things wrong, or just confused you more, I apologize and I’ll try to come back and clean it up later.  In the mean time, hopefully the diagram and configurations below will help you in your own quest to get a policy-based VPN configured between the SRX and ASA.

Oh, and as soon as I recover from this experience I’ll build out a configuration to do a route-based example, which looks to only require a couple of changes on the SRX side and a tad more tweaking perhaps on the ASA side.

Fig 1.1- Policy based VPN 


crypto map outside_map 1 match address outside_cryptomap_3
crypto map outside_map 1 set connection-type bi-directional
crypto map outside_map 1 set peer
crypto map outside_map 1 set ikev1 phase1-mode main
crypto map outside_map 1 set ikev1 transform-set ESP-AES-256-SHA
crypto map outside_map 1 set reverse-route
crypto map outside_map interface outside
crypto ipsec ikev1 transform-set ESP-AES-256-SHA esp-aes-256 esp-sha-hmac
crypto ipsec security-association lifetime seconds 28800
crypto ipsec security-association lifetime kilobytes 4608000
crypto ipsec security-association replay window-size 64
crypto ipsec fragmentation before-encryption outside
crypto ipsec fragmentation before-encryption inside
crypto ipsec df-bit copy-df outside
crypto ipsec df-bit copy-df inside
crypto ikev1 enable outside
crypto ikev1 policy 4
 authentication pre-share
 encryption aes-256
 hash sha
 group 2
 lifetime 28800

nat (inside,outside) source static CISCO_NETWORK CISCO_NETWORK destination static JUNIPER_NETWORK JUNIPER_NETWORK no-proxy-arp
object network CISCO_NETWORK
 description Cisco Network
object network JUNIPER_NETWORK
 description Juniper Network


proposal ike-policy1 {
 authentication-method pre-shared-keys;
 dh-group group2;
 authentication-algorithm sha1;
 encryption-algorithm aes-256-cbc;
 lifetime-seconds 28800;
policy ike-policy1 {
 mode main;
 proposals ike-policy1;
 pre-shared-key ascii-text "$%#@!!!"; ## SECRET-DATA
gateway ike-gate {
 ike-policy ike-policy1;
 local-identity inet;
 external-interface fe-0/0/0;
 protocol esp;
 authentication-algorithm hmac-sha1-96;
 encryption-algorithm aes-256-cbc;
 lifetime-seconds 28800;
 proposals IPSEC_PROPOSAL;
vpn ike-vpn {
 ike {
 gateway ike-gate;
 inactive: proxy-identity {
 service any;
 ipsec-policy IPSEC_POLICY;
 establish-tunnels immediately;
source {
 rule-set trust-to-untrust {
 from zone trust;
 to zone untrust;
 rule nonat {
 match {
 then {
 source-nat {
 rule ZZZ {
 match {
 then {
 source-nat {

Dynamic ARP Inspection

ılılılı RouteXP ılılılı ılılılı
Dynamic ARP Inspection

This article is for the Security or for the routing and switching CCNA/CCNP students who wants to understand about the ARP inspection feature. Let's talk about the Dynamic ARP inspection feature.

Dynamic ARP Inspection (DAI) is a security feature that validates Address Resolution Protocol (ARP) packets in a network. DAI allows a network administrator to intercept, log, and discard ARP packets with invalid MAC address to IP address bindings. This capability protects the network from certain "man-in-the-middle" attacks. 

Fig-1.1- Dynamic ARP inspection

ARP Cache Poisoning:
You may attack hosts, switches, and routers connected on your Layer 2 network by using "poisoning" their ARP caches. as an instance, a malicious person might intercept site visitors meant for different hosts at the subnet by using poisoning the ARP caches of structures linked to the subnet.

Consider the following configuration: 

Fig 1.1 ARP Cache Poisoning ( NB)
Fig 1.2 ARP Cache Poisoning ( NB)
Hosts HA, HB, and HC are connected to the switch on interfaces A, B and C, all of which are on the same subnet. Their IP and MAC addresses are shown in parentheses; for example, Host HA uses IP address IA and MAC address MA. When HA needs to communicate to HB at the IP Layer, HA broadcasts an ARP request for the MAC address associated with IB. As soon as HB receives the ARP request, the ARP cache on HB is populated with an ARP binding for a host with the IP address IA and a MAC address MA; for example, IP address IA is bound to MAC address MA. When HB responds, the ARP cache on HA is populated with a binding for a host with the IP address IB and a MAC address MB. 

Host HC can "poison" the ARP caches of HA and HB by broadcasting forged ARP responses with bindings for a host with an IP address of IA (or IB) and a MAC address of MC. Hosts with poisoned ARP caches use the MAC address MC as the destination MAC address for traffic intended for IA or IB. This means that HC intercepts that traffic. Because HC knows the true MAC addresses associated with IA and IB, HC can forward the intercepted traffic to those hosts using the correct MAC address as the destination. HC has inserted itself into the traffic stream from HA to HB, the classic "man in the middle" attack.

Dynamic ARP Inspection 
To prevent ARP poisoning assaults consisting of the only described inside the previous section, a switch should ensure that simplest legitimate ARP requests and responses are relayed. DAI prevents these assaults via intercepting all ARP requests and responses. every of these intercepted packets is tested for legitimate MAC deal with to IP deal with bindings before the nearby ARP cache is updated or the packet is forwarded to the best vacation spot. Invalid ARP packets are dropped. 

DAI determines the validity of an ARP packet primarily based on legitimate MAC address to IP address bindings saved in a relied on database. This database is built at runtime with the aid of DHCP snooping, supplied that it's far enabled at the VLANs and at the switch in query. similarly, DAI can also validate ARP packets in opposition to person-configured ARP ACLs in an effort to take care of hosts that use statically configured IP addresses. 

DAI can also be configured to drop ARP packets whilst the IP addresses within the packet are invalid or whilst the MAC addresses in the body of the ARP packet do not healthy the addresses certain within the Ethernet header.

Interface Trust state, Security Coverage and Network Configuration 
DAI associates a trust state with each interface on the system. Packets arriving on trusted interfaces bypass all DAI validation checks, while those arriving on untrusted interfaces go through the DAI validation process. In a typical network configuration for DAI, all ports connected to host ports are configured as untrusted, while all ports connected to switches are configured as trusted. With this configuration, all ARP packets entering the network from a given switch will have passed the security check; it is unnecessary to perform a validation at any other place in the VLAN / network: 

Fig 1.2 Validation of ARP Packets on a DAI-enabled VLAN
Fig 1.3 Validation of ARP Packets on a DAI-enabled VLAN 
Configuring interfaces as untrusted when they need to be trusted can result in a lack of connectivity. If we expect that both S1 and S2  run DAI on the VLAN that holds H1 and H2, and if H1 and H2 have been to gather their IP addresses from S1, then only S2 binds the IP to MAC address of H1. therefore, if the interface among S1 and S2 is untrusted, the ARP packets from H1 get dropped on S2. This circumstance would bring about a loss of connectivity between H1 and H2. 

Configuring interfaces to be trusted while they're definitely untrusted leaves a safety hollow in the network. If S1 were now not walking DAI, then H1 can easily poison the ARP of S2 (and H2, if the inter- transfer link is configured as relied on). This condition can arise despite the fact that S2 is strolling DAI. 

DAI guarantees that hosts (on untrusted interfaces) related to a transfer running DAI do now not poison the ARP caches of other hosts inside the community. It does now not, however, make sure that hosts from different quantities of the network do not poison the caches of the hosts linked to it. 

 To deal with instances wherein some switches in a VLAN run DAI and different switches do now not, the interfaces connecting such switches must be configured as untrusted. To validate the bindings of packets from non-DAI switches, but, the transfer walking DAI need to be configured with ARP ACLs. whilst it isn't feasible to determine such bindings, switches strolling DAI must be remote from non-DAI switches at Layer 3.Relative priority of Static Bindings and DHCP Snooping Entries  

As noted previously, DAI populates its database of legitimate MAC address to IP address bindings via DHCP snooping. It additionally validates ARP packets against statically configured ARP ACLs. it's far crucial to note that ARP ACLs have priority over entries inside the DHCP snooping database. ARP Packets are first compared to consumer-configured ARP ACLs. If the ARP ACL denies the ARP packet, then the packet might be denied despite the fact that a valid binding exists in the database populated by means of DHCP snooping.

Cisco Certifications, jobs and Career Path

ılılılı RouteXP ılılılı ılılılı
Cisco Certifications, jobs and Career Path

The widely respected IT certification programs available through Cisco Career Certifications bring valuable, measurable rewards to networking professionals, to their managers, and to the organizations that employ them. Choose a career path below that meets your goals for professional and financial rewards.

Cisco Certifications
If we are talking about the Cisco certifications, we have the following Cisco certifications.

Entry Level Cisco Certifications:-
CCENT and CCE: these are the basics cisco certifications to enter in the field of IT/Telecom networking.

Associate Level Cisco Certifications:-
The below certifications which are for associate professional are widely accepted in many countries according to the jobs and career path growth.

Freshers can start their journey with this certifications which as per market standards you can earn from 2-3 lacs/annum with this certification. Exceptions are always there which high skilled people with the CCNA certification with more salary package.

If have the experience of 1-4 years and you are associate certified Cisco professional with strong basic knowledge, they you can earn upto 6 lacs/annum in the country like India, but make sure you have strong associate skills to understand the traffic flow on packet level.

Cisco certification list
CCNA Cloud
CCNA Collaboration
CCNA Data Center
CCNA Industrial
CCNA Routing and Switching
CCNA Security
CCNA Service Provider
CCNA Wireless

Cisco certifications cost for associate level is : 290$

I highly recommended if you have more than 4 years of experience in the Telecom industry, please don't stop with the associate certifications, go with the Cisco professional certifications further. 

Note: Experience with more than 4 years can further go with the Professional Certifications.

Professional Courses:-
The below certifications which are for professional candidates and are widely accepted in many countries according to the jobs and career path growth.

If you have the experience of 5-7 years and you are Professional certified Cisco professional with strong basic knowledge, they you can earn upto 12 lacs/annum in the country like India, but make sure you have strong basics skills to understand the traffic flow on packet level as well and the more mature role with the wider forum.

Cisco certification list
CCNP Cloud
CCNP Collaboration
CCNP Data Center
CCNP Routing and Switching
CCNP Security
CCNP Service Provider
CCNP Wireless

Cisco certifications cost for professional level is : 250$ per exam

Note: Experience with more than 8-10 years can further go with the Expert Certifications.

Expert Courses:-
The below certifications which are for Expert candidates and are widely accepted in many countries according to the jobs and career path growth.

If you have the experience more than 10 years and you are Expert certified Cisco professional with strong basic knowledge, they you can earn upto 20-24 lacs/annum in the country like India, but make sure you have strong basics skills to understand the traffic flow on packet level as well and also have the understanding about the live network with the troubleshooting skills.

Cisco certification list
CCIE Collaboration
CCIE Data Center
CCIE Routing and Switching
CCIE Security
CCIE Service Provider
CCIE Wireless

Cisco certifications cost for professional level is : 400$ Written and 1600$ LAB

Note: Experience with more than 10-15 years can further go with multiple CCIE Certifications or CCDE certifications to understand the design role.

At least you can try the CCAr certification, if you have much money to invest :) 


Cisco certification Salary
CCNA Certifications: 1-4 years of Exp in Telecom/IT company can earn upto 4-6 lacs/annum
CCNP Certifications: 5-7 years of Exp in Telecom/IT Company can earn upto 7-12 lacs/annum
CCIE Certifications: 10 years of exp in Telecom/IT company can earn maximum of 14-16 lacs/annum
Dual CCIE: 12-15 Years with Dual CCIE can earn upto 20 lacs/annum in Telecom/IT industry.

*all the above prices are in INR as per the survey done.

We will come with the survey which will be done in European and Asia-PAC and American countries.

Popular Posts