Policy-Based <Span Class="caps">VPN</Span> Between Juniper <Span Class="caps">SRX</Span> and Cisco <Span Class="caps">ASA</Span>

  • Home /
  • Archived Blog Posts /
  • Policy-based <span class="caps">VPN</span> between Juniper <span class="caps">SRX</span> and Cisco <span class="caps">ASA</span>

Read­ing Time: 4 min­utes

One of the things that I am called upon to do fair­ly often in my cur­rent role is to con­fig­ure remote access VPN devices for some site or anoth­er.  Often these sites are tran­sient in nature, only stay­ing active for weeks or months at the longest before dis­ap­pear­ing forever–or at least until I don’t care any more.

Because I spend a fair amount of time set­ting these VPN tun­nels up, I have got­ten fair­ly good at the ins and outs of IPsec VPN tun­nel con­fig­u­ra­tion and trou­bleshoot­ing.  I was even begin­ning to think of myself as a bit of a VPN whis­per­er.  That was about to change, how­ev­er.

We use Cis­co’s ASA prod­uct line every­where for this type of thing, and as many of you no doubt know, if you use one ven­dor’s prod­uct for VPN tun­nels you are gen­er­al­ly in a good posi­tion.  You’ll like­ly still have prob­lems from time to time–just enough to keep you honest–but it works itself out.  This is the mod­el we’d been fol­low­ing for sev­er­al years.  Until now.

For rea­sons pass­ing inter­est here, we made the deci­sion to start explor­ing the use of Juniper’s SRX prod­uct line for our remote, tran­sient tun­nel des­ti­na­tions and small­er 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 inte­grate with the exist­ing infra­struc­ture.  This, as they say, is when the prover­bial excre­ment hit the fan.

As any­one who deals in these things knows, mix­ing ven­dors on either side of a VPN tun­nel is gen­er­al­ly a recipe for trou­ble.  Depend­ing on ven­dors, your trou­bles range from the “few drinks after work” type to the “move to Mex­i­co and open a beach bar” kind.  I had heard from many peo­ple that I trust that the SRX to ASA con­fig­u­ra­tion was this lat­ter type.

Juniper SRX devices pre­fer a type of VPN tun­nel known as a route-based VPN.  I’m not going to go into specifics here, but suf­fice it to say it’s a tech­nique that makes sense and a lot of ven­dors work this way.  Cis­co’s ASA, on the oth­er hand, prefers a type of VPN tun­nel known as pol­i­cy-based.  Pol­i­cy-based VPNs have some lim­i­ta­tions and seem to be favored most­ly by Cis­co and any­one who wants to inte­grate with Cis­co.  I had to make things work with­out chang­ing much on the HQ side (where the Cor­po­rate ASA units sit) out­side of what we nor­mal­ly do, so that meant that the SRX at the remote site need­ed to be con­fig­ured in a pol­i­cy-based way.

Bring on the pain.

The process I fol­lowed went some­thing like this:

  1. Spend a cou­ple of days learn­ing the Juniper SRX syn­tax.  This part was actu­al­ly kind of fun.
  2. Spend 5 min­utes con­fig­ur­ing new tun­nel on cor­po­rate ASA.
  3. Spend 3+ days try­ing to get Juniper to talk to ASA.  Spend only slight­ly more time con­fig­ur­ing as bang­ing head on desk.
  4. Spend 5.5 hours spread over two more days with jTAC.  Bang head more while they can’t fig­ure it out either.
  5. Go home, relax, have eure­ka moment, race back to office, make one-line change, FIX EVERYTHING!
  6. Go back home and drink.


As it turns out, the prob­lem can best be described as some­thing that every Cis­co Engi­neer learns in infan­cy: Cis­co is con­sis­tent­ly incon­sis­tent.  For exam­ple, when the ASA refers to SHA, do you sup­pose it’s refer­ing to the old SHA‑0 or the SHA‑1 that cor­rect­ed a flaw in the old SHA‑0?  Dun­no.  Since they, in some places, only say “SHA” and in oth­ers “SHA‑1” it’s any­body’s guess, real­ly.

The main thing I re-learned from this expe­ri­ence is that the defaults–the lit­tle timers, iden­ti­ties, and var­i­ous oth­er lit­tle bits–that make up a suc­cess­ful nego­ti­a­tion for an IPsec tun­nel are dif­fer­ent across plat­forms.  Some­times you real­ly have to search to find what they’re called.  Some­times you have to bang your head on the desk for a few days.

One more thing: this post was typed up quick­ly, with no edit­ing, and way too much cof­fee.  If I’ve over­looked things, got­ten things wrong, or just con­fused you more, I apol­o­gize and I’ll try to come back and clean it up lat­er.  In the mean time, hope­ful­ly the dia­gram and con­fig­u­ra­tions below will help you in your own quest to get a pol­i­cy-based VPN con­fig­ured between the SRX and ASA.

Oh, and as soon as I recov­er from this expe­ri­ence I’ll build out a con­fig­u­ra­tion to do a route-based exam­ple, which looks to only require a cou­ple of changes on the SRX side and a tad more tweak­ing per­haps on the ASA side.



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 {