SRX Services Gateway
Showing results for 
Search instead for 
Do you mean 
Reply
Contributor
Posts: 77
Registered: ‎04-29-2009
0 Kudos

ASA to SRX golden configuration

I'm running a SRX650 at a central site and have two Cisco ASA's (one 5505 running 8.0(5)23 and one 5510 running 8.0(5)) at remote sites. I run hub-and-spoke configuration with the srx being the hub. The sites run a rfc1918 /24's (192.168.16.0 in this case) and the srx has the route for the 192.168.0.0/16. I have a working setup since more than a year ago but after upgrading from 10.0R2.10 more than 6 months ago, the VPN's have been all but stable. I've messed around with most of the settings and during short periods of time, I've noticed a slight improvement, just to the start behave even worse than before after an additional couple of days. Right now I run dpd since not running dpd puts the cpn in a state (after a couple of hours) where it doesn't reestablis until after a manual clear of the security-associations in the SRX. The VPN goes up and down with just a couple of minutes interval, this being logged in the ASA:

 

Sep 05 23:46:59 [IKEv1 DEBUG]: Group = XX.XX.XX.XX, IP = XX.XX.XX.XX, Sending keep-alive of type DPD R-U-THERE (seq number 0x4cadc372)
Sep 05 23:46:59 [IKEv1 DEBUG]: Group = XX.XX.XX.XX, IP = XX.XX.XX.XX, constructing blank hash payload
Sep 05 23:46:59 [IKEv1 DEBUG]: Group = XX.XX.XX.XX, IP = XX.XX.XX.XX, constructing qm hash payload
Sep 05 23:46:59 [IKEv1]: IP = XX.XX.XX.XX, IKE_DECODE SENDING Message (msgid=d9713593) with payloads : HDR + HASH (8) + NOTIFY (11) + NONE (0) total length : 84
Sep 05 23:47:01 [IKEv1 DEBUG]: Group = XX.XX.XX.XX, IP = XX.XX.XX.XX, Sending keep-alive of type DPD R-U-THERE (seq number 0x4cadc373)
Sep 05 23:47:01 [IKEv1 DEBUG]: Group = XX.XX.XX.XX, IP = XX.XX.XX.XX, constructing blank hash payload
Sep 05 23:47:01 [IKEv1 DEBUG]: Group = XX.XX.XX.XX, IP = XX.XX.XX.XX, constructing qm hash payload
Sep 05 23:47:01 [IKEv1]: IP = XX.XX.XX.XX, IKE_DECODE SENDING Message (msgid=b916c9f1) with payloads : HDR + HASH (8) + NOTIFY (11) + NONE (0) total length : 84
Sep 05 23:47:03 [IKEv1 DEBUG]: Group = XX.XX.XX.XX, IP = XX.XX.XX.XX, Sending keep-alive of type DPD R-U-THERE (seq number 0x4cadc374)
Sep 05 23:47:03 [IKEv1 DEBUG]: Group = XX.XX.XX.XX, IP = XX.XX.XX.XX, constructing blank hash payload
Sep 05 23:47:03 [IKEv1 DEBUG]: Group = XX.XX.XX.XX, IP = XX.XX.XX.XX, constructing qm hash payload
Sep 05 23:47:03 [IKEv1]: IP = XX.XX.XX.XX, IKE_DECODE SENDING Message (msgid=83ca440) with payloads : HDR + HASH (8) + NOTIFY (11) + NONE (0) total length : 84
Sep 05 23:47:05 [IKEv1]: Group = XX.XX.XX.XX, IP = XX.XX.XX.XX, IKE lost contact with remote peer, deleting connection (keepalive type: DPD)
Sep 05 23:47:05 [IKEv1 DEBUG]: Group = XX.XX.XX.XX, IP = XX.XX.XX.XX, IKE SA MM:94c80332 rcv'd Terminate: state MM_ACTIVE  flags 0x00000062, refcnt 1, tuncnt 1
Sep 05 23:47:05 [IKEv1 DEBUG]: Group = XX.XX.XX.XX, IP = XX.XX.XX.XX, sending delete/delete with reason message
Sep 05 23:47:05 [IKEv1 DEBUG]: Group = XX.XX.XX.XX, IP = XX.XX.XX.XX, constructing blank hash payload
Sep 05 23:47:05 [IKEv1 DEBUG]: Group = XX.XX.XX.XX, IP = XX.XX.XX.XX, constructing IPSec delete payload
Sep 05 23:47:05 [IKEv1 DEBUG]: Group = XX.XX.XX.XX, IP = XX.XX.XX.XX, constructing qm hash payload
Sep 05 23:47:05 [IKEv1]: IP = XX.XX.XX.XX, IKE_DECODE SENDING Message (msgid=c659b2e8) with payloads : HDR + HASH (8) + DELETE (12) + NONE (0) total length : 68
Sep 05 23:47:05 [IKEv1 DEBUG]: Group = XX.XX.XX.XX, IP = XX.XX.XX.XX, Active unit receives a delete event for remote peer XX.XX.XX.XX.

 The VPN is then torn down and reestablished after a couple of seconds. In most cases, however, when a DPD is sent from the ASA, the SRX responds OK and the session is not torn down. This is the relevant part of the configuration in the SRX:

