Project

General

Profile

Issue #3283

IKE Multi Interface Issue

Added by Krishnamurthy Daulatabad 15 days ago. Updated 5 days ago.

Status:
Feedback
Priority:
Normal
Assignee:
-
Category:
-
Affected version:
5.7.1
Resolution:

Description

We are running IKE on 2 network interfaces, eth0 and eth0:1. Our requirement is to use eth0:1 for all IKE SAs for which we are configured as responders. For initiator case, we want to use interface eth0. This is working for us mostly. But in one case, we are seeing a problem when an initiator is trying to establish an SA to the server. This is sequence of events:
1. Initiator established IKE SA and Child SA using address on eth0:1 (Initiators only know this address in our case. They DONT know address on eth0 at all)
2. After roughly 6 seconds, there was a change in SA detected, the SRC IP on responder outbound SA got changed to eth0 address (Dst IP on initiator outbound also changed to eth0 address)

The main question is how can this happen? Is this triggered by a packet from server to client with SRC ip as eth0 address?
Ideally responder will always reply back using eth0:1 interface address to all packets from initiator and Client has no way to know the eth0 address.
Is there any case where responder will send packet using eth0 address?
This has happened couple of times in our setup. But unfortunately we don't have packet capture when this happened.

Here is the log on responder :

2019-11-27T06:05:41.0+0000 09[IKE] <client_nuc1|7912> CHILD_SA client_nuc1{45} established with SPIs 270084fb_i 2fc67e20_o and TS 5.182.214.126/32 === 192.168.8.81/32
2019-11-27T06:05:41.0+0000 09[ENC] <client_nuc1|7912> splitting IKE message (1760 bytes) into 2 fragments
2019-11-27T06:05:46.0+0000 07[IKE] <client_nuc1|7912> retransmit 1 of request with message ID 0
2019-11-27T06:05:47.0+0000 05[MGR] ignoring request with ID 2, already processing
2019-11-27T06:05:47.0+0000 04[IKE] <client_nuc1|7912> local host is behind NAT, sending keep alives
2019-11-27T06:05:47.0+0000 15[IKE] <client_nuc1|7912> local host is not behind NAT anymore

We are using the configuration below:

client_nuc1: , no reauthentication, no rekeying
local: %any
remote: %any
local unspecified authentication:
id: server_ln1
certs: O=SRV_NUC, CN=server_ln1
remote unspecified authentication:
id: client_nuc1
server_ln1: TUNNEL, rekeying every 3600s
local: dynamic
remote: 0.0.0.0/0

History

#1 Updated by Noel Kuntze 15 days ago

  • Status changed from New to Feedback
  • Priority changed from Urgent to Normal

Aliases are not real interfaces.

The list of information required that is shown on the HelpRequests page is not a joke. We need all of that in order to tell you what and why exactly something happens.

#2 Updated by Krishnamurthy Daulatabad 15 days ago

Unfortunately, we have lost the logs of the IKE from the start time (logging is limited and overwritten now).

We use dynamic configuration on IKE using VICI (we have a separate agent for this). So no swanctl.conf or ipsec.conf . Have sent the swanctl --list-conns output above

We run IKE on linux (Ubuntu 16.04 based), but our datapath is not in kernel. We have a separate datapath which is configured by IKE using a plugin similar to kernel_pfkey or kernel_netlink(). We don't use any firewall, iptables configuration here.

Please let me know if you need any other information from my end.

#3 Updated by Tobias Brunner 15 days ago

The main question is how can this happen?

MOBIKE

Is this triggered by a packet from server to client with SRC ip as eth0 address?

Read the logs for details.

Ideally responder will always reply back using eth0:1 interface address to all packets from initiator and Client has no way to know the eth0 address.

Then maybe configure the local address and disable MOBIKE.

2019-11-27T06:05:47.0+0000 04[IKE] <client_nuc1|7912> local host is behind NAT, sending keep alives
2019-11-27T06:05:47.0+0000 15[IKE] <client_nuc1|7912> local host is not behind NAT anymore

What's that about? Is the client roaming around? Then you probably want to enable MOBIKE, and you then have to live with the fact that the server is reachable on multiple addresses (any configured local addresses are currently not considered when sending additional addresses to the peer via MOBIKE).

