IKEDv2 and alias addresses

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

IKEDv2 and alias addresses

Sonic
With IKEDv1 I was able to use alias addresses for the VPN tunnels with
a Listen-on directive in isakmpd.conf:
======================
[General]
Listen-on=      1.2.3.7
======================

So far my attempts with IKEDv2 have been unsuccessful at using alias
addresses. Is it possible?

Thanks!

Chris

Reply | Threaded
Open this post in threaded view
|

Re: IKEDv2 and alias addresses

Stuart Henderson
On 2020-06-19, Sonic <[hidden email]> wrote:
> With IKEDv1 I was able to use alias addresses for the VPN tunnels with
> a Listen-on directive in isakmpd.conf:
>======================
> [General]
> Listen-on=      1.2.3.7
>======================
>
> So far my attempts with IKEDv2 have been unsuccessful at using alias
> addresses. Is it possible?

Not without modifying the code.


Reply | Threaded
Open this post in threaded view
|

Re: IKEDv2 and alias addresses

Patrick Wildt-3
In reply to this post by Sonic
On Fri, Jun 19, 2020 at 11:19:11AM -0400, Sonic wrote:

> With IKEDv1 I was able to use alias addresses for the VPN tunnels with
> a Listen-on directive in isakmpd.conf:
> ======================
> [General]
> Listen-on=      1.2.3.7
> ======================
>
> So far my attempts with IKEDv2 have been unsuccessful at using alias
> addresses. Is it possible?
>
> Thanks!
>
> Chris

iked(8) listens on all addresses.  It binds on 0.0.0.0:500 and receives
all IKE messages that arrive, unless there's an isakmpd(8) runnin on the
same address.  Thus there's no need to specify an additional address,
because it's already listening on all addresses.

If you want to use a specific address for a policy, you can use the
"local" keyword to specify it.  This is part of the policy, not a global
option.

Then iked(8) continues to losten on 0.0.0.0:500, but the policy will
only match if the IP address match to the one specified as "local".

Patrick

Reply | Threaded
Open this post in threaded view
|

Re: IKEDv2 and alias addresses

Sonic
On Sun, Jun 21, 2020 at 12:11 PM Patrick Wildt <[hidden email]> wrote:
> If you want to use a specific address for a policy, you can use the
> "local" keyword to specify it.  This is part of the policy, not a global
> option.
>
> Then iked(8) continues to losten on 0.0.0.0:500, but the policy will
> only match if the IP address match to the one specified as "local".

My config is basically:
Remote:
=======================
local_gw="a.b.c.164"
local_net="172.20.28.0/23"
server_gw="x.y.z.45"
server_net="172.26.62.0/23"
state="active"

ikev2 'remote_rsa' $state esp \
        from $local_net to $server_net \
        local $local_gw peer $server_gw \
        dstid server.example.com
=======================
Server:
=======================
local_gw="x.y.z.45"
local_net="172.26.62.0/23"
remote_gw="a.b.c.164"
remote_net="172.20.28.0/23"
state="passive"

ikev2 'server_rsa' $state esp \
        from $local_net to $remote_net \
        local $local_gw peer $remote_gw \
        srcid server.example.com
=======================

Both outside nets are /29's and the .164 and .45 are aliases, with
.161 and .41 being the main address. However in trouble shooting I
kept seeing information moving on the main addresses and my pf.conf
rules were configured for the alias addresses.

Being new to ikev2 setup I may have this all wrong.

Thanks!

Reply | Threaded
Open this post in threaded view
|

Re: IKEDv2 and alias addresses

Stuart Henderson
On 2020-06-21, Sonic <[hidden email]> wrote:
> On Sun, Jun 21, 2020 at 12:11 PM Patrick Wildt <[hidden email]> wrote:
>> If you want to use a specific address for a policy, you can use the
>> "local" keyword to specify it.  This is part of the policy, not a global
>> option.
>>
>> Then iked(8) continues to losten on 0.0.0.0:500, but the policy will
>> only match if the IP address match to the one specified as "local".

IIRC "local" isn't enough, some packets are still sent on the bound
0.0.0.0, the kernel chooses the source address (based on the local
interface address in the route to the destination) and it can be
the wrong address for the other side.

It's been a while since I tried and I don't remember which packets
were involved.

