This community is currently under full moderation, meaning  all posts will be reviewed before appearing in the community. Please expect a brief delay—there is no need to post multiple times. If your post is rejected, you'll receive an email outlining the reason(s). We've implemented full moderation to control spam. Thank you for your patience and participation.

Expand all | Collapse all

VPN is still not working --- SRX to ASA

Jump to Best Answer
  • 1.  VPN is still not working --- SRX to ASA

    Posted 07-14-2010 10:43
      |   view attached

    ASA : VPN : Vendor Controlled

    Phase 1: 3DES - MD5 - Group 2 - 86400 sec lifetime

    Phase 2: Main Negotiation Mode - PFS Disabled - SA Lifetime 28800 - 3DES - MD5


    My scrubbed VPN related configuration is attached...


    The following is from the log files:



    (ike trace)

    Jul 14 20:29:06 kmd_sa_cfg_free: Tunnel node for tunnel 0 (SA: ARIS) not found
    Jul 14 20:29:06 Group/Shared IKE ID VPN configured: 0
    Jul 14 20:29:06 kmd_diff_config_now, configuration diff complete


    Jul 14 17:29:06 Obsolete parameter length_of_local_secret is not set to zero in ssh_ike_init
    Jul 14 17:29:06 Obsolete parameter token_hash_type is not set to zero in ssh_ike_init
    Jul 14 17:34:23 Group/Shared IKE ID VPN configured: 0





    srx20100714.txt   14 KB 1 version

  • 2.  RE: VPN is still not working --- SRX to ASA

    Posted 07-14-2010 11:11
    Your outbound NAT matching all trust traffic will prevent any policy based VPN from working.. To fix this exclude the remote VPNnets from that rule with a new term matched them and eludes them.

  • 3.  RE: VPN is still not working --- SRX to ASA

    Posted 07-14-2010 12:27

    Ok, I have added the following in bold to my NAT cfg :


    from zone trust;
    to zone untrust;
    rule vpn-no-nat-rule {
        match {
            destination-address [ 10.x.x.0/24 10.x.x.0/24 ];    ## IP Ranges for Remote Connection
        then {
            source-nat {
    rule source-nat-rule {
        match {
        then {
            source-nat {



    Nothing has changed --- Although i'm sure this would have just been one more thing to throw me off, so thank you.


  • 4.  RE: VPN is still not working --- SRX to ASA

    Posted 07-14-2010 12:43

    Founda nother issue that my polices were out of order (i.e. VPN police fell after a deny all policy) --- Fixed the order of the polices, still no luck...


    Event logs now say:


    Jul 14 22:36:34 iked_process_ifl_ext_add: ifl tunnel-id lookup failed for ifl vlan.100
    Jul 14 22:36:34 Couldn't get the zone information for interface ext ge-0/0/0, error No such file or directory
    Jul 14 22:36:34 Couldn't get the zone information for interface ext ge-0/0/0, error No such file or directory
    Jul 14 22:36:34 Couldn't get the zone information for interface ext ge-0/0/0, error No such file or directory
    Jul 14 22:36:34 kmd_sa_cfg_free: Tunnel node for tunnel 2 (SA: INSTANCE-ARIS_0002_0011_0000) not found

  • 5.  RE: VPN is still not working --- SRX to ASA

    Posted 07-14-2010 12:50

    Another thought is that this keeps referencing ge-0/0/0


    ge-0/0/0 thru ge-0/0/7 are setup in a switching configuration, and are all configured as apart of vlan.175 ---


    I have mutliple routers and appliances on site that plug directly into this "dmz" to recieve direct access to my internet link, no filtering is done by the SRX for these devices.


    In other words, The internet connetion plugs into ge-0/0/0 and is switched with the other 7 ports on vlan.175 which have other routers on them, without this type of configuration I have to put another switch between my internet connection and the SRX... Is this configuration causing the issue, somehow not supported? (please tell me this is not it).



  • 6.  RE: VPN is still not working --- SRX to ASA

    Posted 07-14-2010 13:01

    Try adding IKE to the system services of the VLAN interfaces not just the ZONE it is a member of.


    Not really sure about terminating on a VLAN like that.. I have only used the VLAN configuration for my internal interfaces.

  • 7.  RE: VPN is still not working --- SRX to ASA

    Posted 07-14-2010 13:15

    Same, here, but I don't see any other way to do the "WAN Switch" that I need ... Unless you know of any tricks ... Everything else like NAT has been working with no problems with this configuration.   I actually had ge-0/0/0 in the interface-range with the other 7 ports, but pulled it out and configured it individually hoping that might be the issue...    --


    - Not seeing where I could add ike to the VLAN itself...   As for the recommendation, i'm not seeing where I can add a system service to the VLAN itself.





  • 8.  RE: VPN is still not working --- SRX to ASA

    Posted 07-15-2010 09:07

    Anybody from Juniper have any comments on the outside interfaces running as ethernet-switching --- and any ideas how to work around this?   


    Do I have to run a jumper cable between ports? (i.e. setup ethernet switch ge-0/0/0 to ge-0/0/6 with my actual internet link comming in on that switch, and then run a cable from that switch groups port ge-0/0/6  into ge-0/0/7 which then becomes my WAN interface?   Seems kind of silly, but it's the next thing I'm about to do because I don't know what else I can do.


    Is this really the cause of my problem before I go disrupting everyones internet to try and get these VPN tunnels up?  


    I wish I could have tested this more, but my hand was forced due to equipment failures with the old stuff before I had time to really test every aspect of this thing out.

  • 9.  RE: VPN is still not working --- SRX to ASA

    Posted 07-15-2010 09:16

    At this point I would just open a ticket if I where you.. the Juniper techs seem to have WAY more detailed documentation or trainging on SRX VPN issues than what is provided in the documetaion..

  • 10.  RE: VPN is still not working --- SRX to ASA

    Posted 07-20-2010 11:36

    1.) External interface for IKE should always be IP addressed based interface. IKE can not establish tunnel without an IP address. I suggest configure external interface to be vlan.175. This interface should be part of zone with inbound IKE service packet permitted. I hope the peer gateway (ASA) is reachable thru vlan.175 interface.


    2.) The verify first policy says all traffic should go thru IDP. Thus IPSec policy is never matched. My suggestion is to move IPSec policy first.


       policies {
            from-zone trust to-zone untrust {
                policy trust-to-untrust {
                    match {
                        source-address any;
                        destination-address any;
                        application any;

                    then {
                        permit {
                            application-services {



    If you still see the issue, can you attach complete /var/log/kmd file. This has the IKE log details.




  • 11.  RE: VPN is still not working --- SRX to ASA

    Posted 07-21-2010 10:14

    Thank you for the response --- I still am having issues after making the above changes, and am currently working with JTAC, which despite all of the bad things I've seen here about support, I have been very impressed with on this issue... Biggest thing slowing me down now is being in communication with the guys on the other side of this tunnel.


    I will post all of the findings / fixes that I make inside of this thread once I have the tunnel up and running.


  • 12.  RE: VPN is still not working --- SRX to ASA
    Best Answer

    Posted 07-29-2010 10:06

    The problem has been resolved, --- There are a couple not-so-obvious issues that I ran into while setting this up, and hopefully I can save someone some bang-head-against-wall moments by posting my working configuration as well as an overview of what was wrong.


    First, the obvious, make sure your policies are in the right order, as noted by


    SomeITGuy noted that I needed to use my vlan interface, for whatever reason I thought I had tried that already and it would not let me, but I must not have done it correctly because that did work...     Further on that note, there is no issue with running IPSEC VPN over a group of interfaces configured with family ethernet-switching.


    Here is a big killer that had me screwed all along:


    You can NOT combine multiple subnets into the same policy for a IPSEC-VPN policy...   This is something that Junos will let you do, it will pass commit checks, but it does not work, at all.     While I understand why this is failing, as proxy-addresses are pulled from this, it would be REALLY NICE if junos was able to handle this a bit better...

    In my case, I had the following problem:

    I had 3 IP addresses on MY SIDE (ex. - that needed to be allowed on this VPN policy, on the other side I had a total of NINE addresses that needed to be allowed ( - and -244) , there was no clean-cut subnets available for this.   The remote site was NOT able to allow me access to the subnet(s) that could be generated to allow me to access all of those addresses... For this tunnel I HAVE to use /32 addresses.

    I was able on my side to allow access to the subnet of because I do not have any other equipment that falls into that subnet range... Doing this enabled me to save ALOT of work because for each combination of addresses that you have (remote and local) you have to create a whole new policy.   Because I was able to combine mine into a subnet this saved me a TON of work, and I was able to get this VPN tunnel up with only 9 polices.... (which is really stupid crazy compared to what I'm used to with cisco, sorry, have to point that out)

    So, I created an address book entry in my trust zone for that subnet called Local-10_1_1_96-29

    Then I created 9 address book entries for all of the /32 addresses on the remote side using the same type of naming

    Then I created 9 policies which all look something like this:  (had I not used a subnet on my side, this would be 27 polices!!!)

    from-zone trust to-zone untrust {
        policy ARIS-1 {
            match {
                source-address Local-10_1_1_96-29;
                destination-address remote_10_1_1_21-32;
                application any;
            then {
                permit {
                    tunnel {
                        ipsec-vpn remote;


    Once the other side was changed in their configuration to use my local /29 subnet, everything started working.

    I have alot of VPNs here that are provided for VENDOR SUPPORT, and these vendors typically have access to only very specific IPs on my network... This is NOT uncommon in my configuration, I don't actually have a single Site to Site VPN setup that allows access to a large subnet... THIS IS A PAIN IN THE A** and I am not looking forward to moving the rest of my VPN tunnels off of Cisco equipment.   It would be great to see this made just a little bit easier.     JUNOS will allow you to make the policy statement to read something like "source-address [ address-1-32 address-2-32 ]   Why the hell can't it figure out that those are all seperate and just deal with it rather than making me put in 9 polices for 1 VPN tunnel which makes looking at my configuration a complete mess?

  • 13.  RE: VPN is still not working --- SRX to ASA

    Posted 07-29-2010 10:09

    One more thing, the person I worked with at JTAC was awesome, it was truely a pleasure to work with her on this case and I appreciate everything that she did to help me out, I learned alot working with her as she was always willing to explain what I did not understand coming from a cisco world.     I, personally, am very happy with my service from JTAC.   I just wanted to say that since I kind of ranted a bit above.   Smiley Happy

  • 14.  RE: VPN is still not working --- SRX to ASA

    Posted 07-29-2010 21:15

    This was posted on this other post. But I think worth repeating.



    Mainly the restriction of having to use multiple security policies for each proxy-id pair is needed when we need to interop with other vendors that do not have option for equivalent of Juniper route-based VPN. Actually for Juniper to Juniper VPNs this is extremely simple to have any number of subnets on each side of a LAN-to-LAN VPN with route-based VPN. And with route-based approach we only use a single SA pair for however number of subnets pairs that are needed. This approach uses far less SA resources than having to break each subnet pair into unique SAs. So for instance, if there were 3 subnets on one LAN and 4 subnets on the other LAN, that would mean 12 unique subnet pairs and hence 12 SAs on the VPN device. Route-based by comparison would need only 1 SA to do the same.

    Having said that, I do understand that we cannot assume that we are always building tunnels between Juniper devices. We do actually have a VPN Configurator tool accessible from our KnowledgeBase site. With this tool you can select policy-based and actually add however number of subnets on each side of the tunnel. The VPN configurator would output complete VPN configs including ALL policies needed to accomplish the task. You would just need to copy and paste the configs on your device.

    Here is the link to the VPN Configurator tool.

    The below link also is useful for other configuration and/or troubleshooting of VPNs on JUNOS devices.

    Hope this helps.

  • 15.  RE: VPN is still not working --- SRX to ASA

    Posted 07-30-2010 05:01

    I understand what you are saying but this is really a user interface issue and not a technical one.


    If you use policy vpn on other vendors like Sonicwall or Cisco, they provide a single user interface location to automatically create and associate these multiple tunnels that are required for operation.  There are multiple tunnel connections being created, they are just simplifying the user interface to get there.


    When you look at the tunnel status and other areas of their interface you do see them as the actual separate tunnels that they are.  But they organize it to make the configuration easier and the review of the configuration easier.


    And they also only count unique gateways towards your licensed number of ipsec vpn limit.  So even if you are creating three of these segment tunnels your license count for vpn tunnels only gets decremented by one.

  • 16.  RE: VPN is still not working --- SRX to ASA

    Posted 07-30-2010 08:43

    Agreeed --- I realize that there is scripts and the configuration tool that I can use --- the biggest issue is now that with all of the tunnels I have like this my configuration file is becoming a monster that is very difficult to look at, audit, and troubleshoot... It's HUGE.... And for the most part we HAVE to assume that we are not linking to any other Juniper equipment because frankly the market share for Juniper equipment is not anywhere close to what Cisco has.    It's nice that if I was connecting to Juniper on both sides it's easier, it's just not today's reality as I am the FIRST person that I know directly that has started using Juniper equipment, and I had to fight hard to make that happen citing along with other things that I liked the way the configuration was layed out, it seemed to make more sense than cisco's flat layouts... This process of connecting to multiple vendors has to be simplified...    All of the other vendors I have worked with have figured out how to make policy VPNs work with 1 combined policy and can figure out that if you have seperate subnets (or IPs with /32) that they need to adjust accordingly with the Proxy IDs so that Phase 2 doesnt vomit.


    I also agree with the poster that it is slightly crazy that what I consider to be 1 VPN tunnel is counting as 9 on the device.


  • 17.  RE: VPN is still not working --- SRX to ASA

    Posted 08-02-2010 12:08

    There is another approach you could use which might simplify your life. I've had exactly this problem building an IPSEC VPN between a Cisco 876 and an SRX210, with multiple subnets in unrelated address spaces on the SRX side.


    I solved it by building a GRE tunnel and then stuffing that into the IPSEC VPN tunnel. Clearly this involves encapsulation overheads but it works very well since all the IPSEC tunnel sees are the end-point ip addresses of the GRE tunnel. These remain constant no matter what traffic you stuff through it and which subnets are involved at either end; that's all controlled by directing whatever traffic you want into the GRE tunnel.




  • 18.  RE: VPN is still not working --- SRX to ASA

    Posted 09-20-2010 10:05

    I would have to give my thumbs up on the GRE based vpn policies. Not only does GRE make life simple going cisco to juniper, but I have managed a 200 plus location VPN network ALL cisco BTW, and as a standard we connected all the cisco boxes with GRE tunnels.


    Not only does it work well, but it allows multicast traffic which is a must in some enterprise environments. Also it lets you connect all your remote sites to multiple VPN HUB concentrators  and have failover, you just run OSPF on each gre tunnel interface and advertise the local site subnet back into ospf.


    This gives you a really robust vpn topology with automatic failover  and or traffic sharing between the different VPN HUBS.


    Don't count out GRE. It is an awsome protocol.

  • 19.  RE: VPN is still not working --- SRX to ASA

    Posted 09-04-2010 11:08

    Hello Kullnd,

    first of all: Thanks! You helped me out of a lot of trouble. I had the same issue and was absolutely stuck.

    Second: I agree to your opinion that this behavior is an absolute no go. All major vendors of VPN equipment can handle policies with multiple subnetworks on each side and can create the n*m SAs from it.

    A tool like the Juniper Configurator which generates the permuted policies will help to create the configuration, but that configuration cannot be handled afterwards. It will get much too big to change or debug.


    The configuration must stay as simple as possible not only at creation time but also afterwards. For other vendors this seems not to be a problem, so why for Juniper?

    To use GRE tunnels for each VPN like Gagoo suggests will add unnecessary complexity and sources for errors.

    Furthermore it will waste a lot of bandwidth and/or will slow connections down. For small packets like in interactive communication imagine the overhead produced by PPPoE-header + IPsec-header + GRE-header.


    Route based VPNs are nice if you have only Juniper boxes, but like you we have lots of VPN to other vendors.


    We are evaluation Juniper SRX to substitute a 100+ location VPN currently run with Lucent Bricks - Alcatel-Lucent will stop selling them 😞 - but if Juniper will not add this a better VPN-policy handling  ...

    - Steffen

  • 20.  RE: VPN is still not working --- SRX to ASA

    Posted 09-20-2010 07:20

    Hi, I'm trying to config a VPN tunnel between an ASA and an SRX240. I was wondering if you could post your working config.

  • 21.  RE: VPN is still not working --- SRX to ASA

    Posted 09-20-2010 07:28

    VPN Configurations can very greatly depending on what exactly your trying to do --- What I would recommend is using the configuration tool at​ols/vpnconfig.html , make sure you use a Policy VPN config as the Routed VPN only works between juniper devices (that I'm aware of).  


    If you can't get it up after that point, posting your config will allow us to view it and let you know what we see wrong.  Promise you this will be much easier than you trying to pick my configs apart, and will take less time on my side as well as pulling the config and filtering out my internal information takes time.




  • 22.  RE: VPN is still not working --- SRX to ASA

    Posted 03-10-2011 00:56

    Hi, kullnd


    I got the same error messages from log as you metioned, but i'm not sure weather the way you tried can solve it.

    I use a srx3600 to create ipsec vpn with an asa5505, but the difference is the asa5505 gets dynamic ip address from

    ISP by DSL and I dont need to setup VLAN.

    From asa5505 debug infomation, I found negotiation phase 1 was completed, then failed at phase 2. So few error

    message I could get to find the reason when i ping target address to initial the vpn.


    The attachments are the configurations of srx3600 and asa5505 
    and below is the debug info from the ASA:



    hw(config)# Mar 09 23:54:22 [IKEv1]: Group = y.232.124.40, IP = y.232.124.40, QM FSM error (P2 struct &0x175ddb8,

    mess id 0x1827933f)!
    Mar 09 23:54:22 [IKEv1]: Group = y.232.124.40, IP = y.232.124.40, construct_ipsec_delete(): No SPI to identify Phase 2

    Mar 09 23:54:22 [IKEv1]: Group = y.232.124.40, IP = y.232.124.40, Removing peer from correlator table failed, no

    Mar 09 23:54:49 [IKEv1]: Group = y.232.124.40, IP = y.232.124.40, construct_ipsec_delete(): No SPI to identify Phase 2

    Mar 09 23:54:49 [IKEv1]: Group = y.232.124.40, IP = y.232.124.40, Removing peer from correlator table failed, no



    hw(config)# show crypto isakmp sa

       Active SA: 1
        Rekey SA: 0 (A tunnel will report 1 Active and 1 Rekey SA during rekey)
    Total IKE SA: 1

    1   IKE Peer: y.232.124.40
        Type    : L2L             Role    : initiator
        Rekey   : no              State   : AM_ACTIVE


    srx3600 log message:

    Mar 10 06:34:53 KMD_INTERNAL_ERROR: iked_sa_cfg_delete_from_hash_table_for_one_gw: Failed to delete sa_cfg ike-vpn from sadb hash tbl with rip=0, lip=0
    Mar 10 06:34:53 kmd_sa_cfg_free: Tunnel node for tunnel 0 (SA: ike-vpn) not found
    Mar 10 06:34:53 KMD_INTERNAL_ERROR: iked_sa_cfg_delete_from_hash_table_for_one_gw: Failed to delete sa_cfg ike-vpn-test from sadb hash tbl with rip=0, lip=0
    Mar 10 06:34:53 kmd_sa_cfg_free: Tunnel node for tunnel 0 (SA: ike-vpn-test) not found
    Mar 10 06:34:53 Group/Shared IKE ID VPN configured: 0
    Mar 10 06:34:53 kmd_diff_config_now, configuration diff complete
    Mar 10 06:34:53 iked_process_ifl_ext_add: ifl tunnel-id lookup failed for ifl ge-0/0/1.0
    Mar 10 06:34:53 kmd_sa_cfg_free: Tunnel node for tunnel 2 (SA: INSTANCE-ike-vpn_0002_0010_0000) not found
    Mar 10 06:42:07 kmd_sa_cfg_free: Tunnel node for tunnel 4 (SA: INSTANCE-ike-vpn-test_0004_0005_0000) not found
    Mar 10 07:33:32 iked_process_ifl_ext_add: ifl tunnel-id lookup failed for ifl ge-0/0/1.0


    thanks in advance, any information will be appreciated!



    asa5505_config.txt   3 KB 1 version
    3600_config.txt   6 KB 1 version

  • 23.  RE: VPN is still not working --- SRX to ASA

    Posted 03-10-2011 14:20

    Try removing the aggressive mode from the ASA crypto map mymap.


    Also, I would suggest using cipher suites more modern/robust/secure than DES and MD5.  My standard IPSec configuration these days (which works fine between numerous Juniper and Cisco devices) is:



    proposal ike-prop-p1 {
        description "Custom - pre-g2-aes128-sha";
        authentication-method pre-shared-keys;
        dh-group group2;
        authentication-algorithm sha1;
        encryption-algorithm aes-128-cbc;
        lifetime-seconds 86400;

     And here is what I use for Phase 2:



    proposal ipsec-prop-p2 {
        description "Custom - esp-aes128-sha";
        protocol esp;
        authentication-algorithm hmac-sha1-96;
        encryption-algorithm aes-128-cbc;
        lifetime-seconds 28800;
        lifetime-kilobytes 1048576;
    policy ipsec-pol-1 {
        description "Custom - DH Group 2 PFS";
        perfect-forward-secrecy {
            keys group2;
        proposals ipsec-prop-p2;



    On the Cisco side:



    crypto isakmp policy 5
     authentication pre-share
     encryption aes
     hash sha
     group 2
     lifetime 86400
    crypto ipsec transform-set ipsec-p2 esp-aes esp-sha-hmac
    crypto ipsec security-association lifetime seconds 28800
    crypto ipsec security-association lifetime kilobytes 1048576
    crypto map foo 5 match address MYACL
    crypto map foo 5 set pfs 
    crypto map foo 5 set peer 
    crypto map foo 5 set transform-set ipsec-p2
    crypto map foo interface outside



  • 24.  RE: VPN is still not working --- SRX to ASA

    Posted 03-10-2011 17:05



    thanks for your information, I will try it later.

    I think there is a little difference from our configuration. In my scenario, ASA will accquire dynamic IP

    from the ISP, and it is supposed to use Aggressive mode when the peer has no static IP.

     Am I right?

  • 25.  RE: VPN is still not working --- SRX to ASA

    Posted 03-12-2011 18:26

    My vpn went to work after modification as kullnd mentioned.

    The policy in srx does not support mixture of different subnet in some case.


    My solution is :

    In SRX:

    seperate different subnet source-address into different policy.


    In Cisco:

    seperate different subnet into different access-list

  • 26.  RE: VPN is still not working --- SRX to ASA

    Posted 09-26-2011 08:40

    I think the keyword is,  this solution is, IPSec over GRE or GRE over IPSec.

    If it is IPSec over GRE, the interesting traffic is protocol 47.

  • 27.  RE: VPN is still not working --- SRX to ASA

    Posted 10-01-2011 23:20

    I have a couple more issues on this point, since some of my customers require me to nat on the outbound, I have to use route based vpns, as you cant source nat with policy based vpns, even to asa's.

    Then next, is a lot of times I go to the same address at the customer site from multiple addresses on my set.  So the customer has to set up just an access-list on his cisco, I have to set up multiple vpns as mentioned earlier and set the st0 interface as multipoint, at this point I cant add a static route to the single host I am reaching as it wont be entered into the routing table, and i have to use tunnel based forwarding, but since I'm going to the same destination, I now have to base my routing on source, so I have to to fbf based on souce all pointing at different routing instances.  i.e. if from source a, then use tunnel a, if from source b use tunnel b.  I then ran into one more instance, my traffic was coming in on a vpn interface, and you cant apply fbf to an st0 interface.  I eventually solved it by combining my encryption domain into a larger subnet since my addresses were contigous in this case and had my customer change their access list.  Fortunately the customer was willing to do this.  If my addresses would have been non contigous, not sure what I would have done.


    One other note, now that cisco has vti's you can do a route based vpn to a cisco router, of courses ASA's dont support this yet.