SRX to ASA IPSec troubles

Question

we built a VPN between partner's Cisco ASA (unknown version) and my Juniper SRX 340.

The tunnel seems to go up properly:

root@fw01> show security ike security-associations 
node0:
--------------------------------------------------------------------------
  Index   State  Initiator cookie  Responder cookie  Mode           Remote Address   
  871021  UP     122b1bc303e78c95  59463a0410c30855  Main           10.20.30.40  

{primary:node0}
root@fw01> show security ipsec security-associations  
node0:
--------------------------------------------------------------------------
  Total active tunnels: 2
  ID    Algorithm       SPI      Life:sec/kb  Mon lsys Port  Gateway   
  <67108877 ESP:3des/md5 31c1eaf2 3402/  4608000 - root 500   10.20.30.40  
  >67108877 ESP:3des/md5 9acb5daf 3402/  4608000 - root 500   10.20.30.40  
  <67108878 ESP:3des/md5 5e4c4071 3462/  4608000 - root 500   10.20.30.40  
  >67108878 ESP:3des/md5 2efdc6d8 3462/  4608000 - root 500   10.20.30.40  

    {primary:node0}

but there is no way to send traffic over the tunnel (there are 2 subnets /24 from its side and 1 /24 from mine). I did a lot of attemps, but without serious results.

My conf is the following:

ike {
    proposal LO-MI_prop {
        authentication-method pre-shared-keys;
        dh-group group5;
        authentication-algorithm sha1;
        encryption-algorithm aes-256-cbc;
        lifetime-seconds 28800;
    }
    policy LO-MI_Ike {
        mode main;
        proposals LO-MI_prop;
        pre-shared-key ascii-text "$9$sN4GDQznu0IHqnCu0cSaZGU.P369BRhM8Nb"; ## SECRET-DATA
    }

    gateway LO-MI_gw {
        ike-policy LO-MI_Ike;
        address 10.20.30.40;
        external-interface reth0.0;
    }
}

ipsec {
    proposal LO-MI-IPsec_prop {
        protocol esp;
        authentication-algorithm hmac-md5-96;
        encryption-algorithm 3des-cbc;
        lifetime-seconds 3600;
    }
    policy LO-MI-IPsec_policy {
        proposals LO-MI-IPsec_prop;
    }
    vpn LO-MI_VPN {
        bind-interface st0.4;
        ike {
            gateway LO-MI_gw;
            ipsec-policy LO-MI-IPsec_policy;
        }
        traffic-selector term1 {
            local-ip 192.168.0.0/24;
            remote-ip 192.168.10.0/24;
        }
        traffic-selector term2 {
            local-ip 192.168.0.0/24;
            remote-ip 192.168.11.0/24;
        }
        establish-tunnels immediately;
    }
}

routing-options {
    static {
        route 0.0.0.0/0 next-hop 40.30.20.1;
        route 192.168.10.0/24 next-hop st0.4;
        route 192.168.11.0/24 next-hop st0.4;
    }
    auto-export {
        disable;
    }
}

policies {
    from-zone Untrust to-zone Trust {
        policy VPN-PARTNER_IN {
            match {
                source-address VPN-PARTNER;
                destination-address addr_192_168_0_0_24;
                application any;
            }
            then {
                permit;
            }
        }
    }
    from-zone Trust to-zone Untrust {
        policy VPN-PARTNER_OUT {
            match {
                source-address addr_192_168_0_0_24;
                destination-address VPN-PARTNER;
                application any;
            }
            then {
                permit;
            }
        }
    }
}

security-zone Untrust {
        interfaces {
            reth0.0;
            st0.4;
        }
}

Can anyone give me a suggestion?

Thanks in advance to all

UPDATE:

This is the configuration from ASA

crypto map out_map1 1 match address VPN_PARTNER_VB
crypto map out_map1 1 set peer 40.30.20.11
crypto map out_map1 1 set ikev1 transform-set ESP-3DES-MD5
crypto map out_map1 interface out
tunnel-group 40.30.20.11 type ipsec-l2l
tunnel-group 40.30.20.11 ipsec-attributes
 ikev1 pre-shared-key *****
