Project

General

Profile

Issue #1326

Android client NAT keep alive interval

Added by Daniel Lipovetsky over 2 years ago. Updated about 1 year ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
-
Affected version:
5.3.5
Resolution:
Fixed

Description

The NAT keep-alive interval of the Android client is shorter than I would like. The client's log view does not include timestamps, but I estimate the interval to be around 30 seconds.

As noted the response to issue #297:

NAT keep-alives are not negotiated, therefore you can't change the behavior of the client with a server setting

From this I understand that setting

charon.keep_alive
on the server side will not affect the interval on which the client sends keep-alive packets.

Is there an existing method to set the keep-alive interval of the Android client?

(I am using the Android client provided on the Google Play store, version 1.5.0.)


P.S. If there is not an existing method to set the keep-alive interval, I am happy to contribute a pull request. I am not familiar with the code base, and will have questions. Would

src/main/jni/libandroidbridge/charonservice.c
be a good place to pass the option to charon?

Associated revisions

Revision 73a6bec3 (diff)
Added by Tobias Brunner over 2 years ago

android: Increase the NAT-T keepalive interval to potentially save battery life

In case this doesn't work out we could probably make it configurable.

References #1326.

History

#1 Updated by Tobias Brunner over 2 years ago

  • Status changed from New to Feedback

The NAT keep-alive interval of the Android client is shorter than I would like. The client's log view does not include timestamps, but I estimate the interval to be around 30 seconds.

What's the problem you have with the current interval? NAT keep-alives are sent every 20 seconds if there has not been any outbound traffic (IKE or ESP). That's to keep NAT mappings on routers/firewalls between client and server alive.

For many current routers 20 seconds is probably a bit on the low side (e.g. Linux uses 180 seconds as default timeout for established UDP endpoints), but since we can't know or control what intermittent devices a client may encounter that's the default recommended by RFC 3948.

Making this configurable in the app isn't really difficult, but users might be confused by the setting.

#2 Updated by Daniel Lipovetsky over 2 years ago

I have no problem with the current interval of 20 seconds in general. As you say, it may be somewhat conservative, but it is the recommended default.

On the other hand, I expect an increase in the interval to correspond to a decrease in battery use. Having the option to increase the interval would allow me to make a trade-off between battery use and connection timeout.

There is a tool to empirically estimate the NAT timeout (see http://jsharkey.org/blog/2012/09/22/deploying-a-pure-ipsec-pki-vpn-server-for-android-devices/). The tool's author used it to estimate the timeout for 3 major cellular networks in the United States: the timeouts ranged from 60 to 120 seconds. The test is from 2012 and the estimates are out of date. I plan to estimate the timeout on my own cellular network and, if I my estimate is significantly longer than 20 seconds, I would like to increase the interval on the strongswan Android client.

I defer to you about whether or not users will be confused by the setting. The MTU and Server port settings are visible but are set to "(use default)" by default. Do you think users be confused if there were a third setting named, e.g., "Client-side NAT timeout" set to the same "(use default)" value?

#3 Updated by Tobias Brunner over 2 years ago

The next version of the app will increase the default NAT-T keepalive interval to 45 seconds (see associated commit).

#4 Updated by Daniel Lipovetsky over 2 years ago

Thank you for trying a longer default timeout. I'm using the new version of the client, but I can't yet report on battery life impact. All I will have is anecdotal evidence, anyway, but since the default interval has been slightly more than doubled, I expect to notice the impact if it is there.

#5 Updated by Noel Kuntze about 1 year ago

  • Status changed from Feedback to Closed
  • Resolution set to Fixed

Also available in: Atom PDF