interfaces {
    st0 {
        unit 2 {
            description "Stockholm Site";
            family inet;
        }
    }
}

routing-options {
    static {
        route 192.168.16.0/24 next-hop st0.2;
    }
}
security {
	ike {
	    proposal tvx-ike-prop-1 {
	        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;
	    }
	    policy tvx-ike-pol-1 {
	        mode main;
	        description "Policy to spoke sites";
	        proposals tvx-ike-prop-1;
	        pre-shared-key ascii-text "XXXXXXXXXXXX"; ## SECRET-DATA
	    }
	    gateway gw_office_junfrug {
	        ike-policy tvx-ike-pol-1;
	        address YY.YY.YY.YY;
	        dead-peer-detection interval 10;
	        local-identity inet XX.XX.XX.XX;
	        external-interface ge-0/0/0.455;
	    }
	}
	
	ipsec {
    	proposal tvx-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 tvx-ipsec-pol-1 {        
            description "Custom - DH Group 2 PFS";
            perfect-forward-secrecy {   
                keys group2;            
            }                           
            proposals tvx-ipsec-prop-p2;
        }
	
        vpn junfrug_vpn {               
            bind-interface st0.2;       
            ike {                       
                gateway gw_office_junfrug;
                proxy-identity {        
                    local 192.168.0.0/16;
                    remote 192.168.16.0/24;
                    service any;        
                }                       
                ipsec-policy tvx-ipsec-pol-1;
            }                           
            establish-tunnels immediately;
        }
	}
	
	flow {
	    tcp-mss {
	        ipsec-vpn {
	            mss 1350;
	        }
	    }
	}
}

 And in the ASA:

interface Vlan2
 description Outside interface public address(es)
 nameif outside
 security-level 0
 ip address YY.YY.YY.YY 255.255.255.224

access-list outgoing_vpn_lund extended permit ip 192.168.16.0 255.255.255.0 192.168.0.0 255.255.0.0

crypto ipsec transform-set tvx-ipsec-p2 esp-aes esp-sha-hmac 
crypto ipsec security-association lifetime seconds 28800
crypto ipsec security-association lifetime kilobytes 1048576
crypto map vpn_to_lund_vm 5 match address outgoing_vpn_lund
crypto map vpn_to_lund_vm 5 set pfs 
crypto map vpn_to_lund_vm 5 set peer XX.XX.XX.XX 
crypto map vpn_to_lund_vm 5 set transform-set tvx-ipsec-p2
crypto map vpn_to_lund_vm interface outside

crypto isakmp identity address 
crypto isakmp enable outside
crypto isakmp policy 5
 authentication pre-share
 encryption aes
 hash sha
 group 2
 lifetime 86400
no crypto isakmp nat-traversal
crypto isakmp ipsec-over-tcp port 10000

tunnel-group DefaultRAGroup ipsec-attributes
 isakmp keepalive threshold 10 retry 2
tunnel-group XX.XX.XX.XX type ipsec-l2l
tunnel-group XX.XX.XX.XX ipsec-attributes
 pre-shared-key *

 (Thanks to keithr for suggesting these transform sets in a different thread)

 

Any suggestions to what next to try would be greatly appreciated. I've enabled traceoptions to the ike clause in the srx (omitted in the configuration above) but I run a couple of other tunnels as well so output is rather cluttered.

 

