Project

General

Profile

Issue #2411

VPN server name resolution is done via overlay DNS server upon IKE disconnect

Added by Eyal Birger about 3 years ago. Updated about 3 years ago.

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

Description

When a Strongswan client receives a DELETE from the server, if the child SA is still up, it tries
to resolve the server DNS name using the DNS server provisioned by the VPN server (the 'overlay' DNS server).

This fails when the overlay DNS server does not have the record for the underlay VPN gateway.

History

#1 Updated by Tobias Brunner about 3 years ago

  • Status changed from New to Feedback

When a Strongswan client receives a DELETE from the server, if the child SA is still up, it tries
to resolve the server DNS name using the DNS server provisioned by the VPN server (the 'overlay' DNS server).

Delete for the IKE or the CHILD_SA? Why exactly is a DNS resolution triggered while the DNS server is still installed (closeaction maybe?)? Could you provide logs?

This fails when the overlay DNS server does not have the record for the underlay VPN gateway.

There might not be much we can do about this. On Linux only one DNS server can be installed currently, so if you receive one via IKE make sure it can resolve your server IP to e.g. do make-before-break reauthentication or for other situations the server's host name has to be resolved while the SA is up.

#2 Updated by Eyal Birger about 3 years ago

Delete for the IKE or the CHILD_SA? Why exactly is a DNS resolution triggered while the DNS server is still installed (closeaction maybe?)? Could you provide logs?

Sorry - delete of the IKE. child SA is still up for a little while.
closeaction is set to 'restart'

charon[4427]: 09[NET] received packet: from <SERVER_GOOD_IP>[4500] to <LOCAL_IP>[4500] (76 bytes)
charon[4427]: 09[ENC] parsed INFORMATIONAL request 0 [ D ]
charon[4427]: 09[IKE] received DELETE for IKE_SA q[1]
charon[4427]: 09[IKE] deleting IKE_SA q[1] between <LOCAL_IP>[<CLIENT_SUBJECT>]...<SERVER_GOOD_IP>[<SERVER_ID>]
charon[4427]: 09[IKE] deleting IKE_SA q[1] between <LOCAL_IP>[<CLIENT_SUBJECT>]...<SERVER_GOOD_IP>[<SERVER_ID>]
charon[4427]: 09[IKE] installing new virtual IP <CLIENT_IP>
charon[4427]: 09[IKE] restarting CHILD_SA q
charon[4427]: 09[IKE] initiating IKE_SA q[2] to <SERVER_BAD_IP>
charon[4427]: 09[IKE] initiating IKE_SA q[2] to <SERVER_BAD_IP>
charon[4427]: 09[ENC] generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) ]
charon[4427]: 09[NET] sending packet: from <LOCAL_IP>[500] to <SERVER_BAD_IP>[500] (1132 bytes)
charon[4427]: 09[IKE] IKE_SA deleted
charon[4427]: 09[IKE] IKE_SA deleted
charon[4427]: 09[ENC] generating INFORMATIONAL response 0 [ ]
charon[4427]: 09[NET] sending packet: from <LOCAL_IP>[4500] to <SERVER_IP>[4500] (76 bytes)
charon[4427]: 07[IKE] retransmit 1 of request with message ID 0
charon[4427]: 07[NET] sending packet: from <LOCAL_IP>[500] to <SERVER_BAD_IP>[500] (1132 bytes)
charon[4427]: 09[IKE] retransmit 2 of request with message ID 0
charon[4427]: 09[NET] sending packet: from <LOCAL_IP>[500] to <SERVER_BAD_IP>[500] (1132 bytes)
charon[4427]: 13[IKE] retransmit 3 of request with message ID 0
charon[4427]: 13[NET] sending packet: from <LOCAL_IP>[500] to <SERVER_BAD_IP>[500] (1132 bytes)
charon[4427]: 06[IKE] retransmit 4 of request with message ID 0
charon[4427]: 06[NET] sending packet: from <LOCAL_IP>[500] to <SERVER_BAD_IP>[500] (1132 bytes)
charon[4427]: 05[IKE] retransmit 5 of request with message ID 0
charon[4427]: 05[NET] sending packet: from <LOCAL_IP>[500] to <SERVER_BAD_IP>[500] (1132 bytes)
charon[4427]: 11[IKE] giving up after 5 retransmits
charon[4427]: 11[IKE] peer not responding, trying again (2/0)
charon[4427]: 11[IKE] initiating IKE_SA q[2] to <SERVER_GOOD_IP>
charon[4427]: 11[IKE] initiating IKE_SA q[2] to <SERVER_GOOD_IP>

