iptables xt_TEE module on SLES11


We have a customer running SLES11 SP2 on a server where we need to do some traffic redirection tricks. Specifically we need to redirect incoming UDP stream to several different hosts on the same LAN, in addition to receiving it on the original host. I was hoping to use iptables TEE extension for this, which worked fine on my own machine with another distribution:

iptables -t mangle -A PREROUTING -i $interface -p udp -d $myip --dport $port -j TEE --gateway $otherhost1
iptables -t mangle -A PREROUTING -i $interface -p udp -d $myip --dport $port -j TEE --gateway $otherhost2

However, when I tried to run the same commands on SLES, I discovered that the necessary xt_TEE kernel module is not available on SLES11 SP2. I quickly installed some virtual machines with SLES11 SP3 and SLES11 SP4 and found that this module is also not present there. I tried SLE12 next, and in that version the module is present and everything works.

Of course, SLES11 SP2 is quite old, but having to tell the customer “you need to upgrade to SLE12” is somewhat heavy. Is there an easier way to get the necessary xt_TEE module into the existing SLES11 SP2?

Unless you were to check the kernel source and compile the modules from
there, I do not know of any other way. If the kernel source in SLES 11
does not have that code, then you may need to compile from another version
of the source, though all of this is pretty risky for an enterprise
distribution since the focus there is on stability more than the ability
to tweak everything in untested ways via custom compilation.

If they are on SLES 11 SP2, I presume they are out of support and
no-longer receiving official patches/maintenance. Perhaps they could
setup a SLES 12 SP2 box to test things out and see if it is worth their
while to get a new subscription. Updates will only work for sixty (or is
it ninety?) days, but they’re already used to not having updates regularly
it would seem.

Another option may be to go with openSUSE Leap (42.1, or 42.2 as of
tomorrow) which is based on the SLE 12 codebase and while not mean to be
used in the enterprise long-term, it is still based on that same stable
base. The lifecycle of Leap is shorter than SLE, so if they opted for
this long-term they’d potentially be changing out boxes more-often to stay

Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below…