This is what the output from show security ipsec security-associations detail index 131075 looks like:

  Virtual-system: root
  Local Gateway: XX.XX.XX.XX, Remote Gateway: YY.YY.YY.YY
  Local Identity: ipv4_subnet(any:0,[0..7]=192.168.0.0/16)
  Remote Identity: ipv4_subnet(any:0,[0..7]=192.168.16.0/24)
    DF-bit: clear
    Direction: inbound, SPI: cd6ca89c, AUX-SPI: 0
                              , VPN Monitoring: -
    Hard lifetime: Expires in 26982 seconds
    Lifesize Remaining:  943713 kilobytes
    Soft lifetime: Expires in 26406 seconds
    Mode: tunnel, Type: dynamic, State: installed
    Protocol: ESP, Authentication: hmac-sha1-96, Encryption: aes-cbc (128 bits)
    Anti-replay service: counter-based enabled, Replay window size: 64

    Direction: outbound, SPI: 31121cfb, AUX-SPI: 0
                              , VPN Monitoring: -
    Hard lifetime: Expires in 26982 seconds
    Lifesize Remaining:  943713 kilobytes
    Soft lifetime: Expires in 26406 seconds
    Mode: tunnel, Type: dynamic, State: installed
    Protocol: ESP, Authentication: hmac-sha1-96, Encryption: aes-cbc (128 bits)
    Anti-replay service: counter-based enabled, Replay window size: 64

One thing that strikes me here is that lifesize is never decremented desipte traffic passing through the tunnel, in fact, it's always 943713 except for a few moments during tunnel establishment but once it's up, it never changes from that. Other than that it looks OK from what I can tell. This is the Cisco equivalent "show crypto ipsec sa"

interface: outside
    Crypto map tag: vpn_to_lund_vm, seq num: 5, local addr: YY.YY.YY.YY

      access-list outgoing_vpn_lund extended permit ip 192.168.16.0 255.255.255.0 192.168.0.0 255.255.0.0 
      local ident (addr/mask/prot/port): (192.168.16.0/255.255.255.0/0/0)
      remote ident (addr/mask/prot/port): (192.168.0.0/255.255.0.0/0/0)
      current_peer: XX.XX.XX.XX

      #pkts encaps: 87233, #pkts encrypt: 87233, #pkts digest: 87233
      #pkts decaps: 108052, #pkts decrypt: 108052, #pkts verify: 108052
      #pkts compressed: 0, #pkts decompressed: 0
      #pkts not compressed: 87233, #pkts comp failed: 0, #pkts decomp failed: 0
      #pre-frag successes: 0, #pre-frag failures: 0, #fragments created: 0
      #PMTUs sent: 0, #PMTUs rcvd: 0, #decapsulated frgs needing reassembly: 0
      #send errors: 3, #recv errors: 0

      local crypto endpt.: YY.YY.YY.YY, remote crypto endpt.: XX.XX.XX.XX

      path mtu 1500, ipsec overhead 74, media mtu 1500
      current outbound spi: CD6CA89C
      current inbound spi : 31121CFB

    inbound esp sas:
      spi: 0x31121CFB (823270651)
         transform: esp-aes esp-sha-hmac no compression 
         in use settings ={L2L, Tunnel, PFS Group 2, }
         slot: 0, conn_id: 14217216, crypto-map: vpn_to_lund_vm
         sa timing: remaining key lifetime (kB/sec): (922920/26795)
         IV size: 16 bytes
         replay detection support: Y
         Anti replay bitmap: 
          0xFFFFFFFF 0xFFFFFFFF
    outbound esp sas:
      spi: 0xCD6CA89C (3446450332)
         transform: esp-aes esp-sha-hmac no compression 
         in use settings ={L2L, Tunnel, PFS Group 2, }
         slot: 0, conn_id: 14217216, crypto-map: vpn_to_lund_vm
         sa timing: remaining key lifetime (kB/sec): (984044/26795)
         IV size: 16 bytes
         replay detection support: Y
         Anti replay bitmap: 
          0x00000000 0x00000001

 In the cisco end, the lifetime counters (both data and time) decrement as expected. 

 

Any hints and suggestions for what more to try, specific things to have a look at and debug, are appreciated. Judging from a couple of other threads in this forum these issues are rather common but I have yet not found a golden configuration (for both ends, Cisco and Juniper) for a scenario such as this but maybe this thread can end up in a complete, working (& stable :-) example.

Contributor
Posts: 18
Registered: ‎07-06-2011
0 Kudos

Re: ASA to SRX golden configuration

Hi have you consider creating the VPN to the Cisco devices as a policy based VPN instead of a routed based VPN?

