Project

General

Profile

Issue #2262

Install routes for trap policies of transport mode tunnels with IPv6 when several usable IPs exist (management and temporary one)

Added by Noel Kuntze almost 4 years ago. Updated almost 4 years ago.

Status:
Closed
Priority:
Normal
Category:
configuration
Affected version:
5.5.1
Resolution:
No change required

Description

Right now, charon doesn't install a source route to the remote part of the TS
when it installs a trap policy for a transport mode tunnel on IPv6.
When there are several IPs that could be usable to reach the remote host, like
a management IP and a temporary IP, that inevitably leads to some application
using the wrong source IP to reach the remote host and therefore its traffic
to not being trapped and protected by IPsec. Charon should install a corresponding
source route to the remote host into table 220 to avoid that.
I tested this solution by manually adding a correct source route into table 220
and that fixed the problem.

History

#1 Updated by Tobias Brunner almost 4 years ago

  • Status changed from New to Feedback

Right now, charon doesn't install a source route to the remote part of the TS
when it installs a trap policy for a transport mode tunnel on IPv6.

Correct, it currently doesn't install any routes for transport mode policies. As they are usually not required for these scenarios (to reach the other peer the host needs a route anyway).

When there are several IPs that could be usable to reach the remote host, like
a management IP and a temporary IP, that inevitably leads to some application
using the wrong source IP to reach the remote host and therefore its traffic
to not being trapped and protected by IPsec.

Wouldn't that indicate that either your policy is wrong (or insufficient) or that the application selects the wrong IP? You might also want to have a look at charon.prefer_temporary_addrs in case you didn't specify any specific local address/TS.

#2 Updated by Noel Kuntze almost 4 years ago

When there are several IPs that could be usable to reach the remote host, like
a management IP and a temporary IP, that inevitably leads to some application
using the wrong source IP to reach the remote host and therefore its traffic
to not being trapped and protected by IPsec.

Wouldn't that indicate that either your policy is wrong (or insufficient) or that the application selects the wrong IP? You might also want to have a look at charon.prefer_temporary_addrs in case you didn't specify any specific local address/TS.

Well, the application is ping, charon.prefer_temporary_addrs is not set and I didn't set a local_addrs. I guess charon prefers the management IPv6 address then and ping a temporary one. Would setting local_ts = ::/0 work with that? What about link-local addresses? And would transport mode then still work? Probably not, right? I ideally want to protect all traffic to that remote IPv6 address using a transport mode CHILD_SA.

#3 Updated by Tobias Brunner almost 4 years ago

I guess charon prefers the management IPv6 address then and ping a temporary one.

Why guess if you can read the documentation of the option and perhaps a bit about the automatic IPv6 source address selection. Or just try it out by changing the option. ;-)

Would setting local_ts = ::/0 work with that? What about link-local addresses? And would transport mode then still work? Probably not, right?

If you use the current master, which includes da82786b2d, you should be able to use that.

#4 Updated by Noel Kuntze almost 4 years ago

Tobias Brunner wrote:

Would setting local_ts = ::/0 work with that? What about link-local addresses? And would transport mode then still work? Probably not, right?

If you use the current master, which includes da82786b2d, you should be able to use that.

I understood this comment as such, that setting local_ts = ::/0 with mode = transport would make the trap policy match on any local address. However, it doesn't do that. charon still installs a policy for the locally chosen IP and the remote's IP address. I guess you didn't mean that then, right?

I'm using 5.5.2, of course.

#5 Updated by Tobias Brunner almost 4 years ago

Would setting local_ts = ::/0 work with that? What about link-local addresses? And would transport mode then still work? Probably not, right?

If you use the current master, which includes da82786b2d, you should be able to use that.

I understood this comment as such, that setting local_ts = ::/0 with mode = transport would make the trap policy match on any local address. However, it doesn't do that. charon still installs a policy for the locally chosen IP and the remote's IP address. I guess you didn't mean that then, right?

No, you have to trigger the wildcard trap code by not setting a single remote address (you can set it to <remote ip>/128, though, as that is interpreted as subnet) and set remote_ts to <remote IP>/128. Then local_ts may be ::/0. If the configured remote addresses resolve to a specific IP the local address is set to the IP that may be used to reach that remote (that's where charon.prefer_temporary_addrs comes into play). These addresses are then used when deriving the policies from the configured traffic selectors. Interestingly, before da82786b2d ::/0 might actually have been installed even then, as TS were only narrowed to IPs if they were dynamic.

#6 Updated by Noel Kuntze almost 4 years ago

Okay, now using ping gets a CHILD_SA in transport mode up when using remote_addrs=%any (or not setting it), setting leftsubnet=::/0 and rightsubnet=::/remote-address/128.

It works with both addresses. Great. :)

#7 Updated by Tobias Brunner almost 4 years ago

  • Category set to configuration
  • Status changed from Feedback to Closed
  • Assignee set to Tobias Brunner
  • Resolution set to No change required

OK, great.

Also available in: Atom PDF