SRX

Hello!

We have two SRX240 in a cluster. I have configured an IPSec tunnel (policy-based) but the tunnel does not come up.


I found this in the log file, which leads me to the conclusion that it is a local problem:

Oct 18 09:41:14 iked_rts_async_ifa_handler: Received ifa add message for interface reth2
Oct 18 09:41:14 Inside iked_process_ifa_add_msg...
Oct 18 09:41:14   ifam->ifam_name = reth2  ifam->ifam_flags = 0xc0  ifam->ifam_af = 2
Oct 18 09:41:14   got IP address my.external.ip.address
Oct 18 09:41:14 iked_process_ifa_add_msg: Set sacfg ipsec-vpn-customer address my.external.ip.address.  Mark IFA up
Oct 18 09:41:14 iked_check_if_sa_cfg_ready: IFL EXT is down
Oct 18 09:41:14 Not activating the sa-cfg ipsec-vpn-customer, as other information is not available
Oct 18 09:41:14 iked_rts_async_ifa_handler: ifam->ifam_name = reth2 ifam->ifam_flags = 0x0 ifam->ifam_af = 2

I also get these messages every 60s.

Oct 18 09:42:13 Triggering all tunnels
Oct 18 09:42:13 iked_pm_trigger_callback called for ipsec-vpn-customer
Oct 18 09:42:13 iked_pm_trigger_callback: Ignoring SA_CFG ipsec-vpn-customer since IFF reth2.0 is down

But the interface reth2.0 is up and running (I am using it right now). We have another SRX cluster with a similar IPSec tunnel working. As this working cluster is running JunOS 12.1, I just upgraded our "problem cluster" from 11.4 to 12.1, but the symptoms stay the same.

root@gateway# show security ike
traceoptions {
    file iketrace size 1m;
    flag config;
    flag general;
    flag ike;
    level 15;
}
proposal p1-vpn-customer {
    description "P1 customer-VPN";
    authentication-method pre-shared-keys;
    dh-group group2;
    authentication-algorithm sha1;
    encryption-algorithm aes-256-cbc;
    lifetime-seconds 86400;
}

policy ike-policy-vpn-customer {
    mode main;
    proposals p1-vpn-customer;
    pre-shared-key ascii-text *** ## SECRET-DATA
}
gateway ike-gate-vpn-customer {
    ike-policy ike-policy-vpn-customer;
    address customer.ipsec.gateway.address;
    dead-peer-detection;
    external-interface reth2.0;
}

root@gateway# show security ipsec
traceoptions {
    flag security-associations;
    flag packet-processing;
    flag next-hop-tunnel-binding;
}
proposal p2-vpn-customer {
    description "VPN customer";
    protocol esp;
    authentication-algorithm hmac-sha1-96;
    encryption-algorithm aes-256-cbc;
    lifetime-seconds 28800;
}

policy ipsec-policy-vpn-customer {
    proposals p2-vpn-customer;
}

vpn ipsec-vpn-customer {
    bind-interface st0.1;
    ike {
        gateway ike-gate-vpn-customer;
        ipsec-policy ipsec-policy-vpn-customer;
    }
    establish-tunnels immediately;
}

What could be wrong here?

Thanks

Martin

Can you provide below information?

1. show security ipsec sa

2. show security ike sa

3. show interfaces terse | match reth

4. complete SRX configuration.

Regards,

Raveen

Also binding of st0 interface for ipsec vpn configuration, is not required for policy based vpn.

Hi!

There are no SAs up:

{primary:node0}
root@gateway> show security ike security-associations
node0:
--------------------------------------------------------------------------

{primary:node0}
root@gateway> show security ipsec security-associations
node0:
--------------------------------------------------------------------------
  Total active tunnels: 0

{primary:node0}

root@gateway> show interfaces terse | match reth2

ge-0/0/15.0             up    up   aenet    --> reth2.0
ge-5/0/15.0             up    up   aenet    --> reth2.0
reth2                   up    up
reth2.0                 up    up   inet     my.external.ip.address/27

Cleaning up the huge configuration file would take too long, so I'll omit that for now. Which sections would be interesting?

In the meantime, I also opened a case at JTAC, let's see what happens...

Ciao

Martin

Alright, JTAC could solve the problem then.

To me it appears to be a configuration issue.

1. bind-interface is not required for policy based vpn.

2. you need to verify if ike traffic is allowed in you security zone

3. lastly, you need to check you route.

Can you provide below?

1. Snippet of security zones.

2. Snippet of security policy

3. ping to your external-address

4. show route external-address

Regards,

Raveen

We would need to see the security configuration for the external zone. Then very that policies exist to allow the traffic, routes exist, the required protocols and serivces are permitted etc. But as you can see, not even phase 1 has been established. If you cannot provide the security configuration, then you can use an example provided by juniper to see where you have made mistake. You can also search this forum for examples. Many are here.

http://kb.juniper.net/InfoCenter/index?page=content&id=KB10128&smlogin=true

Attachment(s)

IMPLEMENTING POLICYBASED IPSEC VPN USING SRX -en.pdf   600 KB 1 version

If using  route based vpn can you confirm two things in your config ;

that st0.1 has family inet configured :

set interfaces st0.1 family inet

and that st0.1 is bound to a zone.

In cases we have seen when the above is not oresent we have seen issues.

Also you can do a > monitor traffic interface reth2.0 extensive no-resolve matching "host <vpn-peer-ip>"

to see at what message it fails.

Regards,
c_r
 

Note: If this answers your question, you could mark this post as accepted solution, that way it helps others as well. Kudos will be bonus if I earned it!

Hi!

JTAC did help me, the solution was to add st0.X to a security zone.

If the remote st0.x interface is not bound to a security zone, the device does not even attempt to start the tunnel.

Ciao

Martin

Also Can you confirm if the peer address :

customer.ipsec.gateway.address

is resolving . You should have set system name-server configured on teh device to resolve the above to an IP.

Regards,
c_r
 

Note: If this answers your question, you could mark this post as accepted solution, that way it helps others as well. Kudos will be bonus if I earned it!