Routed based VPN seems to work fantastic between SRX and in my experience I have had much more luck with policy based VPN to Cisco devices.

There is more policy work that needs to be configured on the SRX for the crypto ACL to match but after it is done it seems much more stable.

Since you are allowing full IP connectivity between both sides then the policy should be easier to setup. Make sure to include the pair policy command under the policy tunnel configuration.

 

Distinguished Expert
Posts: 979
Registered: ‎09-10-2009
0 Kudos

Re: ASA to SRX golden configuration

What version of Junos are you running?

 

I had some IKE/IPcec problems on 10.2R3, for which some PRs were filed, though I have no way to see the current status of them (*sigh*).

 

You can ask JTAC about PR #s:  569590, 570314, 546228

 

One of those was specifically related to a bug where the SRX would not reestablish a tunnel with a Cisco peer after the KB lifetime is reached (assuming that happens before the seconds lifetime expires).  It's been fixed in more recent releases of software.

 

The logs you posted from the ASA look like it's not getting a DPD answer back from the SRX.  You might need to run a packet capture at one or both sides to see if the DPD messages are being sent and received in both directions. You should also check the output of "show security ike sa" since DPD is an IKE/Phase 1 function.

 

-kr


---
If this solves your problem, please mark this post as "Accepted Solution."
Kudos are always appreciated.
Contributor
Posts: 77
Registered: ‎04-29-2009
0 Kudos

Re: ASA to SRX golden configuration

Thanks both of you for your input!

 

I'm running 10.4R6.5 on the SRX.

 

I have looked more at the dpd's, just as keithr pointed out, dpd's sent from the ASA doesn't always seem to be answered by the SRX. If I'm not mistaken, dpd's are only exchanged when no other traffic is passing, and sitting with the ASA console up and debugging enabled I can clearly see that it sometimes takes several hours between the sending of DPD's from the ASA. And everytime it does send a R-U-THERE, the SRX fails to answer and the vpn is brought down. Sigh... Searching through the log on the SRX, I can see that it sometimes does send an ACK to the ruthere, bot in most cases it's not. And since there seem to be some other issue with not having dpd enabled, of all the bad options, running with dpd enabled is the better of them.

 

I will first set up a packet capture on the srx to try and see why the dpd's are not answered. If that doesn't lead me anywhere I'll reconfigure to use policy based VPN instead. I don't have the time to try that right now but hopefully within a couple of days, will get back to you with the results. I will also try too look through the release notes of later versions to see if anything appears wrt VPN-interoperability.

 

Since a while back I've considered "upgrading" the ASA's in the regional offices to SRX's but I have a hard time convincing myself wheter that is the right thing to do. Apart from this particular issue, the ASA's work fantastic, especially with SIP, which I'm wholly dependant on and I know at least in older versions of Junos that has been really troublesome. Looking through the forums I get the feeling this has maybe become better in later releases? Anyone with experience on that?

Contributor
Posts: 77
Registered: ‎04-29-2009
0 Kudos

Re: ASA to SRX golden configuration

So I've reconfigured the SRX to use policy based vpn for one of the ASA's since about two days back. I still see the same behaviour wrt dropping the connection about every 3-7 hours. jc_ruiz, would it be possible for you to share your well-working configuration so I can try it and see wether it does any difference in my scenario?

Contributor
Posts: 77
Registered: ‎10-09-2008
0 Kudos

Re: ASA to SRX golden configuration

Hi Did you ever get to the bottom of this problem

Distinguished Expert
Posts: 828
Registered: ‎04-17-2008
0 Kudos

Re: ASA to SRX golden configuration

Please provide the output from "show ike security-association detail" on the SRX and "show crypto isakmp sa" on the Cisco side.

Ben Dale
JNCIP-ENT, JNCIS-SP, JNCIE-SEC #63
Juniper Ambassador
Follow me @labelswitcher
Contributor
Posts: 77
Registered: ‎04-29-2009
0 Kudos

Re: ASA to SRX golden configuration

This is the output from the SRX

