iked.conf insanity (passing traffic locally between two tunneled subnets)

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

iked.conf insanity (passing traffic locally between two tunneled subnets)

Daniel Ouellet
Hi,

I have two separate subnets (on different interfaces) on a router. I am
trying to tunnel both subnets over the internet to another router on my
network. I can tunnel one subnet easily and everything works as
expected, but when I tunnel the 2nd subnet, then traffic from one local
subnet is no longer forwarded to the other subnet, but is
unconditionally sent into the ipsec tunnel, bypassing the routing table.
Traffic flows between the two subnets as expected when iked is disabled.

I thought I should be able to use config like this:

ikev2 "VPN" active esp inet from re0 to tunnel.realconnect.com
ikev2 "Flow" active \
        from re1 to tunnel.realconnect.com \
        from re1 to stats.realconnect.com \
        from 66.63.44.66 to 0.0.0.0/0 \
        from 66.63.44.67 to 66.63.0.0/18 \
        from 66.63.44.67 to christine-home.realconnect.com \
        from home.ouellet.us to 0.0.0.0/0 \
        from 66.63.44.96/27 to 0.0.0.0/0 \
        peer tunnel.realconnect.com

but then I get the problem described above, where traffic stops flowing
between the local subnets - machines on subnet 66.63.44.96/27 (behind
re1) cannot talk to machines on 66.63.44.64/27 (behind re1) - the
traffic is unconditionally sent to enc0 instead.

To get this to work, I've had to configure each flow to cover the entire
ipv4 space except for the two local subnets. This gets even uglier,
because doing so results in lines which are apparently too long to
parse, and iked refuses to start unless I break it into multiple smaller
flows.

Horrific (but working) config below:


ikev2 "VPN" active esp inet from re0 to tunnel.realconnect.com

ikev2 "Flow" active \
        from re1 to tunnel.realconnect.com \
        from re1 to stats.realconnect.com \
        from 66.63.44.66 to 0.0.0.0/2 \
        from 66.63.44.66 to 64.0.0.0/8 \
        from 66.63.44.66 to 65.0.0.0/8 \
        from 66.63.44.66 to 66.0.0.0/11 \
        from 66.63.44.66 to 66.32.0.0/12 \
        from 66.63.44.66 to 66.48.0.0/13 \
        from 66.63.44.66 to 66.56.0.0/14 \
        from 66.63.44.66 to 66.60.0.0/15 \
        from 66.63.44.66 to 66.62.0.0/16 \
        from 66.63.44.66 to 66.63.0.0/19 \
        from 66.63.44.66 to 66.63.32.0/21 \
        from 66.63.44.66 to 66.63.40.0/22 \
        from 66.63.44.66 to 66.63.44.0/26 \
        from 66.63.44.66 to 66.63.44.128/25 \
        from 66.63.44.66 to 66.63.45.0/24 \
        from 66.63.44.66 to 66.63.46.0/23 \
        from 66.63.44.66 to 66.63.48.0/22 \
        from 66.63.44.66 to 66.63.52.0/22 \
        from 66.63.44.66 to 66.63.56.0/21 \
        from 66.63.44.66 to 66.64.0.0/10 \
        from 66.63.44.66 to 66.128.0.0/9 \
        from 66.63.44.66 to 67.0.0.0/8 \
        from 66.63.44.66 to 68.0.0.0/6 \
        from 66.63.44.66 to 72.0.0.0/5 \
        from 66.63.44.66 to 80.0.0.0/4 \
        from 66.63.44.66 to 96.0.0.0/3 \
        from 66.63.44.66 to 128.0.0.0/1 \
        from 66.63.44.67 to 66.63.0.0/19 \
        from 66.63.44.67 to 66.63.32.0/21 \
        from 66.63.44.67 to 66.63.40.0/22 \
        from 66.63.44.67 to 66.63.44.0/26 \
        from 66.63.44.67 to 66.63.44.128/25 \
        from 66.63.44.67 to 66.63.45.0/24 \
        from 66.63.44.67 to 66.63.46.0/23 \
        from 66.63.44.67 to 66.63.48.0/22 \
        from 66.63.44.67 to 66.63.52.0/22 \
        from 66.63.44.67 to 66.63.56.0/21 \
        from 66.63.44.67 to christine-home.realconnect.com \
        peer tunnel.realconnect.com

