Netfilter, IPVLAN, L3S and NAT64

Netfilter, IPVLAN, L3S and NAT64

[Rob Ert]

Hello all,

I need IPv4 connectivity for my particular ipvlan server setup and was
hoping someone might be able to help.  My grasp of the subject matter
is too limited, but more knowledgeable people are telling me that
NAT64 will be difficult if not impossible to get working with ipvlan:

https://mail-lists.nic.mx/pipermail/jool-list/2023-December/000498.html

I am a little reluctant to do away with my ipvlan setup (described in
the link above), as it works very well, albeit minus IPv4 connectivity
:-).

Since “Tundra-NAT64” is designed as a translator for one host, I was
thinking, maybe NAT64 could be realized with Tundra-NAT64 running
inside the individual systemd-nspawn containers as an alternative to
setting up full dual-stack IPv6 and IPv4-rfc1918 with masquerading for
the individual containers? I can install Tundra-NAT64 in a
systemd-nspawn container with the following systemd.nspawn overrides:

[Exec]
PrivateUsers=off
Timezone=off
Capability=CAP_NET_BIND_SERVICE CAP_NET_RAW CAP_NET_ADMIN CAP_SYS_NICE
CAP_CHOWN CAP_IPC_LOCK

[Network]
IPVLAN=enp1s0

I would rather not keep these overrides in production, but I assume if
it works with the overrides, it can be set up beforehand with
systemd-networkd without overrides.

According to the documentation, ipvlan in L3S mode provides netfilter hooks:

“In L3S mode, virtual devices process the same way as in L3 mode,
except that both egress and ingress traffics of a relevant container
are landed on netfilter chain in the default namespace. L3S mode
behaves in a similar way to L3 mode but provides greater control of
the network.”

I was hoping someone might be able to give me some pointers as to how
to get something like this to work, or tell me definitively that it is
not practically possible; but then, I really don’t understand what L3S
mode is good for.

I am also open to using “Jool” or “Tayga” for NAT64.

Many thanks,
all the best and
Happy Holidays,

Rob

Re: Netfilter, IPVLAN, L3S and NAT64

[Joshua Moore]

Is there a reason you cannot place a router in front of the ipvlan device and make the forwarding decision in the router. If the traffic needs to be ipvlan then send it to the ipvlan device, otherwise NAT64 etc.


> On Dec 21, 2023, at 10:38 AM, Rob Ert <ertr3960@gmail.com> wrote:
> 
> Hello all,
> 
> I need IPv4 connectivity for my particular ipvlan server setup and was
> hoping someone might be able to help.  My grasp of the subject matter
> is too limited, but more knowledgeable people are telling me that
> NAT64 will be difficult if not impossible to get working with ipvlan:
> 
> https://mail-lists.nic.mx/pipermail/jool-list/2023-December/000498.html
> 
> I am a little reluctant to do away with my ipvlan setup (described in
> the link above), as it works very well, albeit minus IPv4 connectivity
> :-).
> 
> Since “Tundra-NAT64” is designed as a translator for one host, I was
> thinking, maybe NAT64 could be realized with Tundra-NAT64 running
> inside the individual systemd-nspawn containers as an alternative to
> setting up full dual-stack IPv6 and IPv4-rfc1918 with masquerading for
> the individual containers? I can install Tundra-NAT64 in a
> systemd-nspawn container with the following systemd.nspawn overrides:
> 
> [Exec]
> PrivateUsers=off
> Timezone=off
> Capability=CAP_NET_BIND_SERVICE CAP_NET_RAW CAP_NET_ADMIN CAP_SYS_NICE
> CAP_CHOWN CAP_IPC_LOCK
> 
> [Network]
> IPVLAN=enp1s0
> 
> I would rather not keep these overrides in production, but I assume if
> it works with the overrides, it can be set up beforehand with
> systemd-networkd without overrides.
> 
> According to the documentation, ipvlan in L3S mode provides netfilter hooks:
> 
> “In L3S mode, virtual devices process the same way as in L3 mode,
> except that both egress and ingress traffics of a relevant container
> are landed on netfilter chain in the default namespace. L3S mode
> behaves in a similar way to L3 mode but provides greater control of
> the network.”
> 
> I was hoping someone might be able to give me some pointers as to how
> to get something like this to work, or tell me definitively that it is
> not practically possible; but then, I really don’t understand what L3S
> mode is good for.
> 
> I am also open to using “Jool” or “Tayga” for NAT64.
> 
> Many thanks,
> all the best and
> Happy Holidays,
> 
> Rob
> 