IKE peer YY.YY.YY.YY, Index 1099979,
  Role: Responder, State: UP
  Initiator cookie: 1b6666b1d4fc786c, Responder cookie: 3d2e7a8aeb005818
  Exchange type: Main, Authentication method: Pre-shared-keys
  Local: XX.XX.XX.XX:500, Remote: YY.YY.YY.YY:500
  Lifetime: Expires in 86382 seconds
  Peer ike-id: YY.YY.YY.YY
  Xauth assigned IP: 0.0.0.0
  Algorithms:
   Authentication        : sha1 
   Encryption            : aes-cbc (128 bits)
   Pseudo random function: hmac-sha1
  Traffic statistics:
   Input  bytes  :                  884
   Output bytes  :                  928
   Input  packets:                    5
   Output packets:                    4
  Flags: Caller notification sent 
  IPSec security associations: 1 created, 0 deleted
  Phase 2 negotiations in progress: 1

    Negotiation type: Quick mode, Role: Responder, Message ID: 3471791129
    Local: XX.XX.XX.XX:500, Remote: YY.YY.YY.YY:500
    Local identity: ipv4_subnet(any:0,[0..7]=192.168.0.0/16)
    Remote identity: ipv4_subnet(any:0,[0..7]=192.168.16.0/24)
    Flags: Caller notification sent, Waiting for done

 And this is the output from the ASA

   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: XX.XX.XX.XX
    Type    : L2L             Role    : initiator 
    Rekey   : no              State   : MM_ACTIVE 
    Encrypt : aes             Hash    : SHA       
    Auth    : preshared       Lifetime: 86400
    Lifetime Remaining: 86349

 This weekend I noticed another interesting thing which is probably related to this issue. When settin up an additional tunnel with this SRX and a J2320, the tunnel refused to come up. Nothing was logged on the SRX side and the J-side timed out time after time. When troubleshooting this i noticed that the public interface (terminating the VPN on the SRX) did not reply to ping despite having "host-inbound-traffic system-services ping" set. When noticing this i set the tunnel on the SRX side to establish-tunnels-immediately and it came up immediately. This leads me to believe that there is something wrong with the SRX not allowing services (ping and ike) despite being permitted in the host-inbound-traffic for the zone as such:

gustav@xyz> show configuration security zones security-zone untrust
tcp-rst;
host-inbound-traffic {
    system-services {
        ping;
        ike;
    }
    protocols {
        ospf;
    }
}
interfaces {
    ge-0/0/0.455;
}

 so despite the above, the interface ge-0/0/0.455 neither answers ping's nor replies to ike traffic initiated from the outside...

 

As can be seen in the posts above, the SRX has issues answering DPD's from the other end of the tunnel, these two issues (no ping replies and no ike traffic allowed) feels somewhat related. The ge-0/0/0.455 has NAT enabled

 

Distinguished Expert
Posts: 828
Registered: ‎04-17-2008
0 Kudos

Re: ASA to SRX golden configuration

Hi Gustav,

 

When you say interface ge-0/0/0.455 has NAT enabled - what do you mean?

 

Is it NATTing addresses from the LAN side to the untrust?

 

Is the untrust interface ge-0/0/0.455 a public IP address that is reachable from the other sites, or is it only available through a NAT?

 

 

Ben Dale
JNCIP-ENT, JNCIS-SP, JNCIE-SEC #63
Juniper Ambassador
Follow me @labelswitcher
Contributor
Posts: 77
Registered: ‎04-29-2009
0 Kudos

Re: ASA to SRX golden configuration

Sorry, bad lingo, I have a source nat rule which uses the interface address:

source {
    pool servicenet_public_ip {
        address {
            XX.XX.XX.XX/32;
        }
    }
    rule-set service-net-nat {
        from interface [ ge-0/0/0.51 ge-0/0/1.0 ];
        to interface [ ge-0/0/0.15 ge-0/0/0.455 ge-0/0/2.0 ];
        rule service-net-nat {
            match {
                source-address [ 192.168.4.0/24 192.168.20.0/24 ];
            }
            then {
                source-nat {
                    pool {
                        servicenet_public_ip;
                    }
                }
            }
        }
    }
}

 and yes, NAT (or PAT actually) is enabled from lan to untrust. The ge-0/0/0.455 has a globally routeable address.

Distinguished Expert
Posts: 979
Registered: ‎09-10-2009
0 Kudos

Re: ASA to SRX golden configuration

Try moving your host-inbound-traffic configuration to the actual interface, rather than the zone.

 

I haven't gotten deep into this, but I just ran a real quick experiment, and I noticed that when I have this:

 

security-zone untrust {
  host-inbound-traffic {
    system-services {
      ping;
    }
  }
  interfaces {
    ge-0/0/0.420 {
      host-inbound-traffic {
        system-services {
          traceroute;
          ssh;
          http;
          https;
        }
        protocols {
          ospf;
        }
      }
    }
  }
}