...
...
...
access-list VPN_VERTICALBOOKING extended permit ip 192.168.10.0 255.255.255.0 192.168.0.0 255.255.255.0
access-list VPN_VERTICALBOOKING extended permit ip 192.168.11.0 255.255.255.0 192.168.0.0 255.255.255.0
...
...
...
access-list mgmt_access_in extended permit ip 192.168.10.0 255.255.255.0 192.168.0.0 255.255.255.0
access-list dmz_access_in extended permit ip 192.168.11.0 255.255.255.0 192.168.0.0 255.255.255.0
access-list out_access_in extended permit ip 192.168.0.0 255.255.255.0 object-group DM_INLINE_NETWORK_4 <--- this is my network
...
...
...
object-group network DM_INLINE_NETWORK_4
 network-object 192.168.10.0 255.255.255.0
 network-object 192.168.11.0 255.255.255.0

Without seeing the other side's configuration, all we can do is guess (which is off limits here). Can you have the admin for the ASA provide a sanitized config for that side? — Jesse P., Oct 2 '19 at 12:51
Hi Jesse. I can't provide anything from ASA, but all from Juniper. Ask me anything could helps. — Gianluca, Oct 2 '19 at 12:57
Sorry. The questions we need answered revolve around making sure there are proper ACLs permitting the traffic into the firewalls on both sides, proper ACLs defining which traffic is allowed over the tunnel, proper NAT (NAT exempt) statements, proper routing statements. Unless you can get answers to that for both sides, it's all just shots in the dark. — Jesse P., Oct 2 '19 at 13:09
Having said that, I don't see NAT statements in YOUR configuration output. You can at least provide that. — Jesse P., Oct 2 '19 at 13:12

Jesse P. · Accepted Answer · 2019-10-02 14:53:52Z

1

One problem on the ASA is that the crypto map match ACL being referenced is named VPN_PARTNER_VB but the ACL name is actually VPN_VERTICALBOOKING, so traffic will not be matched correctly, meaning traffic won't be routed over the tunnel on that side.

Also, I don't see the NAT or NAT exempt on the ASA. As it's set to use "crypto map" that tells me it's using policy-based VPN and would need some kind of NAT statement to either NAT or prevent NAT over the tunnel.

answered Oct 2 '19 at 14:53

Jesse P.

2,1441 gold badge4 silver badges11 bronze badges

The configuration was fixed (the ACL name) and I have more info: if the partner tries to ping me, I see it with tcpdump on my server! – Gianluca Oct 2 '19 at 15:03
@Gianluca So, you're saying that traffic is flowing now that the ACL name has been corrected, and the problem is fixed? – Jesse P. Oct 2 '19 at 15:16
No, I'm saying that the ACL name has been corrected and I see his icmp requests on my server, but he doesn't see my icmp replies on his devices. I suppose some ACL problem my side – Gianluca Oct 2 '19 at 15:24
Or a routing problem my side..I have 2 specular ACLs to manage tunnel traffic; if his packets can enter, why mine can't exit? – Gianluca Oct 2 '19 at 15:31
Sounds more like a routing issue on the host (server), not knowing where to send the replies. Can you verify that there is a valid path to the ASA subnets on the server (traffic makes it to the ASA from the server)? – Jesse P. Oct 2 '19 at 15:37

| show 7 more comments

Gianluca · Accepted Answer · 2019-10-03 15:04:58Z

So, finally I solved. We had two big problems:

a mismatch with ACL names Cisco side (quickly solved)
a missed NAT my side; a less filtered capture showed that traffic tried to go out, but with wrong source addresses)

Fixed the NAT, solved the problem.

Thanks to Jesse P. for the support

Stack Exchange Network

current community

your communities

more stack exchange communities

SRX to ASA IPSec troubles

2 Answers 2

Your Answer

Not the answer you're looking for? Browse other questions tagged ipsec juniper-srx or ask your own question.

Hot Network Questions

SRX to ASA IPSec troubles

2 Answers 2

Your Answer

Sign up or log in

Post as a guest

Not the answer you're looking for? Browse other questions tagged ipsec juniper-srx or ask your own question.

Related

Hot Network Questions