Community discussions

MUM Europe 2020
 
gilester
just joined
Topic Author
Posts: 5
Joined: Sat Feb 01, 2014 1:07 pm

AWS CHR IPSec: IKE constantly renegotiating new phase 1

Thu Nov 28, 2019 11:07 am

Hi

I am experimenting with running a CHR in AWS. There is an IPSec/GRE connection to another CHR I have in a private datacentre through which OSPF operates. It basically works, I have the IPSec/GRE tunnel up and passing traffic and all is good.

However! I noticed if I am not passing traffic across the tunnel, IKE regularly - every 40s at its fastest, sometimes every minute - tears the SA down and renegotiates from phase 1. During this time the tunnel is, obviously, down, as the IKE negotiation takes a few seconds to establish. A nasty workaround has been to get NetWatch pinging through the tunnel every 5s, but I'd rather not rely on that.

When IKE renegotiates I see the following in the log:
Nov/27/2019 19:48:25 ipsec,info endpoint address have changed for active policy
Nov/27/2019 19:48:25 ipsec,info ISAKMP-SA deleted 10.45.240.41[4500]-DATACENTRE-IP[4500] spi:7099b41067981ca9:5ed04b80f6d520bb rekey:1
Nov/27/2019 19:48:35 ipsec,info initiate new phase 1 (Identity Protection): 10.45.240.41[500]<=>DATACENTRE-IP[500]
Nov/27/2019 19:48:35 ipsec,info ISAKMP-SA established 10.45.240.41[4500]-DATACENTRE-IP[4500] spi:402783532deb1c68:87d33a9551dcf7dd

The IKE renegotiation actually seems fine; it correctly figures out I need NAT-T thanks to the way AWS does public IPs; 10.45.240.41 is my public interface on the AWS CHR. But it's being triggered apparently by the mysterious message endpoint address have changed for active policy. What does that mean? Endpoint addresses are not changing, not that I can see. All IP addresses are static in ROS. Why would an idle connection trigger this message anyway when a busy connection does not? I can't see any timers or other connection settings in the IPSec that might trigger this, so perhaps it's not really an IPSec question at all.

The AWS CHR is running 6.45.7 and here's the configuration:
/ip ipsec profile
add dh-group=modp1024 enc-algorithm=aes-256 hash-algorithm=sha256 name=profile_spaceman19nat
/ip ipsec peer
add address=DATACENTRE-IP/32 name=ipsecPeer_man-net-rt1 profile=profile_spaceman19nat
/ip ipsec proposal
add enc-algorithms=aes-256-cbc name=policy_spaceman19
/ip ipsec identity
add peer=ipsecPeer_man-net-rt1 secret=SHAREDSECRET
/ip ipsec policy
add dst-address=DATACENTRE-IP/32 level=unique peer=ipsecPeer_man-net-rt1 proposal=policy_spaceman19 protocol=gre \
    src-address=0.0.0.0/0

The private datacentre CHR is running 6.42.10 so the config is a little different:
/ip ipsec proposal
add enc-algorithms=aes-256-cbc name=policy_1
/ip ipsec peer
add address=AWS-IP/32 comment=AWS-NET-RT1 dh-group=modp1024 \
    enc-algorithm=aes-256 hash-algorithm=sha256 secret=SHAREDSECRET
/ip ipsec policy
add comment=AWS-NET-RT1 dst-address=AWS-IP/32 level=unique proposal=\
    policy_1 protocol=gre src-address=DATACENTRE-IP/32

Thanks for any pointers.

Giles.
 
gilester
just joined
Topic Author
Posts: 5
Joined: Sat Feb 01, 2014 1:07 pm

Re: AWS CHR IPSec: IKE constantly renegotiating new phase 1  [SOLVED]

Wed Dec 04, 2019 11:41 pm

Hi

I realised that while ROS 6.45.7 doesn't allow you to specify the source address for a transport mode IPSec policy, you can specify the local address against the peer definition.

Doing that has stopped the CHR apparently thinking the source address of the IPSec connection has changed and tearing down the SA. My connection has remained stable for 24 hours since making the alteration.

Giles

Who is online

Users browsing this forum: No registered users and 53 guests