I am unable to ping the address of my ge-0/0/0.420 interface.  However, if I change it to this:

 

security-zone untrust {
  interfaces {
    ge-0/0/0.420 {
      host-inbound-traffic {
        system-services {
          ping;
          traceroute;
          ssh;
          http;
          https;
        }
        protocols {
          ospf;
        }
      }
    }
  }
}

I am then able to ping the interface.

 

I'm sure there's probably some blurb buried deep somehwere in a "You passed the JNCIS-SEC test, so you should know this!" document, but honestly, I've always attached my host-inbound-traffic directly to my interfaces, not to the zones, and I've never run into this issue before.

 

Try it, see if it works.  Smiley Wink

-kr


---
If this solves your problem, please mark this post as "Accepted Solution."
Kudos are always appreciated.
Distinguished Expert
Posts: 828
Registered: ‎04-17-2008
0 Kudos

Re: ASA to SRX golden configuration

Host-inbound-traffic under a specific interface always overrides the zone configuration, but having it just configured in a zone Should Just Work™ just as well.

 

On an unrelated side note, there are extra services that are ONLY available when you configure under an interface - such as dhcp, bootp etc.

 

As for the original problem - I would disable "establish-tunnels immediately" on the SRX650.   Cisco defaults to something equivalant to "establish tunnels on-traffic" (eg: something has to match the crypto-map before it will trigger IKE) and this can cause a synchronisation issue where both gateways are trying to initiate a tunnel to each other, and this WILL fail repeatedly.  As a rule of thumb, I always set up SPOKES to connect back to the hub, with "establish-tunnels immediately" on the spoke side and no configuration on the hub.

 

Also I notice in your IKE Gateway configuration you specify a local-identity.  This shouldn't be required in Main mode, so remove it from the configuration just in case it is interfering with anything.

Ben Dale
JNCIP-ENT, JNCIS-SP, JNCIE-SEC #63
Juniper Ambassador
Follow me @labelswitcher
Distinguished Expert
Posts: 979
Registered: ‎09-10-2009
0 Kudos

Re: ASA to SRX golden configuration


dfex wrote:

Host-inbound-traffic under a specific interface always overrides the zone configuration, but having it just configured in a zone Should Just Work™ just as well.


Agreed, and it's great when things really do just work, but even in my simple test, "Should Just Work", as we can see, didn't.

 

I was merely suggesting a couple simple tests to see if it had an effect, maybe it'll help, maybe it won't.

-kr


---
If this solves your problem, please mark this post as "Accepted Solution."
Kudos are always appreciated.
Highlighted
Contributor
Posts: 77
Registered: ‎04-29-2009
0 Kudos

Re: ASA to SRX golden configuration

I took another look at this (tried your suggestion as well keithr - same result thou...) I have several interfaces on the srx and found out that traffic isn't entering the .455 interface but rather .15 (same physical interface though, ge-0/0/0) and they belong to the same security zone, untrust. When that became clear to me, I added a policy for untrust to untrust which permits ping, and voilà, the pings are suddenly answered... This might explain a lot I guess. I've just added "application any" to the untrust to untrust rule and will se if the VPN's act more stable than before.

 

Thanks for your suggestions!

Contributor
Posts: 227
Registered: ‎01-12-2010
0 Kudos

Re: ASA to SRX golden configuration

[ Edited ]

Hi

 

I've been labbing SRX---to---ASA vpn for past couple of months.

 

Its probably useful to let readers know that at time of writing Cisco ASA does *not* support Route-Based VPN unlike the SRX.

 

The setup i'm using is route-based on SRX and of course policy-based on ASA. I wanted to bring up the topic of proxy IDs.

 

My initial understanding was these were required and should align to 'crypto-map' on Cisco end, but in my setup its working without Proxy-id and I'm not using Traffic-Selectors either. I suspect this is because we're using route-based vpn on SRX side. Further input from the expert would be most welcome.

 

thanks in advance

 

                proxy-identity {        
                    local 192.168.0.0/16;
                    remote 192.168.16.0/24;
Ajaz Nawaz
JNCIE-SEC#254 CCIE#15721
JNCIA-FWV | JNCIS-FWV
JNCIA-JUNOS | JNCIS-SEC
JNCIP-SEC | JNCIE-SEC
CCNP-Collaboration