ikev2 "Flow2" active \
        from home.ouellet.us to 0.0.0.0/2 \
        from home.ouellet.us to 64.0.0.0/8 \
        from home.ouellet.us to 65.0.0.0/8 \
        from home.ouellet.us to 66.0.0.0/11 \
        from home.ouellet.us to 66.32.0.0/12 \
        from home.ouellet.us to 66.48.0.0/13 \
        from home.ouellet.us to 66.56.0.0/14 \
        from home.ouellet.us to 66.60.0.0/15 \
        from home.ouellet.us to 66.62.0.0/16 \
        from home.ouellet.us to 66.63.0.0/19 \
        from home.ouellet.us to 66.63.32.0/21 \
        from home.ouellet.us to 66.63.40.0/22 \
        from home.ouellet.us to 66.63.44.0/26 \
        from home.ouellet.us to 66.63.44.128/25 \
        from home.ouellet.us to 66.63.45.0/24 \
        from home.ouellet.us to 66.63.46.0/23 \
        from home.ouellet.us to 66.63.48.0/22 \
        from home.ouellet.us to 66.63.52.0/22 \
        from home.ouellet.us to 66.63.56.0/21 \
        from home.ouellet.us to 66.64.0.0/10 \
        from home.ouellet.us to 66.128.0.0/9 \
        from home.ouellet.us to 67.0.0.0/8 \
        from home.ouellet.us to 68.0.0.0/6 \
        from home.ouellet.us to 72.0.0.0/5 \
        from home.ouellet.us to 80.0.0.0/4 \
        from home.ouellet.us to 96.0.0.0/3 \
        from home.ouellet.us to 128.0.0.0/1 \
        peer tunnel.realconnect.com

ikev2 "Flow3" active \
        from 66.63.44.96/27 to 0.0.0.0/2 \
        from 66.63.44.96/27 to 64.0.0.0/8 \
        from 66.63.44.96/27 to 65.0.0.0/8 \
        from 66.63.44.96/27 to 66.0.0.0/11 \
        from 66.63.44.96/27 to 66.32.0.0/12 \
        from 66.63.44.96/27 to 66.48.0.0/13 \
        from 66.63.44.96/27 to 66.56.0.0/14 \
        from 66.63.44.96/27 to 66.60.0.0/15 \
        from 66.63.44.96/27 to 66.62.0.0/16 \
        from 66.63.44.96/27 to 66.63.0.0/19 \
        from 66.63.44.96/27 to 66.63.32.0/21 \
        from 66.63.44.96/27 to 66.63.40.0/22 \
        from 66.63.44.96/27 to 66.63.44.0/26 \
        from 66.63.44.96/27 to 66.63.44.128/25 \
        from 66.63.44.96/27 to 66.63.45.0/24 \
        from 66.63.44.96/27 to 66.63.46.0/23 \
        from 66.63.44.96/27 to 66.63.48.0/22 \
        from 66.63.44.96/27 to 66.63.52.0/22 \
        from 66.63.44.96/27 to 66.63.56.0/21 \
        from 66.63.44.96/27 to 66.64.0.0/10 \
        from 66.63.44.96/27 to 66.128.0.0/9 \
        from 66.63.44.96/27 to 67.0.0.0/8 \
        from 66.63.44.96/27 to 68.0.0.0/6 \
        from 66.63.44.96/27 to 72.0.0.0/5 \
        from 66.63.44.96/27 to 80.0.0.0/4 \
        from 66.63.44.96/27 to 96.0.0.0/3 \
        from 66.63.44.96/27 to 128.0.0.0/1 \
        peer tunnel.realconnect.com


With this configuration it does work as desired, but is this really the
only way to make it work???

And this is only for a setup with 3 interfaces, but when you need to do
it with 12 interfaces and multiple subnets, it becomes almost impossible
to not make mistakes unless I were to generate this nasty config from a
script or something.

There must be a better way....

It would be useful if iked.conf could use pf-like syntax, such as:

    { 192.0.2.0/24, !192.0.2.5 }

or even better yet if it would just play nice with the routing table and
not try to send traffic to enc0 if the destination is a local subnet
reachable via another interface.