Fwd: Netfilter, IPVLAN, L3S and NAT64

[Rob Ert]

---------- Forwarded message ---------
From: Rob Ert <ertr3960@gmail.com>
Date: Thu, Dec 21, 2023 at 1:08 PM
Subject: Re: Netfilter, IPVLAN, L3S and NAT64
To: Joshua Moore <j@jcm.me>


On Thu, Dec 21, 2023 at 12:43 PM Joshua Moore <j@jcm.me> wrote:
>
> Is there a reason you cannot place a router in front of the ipvlan device and make the forwarding decision in the router. If the traffic needs to be ipvlan then send it to the ipvlan device, otherwise NAT64 etc.
>
>
It's a dual-stack Cloud-VM with 1 IPv4 and an IPv6 /64 subnet as
described in the jool mailing list link above. I have it set up with
IPv6-only systemd-nspawn containerized machine instances using IPVLAN.
Also, I am using WireGuard and Unbound/DNS to realize IPv6
connectivity to the containers and the wider Internet over my
otherwise IPv4-only Internet connection; this setup works very well,
and I am a bit reluctant to do away with IPVLAN, if it is avoidable. I
would like to understand why NAT64 is not doable with IPVLAN L3S mode,
if that is truly the case. I don't think it is possible to integrate a
containerized router with this IPVLAN setup; I believe I would have to
switch to a setup where all the containers are connected over a
virtual bridge.

All the best,
Rob

Re: Netfilter, IPVLAN, L3S and NAT64

[Joshua Moore]

Would have to see a diagram with traffic flows illustrated to understand your use case more.


> On Dec 21, 2023, at 11:14 AM, Rob Ert <ertr3960@gmail.com> wrote:
> 
> ---------- Forwarded message ---------
> From: Rob Ert <ertr3960@gmail.com>
> Date: Thu, Dec 21, 2023 at 1:08 PM
> Subject: Re: Netfilter, IPVLAN, L3S and NAT64
> To: Joshua Moore <j@jcm.me>
> 
> 
>> On Thu, Dec 21, 2023 at 12:43 PM Joshua Moore <j@jcm.me> wrote:
>> 
>> Is there a reason you cannot place a router in front of the ipvlan device and make the forwarding decision in the router. If the traffic needs to be ipvlan then send it to the ipvlan device, otherwise NAT64 etc.
>> 
>> 
> It's a dual-stack Cloud-VM with 1 IPv4 and an IPv6 /64 subnet as
> described in the jool mailing list link above. I have it set up with
> IPv6-only systemd-nspawn containerized machine instances using IPVLAN.
> Also, I am using WireGuard and Unbound/DNS to realize IPv6
> connectivity to the containers and the wider Internet over my
> otherwise IPv4-only Internet connection; this setup works very well,
> and I am a bit reluctant to do away with IPVLAN, if it is avoidable. I
> would like to understand why NAT64 is not doable with IPVLAN L3S mode,
> if that is truly the case. I don't think it is possible to integrate a
> containerized router with this IPVLAN setup; I believe I would have to
> switch to a setup where all the containers are connected over a
> virtual bridge.
> 
> All the best,
> Rob
> 

Re: Netfilter, IPVLAN, L3S and NAT64

[Rob Ert]

On Thu, Dec 21, 2023 at 1:31 PM Joshua Moore <j@jcm.me> wrote:
>
> Would have to see a diagram with traffic flows illustrated to understand your use case more.
>

My setup is as described in Fig1. of the following three page document,
with my WireGuard wg0-tun-device in the default-ns:

"This can be worked-around by assigning one of the
virtual devices to the host and eliminating the
configuration on the master interface, as shown in Fig1."

https://people.netfilter.org/pablo/netdev0.1/papers/IPVLAN-The-beginning.pdf