There might not be much we can do about this. On Linux only one DNS server can be installed currently, so if you receive one via IKE make sure it can resolve your server IP to e.g. do make-before-break reauthentication or for other situations the server's host name has to be resolved while the SA is up.

Problem is that the DNS server in the overlay is not able to return the proper result.
One example is when the underlay VPN gateway is selected using client geo-location. It is problematic to implement the underlay DNS logic in the overlay DNS server.

#3 Updated by Tobias Brunner about 3 years ago

Sorry - delete of the IKE. child SA is still up for a little while.

That's not related to the CHILD_SA. DNS servers are a property of the IKE_SA if anything. And since restarting creates the new IKE_SA overlapping with the existing one (to copy information to it) the installed DNS server is still used. Not sure if it is possible to uninstall that before the hostname is resolved (and what side-effects this would have).

There might not be much we can do about this. On Linux only one DNS server can be installed currently, so if you receive one via IKE make sure it can resolve your server IP to e.g. do make-before-break reauthentication or for other situations the server's host name has to be resolved while the SA is up.

Problem is that the DNS server in the overlay is not able to return the proper result.

So it returns an invalid IP (private?)? Why does it return anything at all? (if it didn't the previous IP should be reused, could obviously still be problematic if the IP changed, but that might trigger another resolution later depending on the configured keying tries)

One example is when the underlay VPN gateway is selected using client geo-location. It is problematic to implement the underlay DNS logic in the overlay DNS server.

I guess. So try not returning an IP for that hostname instead of an unusable one when the request comes from a VPN client's virtual IP.

#4 Updated by Eyal Birger about 3 years ago

So it returns an invalid IP (private?)? Why does it return anything at all? (if didn't the previous IP should be reused, could obviously still be problematic if the IP changed, but that might trigger another resolution later depending on the configured keying tries)
I guess. So try not returning an IP for that hostname instead of an unusable one when the request comes from a VPN client's virtual IP.

Indeed it returns a private IP. I can try to disable it as a workaround. though, that may have the side effect you mentioned, no? (i.e. "make-before-break reauthentication or for other situations the server's host name has to be solved while the SA is up")

Doesn't it make sense for the resolution to always be done via the underlay DNS server? why are there ever cases where the overlay DNS record is relevant?

#5 Updated by Tobias Brunner about 3 years ago

Indeed it returns a private IP. I can try to disable it as a workaround. though, that may have the side effect you mentioned, no? (i.e. "make-before-break reauthentication or for other situations the server's host name has to be solved while the SA is up")

For make-before-break reauthentication the same applies as for reestablishment (i.e. the previous IP is used), so I guess that should be fine. Regarding the other side-effect, I'm not sure. But if this is solely a client it's probably not that much of an issue as most resolutions happen as responder (to find matching configs). But if you have multiple IKE_SAs with virtual IPs and DNS server you can't do anything about that as there will probably always be a custom DNS server installed.

Doesn't it make sense for the resolution to always be done via the underlay DNS server? why are there ever cases where the overlay DNS record is relevant?

As I said, the system (perhaps more specifically glibc's resolver) can only use one DNS server at a time. So there is no way to use a different server when resolving host names. There is also no concept of overlay/underlay DNS server, there is simply a different DNS server installed than was before when one is received via config payload, which is then used for any name resolution (split-DNS is also not possible with the current resolver, unless you do it with a local DNS proxy that perhaps supports that, but that would require a plugin or updown script in strongSwan that handles the installation there). The only way to use a specific, configurable DNS server would be to implement DNS resolution manually or via third-party library (e.g. libunbound).

#6 Updated by Eyal Birger about 3 years ago

Ok. So will try working around this. Thanks!

Also available in: Atom PDF