Can anyone suggest a way to be able to use a more sensible configuration
as shown at the start somehow?

This would be greatly appreciated.

Many thanks for any clue stick if one exist.

Daniel

PS: I don't understand iked.conf's "skip" rule attribute. Why would you
want to use it? How is adding "skip" to a rule different from commenting
out or deleting that rule?

Reply | Threaded
Open this post in threaded view
|

Re: iked.conf insanity (passing traffic locally between two tunneled subnets)

Stuart Henderson
On 2019-01-10, Daniel Ouellet <[hidden email]> wrote:
> I have two separate subnets (on different interfaces) on a router. I am
> trying to tunnel both subnets over the internet to another router on my
> network. I can tunnel one subnet easily and everything works as
> expected, but when I tunnel the 2nd subnet, then traffic from one local
> subnet is no longer forwarded to the other subnet, but is
> unconditionally sent into the ipsec tunnel, bypassing the routing table.

OpenBSD's implementation of ipsec doesn't use the routing table, if you
want that (unless you make code changes) you will need to use a
different tunnel interface (gif or others) and just use ipsec to protect
the gif traffic.

> Traffic flows between the two subnets as expected when iked is disabled.
>
> I thought I should be able to use config like this:
>
> ikev2 "VPN" active esp inet from re0 to tunnel.realconnect.com
> ikev2 "Flow" active \
>         from re1 to tunnel.realconnect.com \
>         from re1 to stats.realconnect.com \
>         from 66.63.44.66 to 0.0.0.0/0 \
>         from 66.63.44.67 to 66.63.0.0/18 \
>         from 66.63.44.67 to christine-home.realconnect.com \
>         from home.ouellet.us to 0.0.0.0/0 \
>         from 66.63.44.96/27 to 0.0.0.0/0 \
>         peer tunnel.realconnect.com
>
> but then I get the problem described above, where traffic stops flowing
> between the local subnets - machines on subnet 66.63.44.96/27 (behind
> re1) cannot talk to machines on 66.63.44.64/27 (behind re1) - the
> traffic is unconditionally sent to enc0 instead.
>
> To get this to work, I've had to configure each flow to cover the entire
> ipv4 space except for the two local subnets. This gets even uglier,
> because doing so results in lines which are apparently too long to
> parse, and iked refuses to start unless I break it into multiple smaller
> flows.

Sounds like you want bypass flows for 66.63.44.96/27 <> 66.63.44.64/27.
IIRC you can still use ipsecctl/ipsec.conf to configure them even
with iked running (the only bypass flows iked will add itself are the
automatic "mess with v6 traffic" ones, there's no iked.conf way to do
this flexibly).

Reply | Threaded
Open this post in threaded view
|

Re: iked.conf insanity (passing traffic locally between two tunneled subnets)

Daniel Ouellet
> OpenBSD's implementation of ipsec doesn't use the routing table, if you
> want that (unless you make code changes) you will need to use a
> different tunnel interface (gif or others) and just use ipsec to protect
> the gif traffic.

The point is to keep the configuration simple and gif doesn't make it
so. But when the source is with changing IP's often it end up not being
very possible is it...

So not really an option.

May be time to check wireguard instead then. But not having it into the
kernel or fully mature yet on OpenBSD is also limiting.

> Sounds like you want bypass flows for 66.63.44.96/27 <> 66.63.44.64/27.
> IIRC you can still use ipsecctl/ipsec.conf to configure them even
> with iked running (the only bypass flows iked will add itself are the
> automatic "mess with v6 traffic" ones, there's no iked.conf way to do
> this flexibly).

The point of ikev2 was to keep things simple and light. Doing the full
ipsec even doable is really a real pain in the butts.

As you saw I can make ikev2 works as is. Yes I hate how I have to do it,
but I can make it work. I was really hoping that may be something I
didn't think of or a different work around the limitation was possible
and someone might get a different idea.

I thought that may be with rdomain it might be a way to bypass the issue
with ikev2, nut I must admit my limitation on rdomain didn't offer me a
solution there either.

If my solution is to use gif/ipsec oppose to my ugly ikev2 ways, I will
stick with the ugly one. Kiss served me well over the year and I will
not use a more complicated solution.

Never the less thanks for your time and consideration to even have read
my email Stuart, I appreciated it!

Daniel