> My config is basically:
> Remote:
>=======================
> local_gw="a.b.c.164"
> local_net="172.20.28.0/23"
> server_gw="x.y.z.45"
> server_net="172.26.62.0/23"
> state="active"
>
> ikev2 'remote_rsa' $state esp \
>         from $local_net to $server_net \
>         local $local_gw peer $server_gw \
>         dstid server.example.com
>=======================
> Server:
>=======================
> local_gw="x.y.z.45"
> local_net="172.26.62.0/23"
> remote_gw="a.b.c.164"
> remote_net="172.20.28.0/23"
> state="passive"
>
> ikev2 'server_rsa' $state esp \
>         from $local_net to $remote_net \
>         local $local_gw peer $remote_gw \
>         srcid server.example.com
>=======================
>
> Both outside nets are /29's and the .164 and .45 are aliases, with
> .161 and .41 being the main address. However in trouble shooting I
> kept seeing information moving on the main addresses and my pf.conf
> rules were configured for the alias addresses.
>
> Being new to ikev2 setup I may have this all wrong.
>
> Thanks!
>
>

phessler ran into this as well. He was able to work around it by
forcing it to use the correct source address by adding an -ifa route.
I'm not sure exactly the order you'll need but try some things along
these lines:

route add -host x.y.z.45 $gateway -ifa a.b.c.164

This is one of various reasons why I stick with isakmpd/ikev1 for
lan-to-lan tunnels and just use ikev2 for single-host clients.


Reply | Threaded
Open this post in threaded view
|

Re: IKEDv2 and alias addresses

Sonic
On Sun, Jun 21, 2020 at 5:20 PM Stuart Henderson <[hidden email]> wrote:
>
> IIRC "local" isn't enough, some packets are still sent on the bound
> 0.0.0.0, the kernel chooses the source address (based on the local
> interface address in the route to the destination) and it can be
> the wrong address for the other side.

I believe that is what I saw. The passive side received packets on the
alias address but when it sent replies they went out the main address
instead.

As I'm getting a /29 via the cable modem which has some extra ports
and in some cases my openbsd firewalls also have extra ports, so
instead of bringing all 5 addresses into one port maybe configuring a
different interface with one of the aliases as its only address could
work, but I believe it would need to be in a different rdomain. Which
may be, in the end, a more elegant solution. Is there any appreciable
overhead using domains like this?

Thanks!

Reply | Threaded
Open this post in threaded view
|

Re: IKEDv2 and alias addresses

Tobias Heider-2
In reply to this post by Sonic
On Sun, Jun 21, 2020 at 04:33:14PM -0400, Sonic wrote:

> On Sun, Jun 21, 2020 at 12:11 PM Patrick Wildt <[hidden email]> wrote:
> > If you want to use a specific address for a policy, you can use the
> > "local" keyword to specify it.  This is part of the policy, not a global
> > option.
> >
> > Then iked(8) continues to losten on 0.0.0.0:500, but the policy will
> > only match if the IP address match to the one specified as "local".
>
> My config is basically:
> Remote:
> =======================
> local_gw="a.b.c.164"
> local_net="172.20.28.0/23"
> server_gw="x.y.z.45"
> server_net="172.26.62.0/23"
> state="active"
>
> ikev2 'remote_rsa' $state esp \
>         from $local_net to $server_net \
>         local $local_gw peer $server_gw \
>         dstid server.example.com
> =======================
> Server:
> =======================
> local_gw="x.y.z.45"
> local_net="172.26.62.0/23"
> remote_gw="a.b.c.164"
> remote_net="172.20.28.0/23"
> state="passive"
>
> ikev2 'server_rsa' $state esp \
>         from $local_net to $remote_net \
>         local $local_gw peer $remote_gw \
>         srcid server.example.com
> =======================
>
> Both outside nets are /29's and the .164 and .45 are aliases, with
> .161 and .41 being the main address. However in trouble shooting I
> kept seeing information moving on the main addresses and my pf.conf
> rules were configured for the alias addresses.
>
> Being new to ikev2 setup I may have this all wrong.
>
> Thanks!
>

I tried to reproduce your bug (on current) but it seems to work as intended
for me.  It would certainly help to have a bit more info such as an iked log
and a tcpdump of your failed handshake as well as the used openbsd version.

Reply | Threaded
Open this post in threaded view
|

Re: IKEDv2 and alias addresses

Sonic
On Thu, Jun 25, 2020 at 4:10 PM Tobias Heider <[hidden email]> wrote:
> I tried to reproduce your bug (on current) but it seems to work as intended
> for me.  It would certainly help to have a bit more info such as an iked log
> and a tcpdump of your failed handshake as well as the used openbsd version.

The passive side is a much older version. At this point Ikev1 is
working and once I update that box to current I'll most likely test
and, if successful, switch to Watchguard as rumor has it that its
performance is much better.

Thanks for your assistance!

Chris