#4 Updated by Krishnamurthy Daulatabad 15 days ago

Tobias Brunner wrote:

The main question is how can this happen?

MOBIKE

Is this triggered by a packet from server to client with SRC ip as eth0 address?

Read the logs for details.

Ideally responder will always reply back using eth0:1 interface address to all packets from initiator and Client has no way to know the eth0 address.

Then maybe configure the local address and disable MOBIKE.

2019-11-27T06:05:47.0+0000 04[IKE] <client_nuc1|7912> local host is behind NAT, sending keep alives
2019-11-27T06:05:47.0+0000 15[IKE] <client_nuc1|7912> local host is not behind NAT anymore

What's that about? Is the client roaming around? Then you probably want to enable MOBIKE, and you then have to live with the fact that the server is reachable on multiple addresses (any configured local addresses are currently not considered when sending additional addresses to the peer via MOBIKE).

No Client is not roaming. From the logs above and looking at the code, I guess the reason for "local host is not behind NAT anymore" decision is due to the initiator responding to server on a different address (than original exchanged packets), that is eth0 address. Is that possible? This is possible in our setup ONLY if server had sent a packet to initiator with SRC Ip as eth0 address ( We are doubting some retransmit packet possibly, as we see some retransmits in the logs before this issue happened).

Normally we only see server sending out packets with eth0:1 interface IP on which it gets requests. So we wanted to know when this SRC ip can change when transmitting packets?

We have MOBIKE enabled , we see these messages in the log "2019-11-27T06:13:53.0+0000 10[IKE] <7921> peer supports MOBIKE"

#5 Updated by Tobias Brunner 12 days ago

From the logs above and looking at the code,

Not sure what logs you are looking at, but if you mean the few lines you posted, that doesn't show much.

I guess the reason for "local host is not behind NAT anymore" decision is due to the initiator responding to server on a different address (than original exchanged packets), that is eth0 address. Is that possible?

Sure.

So we wanted to know when this SRC ip can change when transmitting packets?

The source address is selected based on the routes, it might be a different one than you sent the packet to. However, by default (i.e. if charon.prefer_best_path is disabled in strongswan.conf) the currently used or configured address is kept if the routes indicate in can be used to reach the peer.

#6 Updated by Krishnamurthy Daulatabad 12 days ago

Tobias Brunner wrote:

From the logs above and looking at the code,

Not sure what logs you are looking at, but if you mean the few lines you posted, that doesn't show much.

I guess the reason for "local host is not behind NAT anymore" decision is due to the initiator responding to server on a different address (than original exchanged packets), that is eth0 address. Is that possible?

Sure.

So we wanted to know when this SRC ip can change when transmitting packets?

The source address is selected based on the routes, it might be a different one than you sent the packet to. However, by default (i.e. if charon.prefer_best_path is disabled in strongswan.conf) the currently used or configured address is kept if the routes indicate in can be used to reach the peer.

In our case prefer_best_path is disabled. Basically our requirement is to have IKE responder to always use eth0:1 address while responding to client requests. As IKE initiator we would always want to use eth0 address to establish sessions with peers. I guess this can be achieved by setting "local_addrs" parameter in the swanctl.conf configuration. Is that right?

#7 Updated by Tobias Brunner 10 days ago

I guess this can be achieved by setting "local_addrs" parameter in the swanctl.conf configuration. Is that right?

Probably, but the routes and other stuff also matters.

#8 Updated by Krishnamurthy Daulatabad 5 days ago

Tobias Brunner wrote:

I guess this can be achieved by setting "local_addrs" parameter in the swanctl.conf configuration. Is that right?

Probably, but the routes and other stuff also matters.

Is there any way to bind the IKE socket to a particular interface so that interface address is always chosen as the SRC ip in the outgoing packet?

#9 Updated by Tobias Brunner 5 days ago

Is there any way to bind the IKE socket to a particular interface so that interface address is always chosen as the SRC ip in the outgoing packet?

No. But you can ignore packets from specific interfaces (charon.interfaces_* strongswan.conf options). These are global options, though, and changing them obviously has no effect if the IP addresses are on the same interface (as Noel said, eth0:1 is not a separate interface, see #309).

Also available in: Atom PDF