Hi
I am creating a container which uses iptables and specifically focuses on utilizing TPROXY (https://www.kernel.org/doc/Documentation/networking/tproxy.txt) but am not able to add any of the Iptable rules inside the docker environment (I connect to it using running shell).
I was curious about the RUN mode of dockers inside RouterOS. Are containers launched with “–privileged” and “–cap-add=NET_ADMIN” ?
Any ideas how to use Iptables and Tproxy inside a docker container on the Routeros?
Thanks 
RouterOS doesn’t use Docker.
I think it uses LXC or a derivitive. Open to correction here.
AFAIK there is no equivalent to the option “–privileged”. The ability to gain root on the router is something Mikrotik guards against, so --privileged isn’t likely.
Similarly, with NET_ADMIN, RouterOS doesn’t allow a container direct access to system ethernet devices – traffic goes through the VETH only. NET_ADMIN would allow access to ALL interfaces, not just the VETH.
Any suggestions on how to create a docker container for Routeros which supports iptables and it’s modules including tproxy?!
Routeros firewall itself does not allow something similar to tproxy, or does it?!
I don’t know much about the TOR ecosystem. But you can use VLANs on the VETH to a container. Say two VLANs on VETH:
one VLAN can be the IN traffic and one VLAN can be OUT traffic.
But the TOR software in the conatain have to be setup to use that kinda scheme. Dunno know if possible.
TOR?!
Tproxy is https://www.kernel.org/doc/Documentation/networking/tproxy.txt …
LOL. Wrong container. Same answer. MT don’t allow root things in containers. So no NET_ADMIN or --privilege
Mikrotik has suggest some TAP/TUN support in future. It’s a tricky because they are trying to avoiding a compromised container from hacking the router. With those options, that be trivial.
I blame the @fakeusername2022 username for my mistake 
One step forward…
I listed all exposed Kernel modules from RouterOS to a running container (as you know containers do not have any Linux Kernel and depend JUST on the host kernel. Therefore, just the loaded Kernel Modules of the main RouterOS kernel is available to them).
So here is the output. Others might find this interesting:
lsmod
Module Size Used by
chacha20poly1305 16384 0
esp6 20480 0
ah6 16384 0
esp4 20480 2
ah4 16384 0
camellia_generic 32768 0
twofish_generic 20480 0
twofish_common 24576 1 twofish_generic
sch_rate 16384 51
sch_pcq 20480 4
ip6_tables 24576 0
imq 16384 0
cls_linear 20480 8 imq
cls_fw 20480 1 imq
sch_htb 28672 4
wireguard 65536 0
ip6_udp_tunnel 16384 1 wireguard
udp_tunnel 20480 1 wireguard
curve25519_x86_64 40960 1 wireguard
libcurve25519_generic 49152 2 curve25519_x86_64,wireguard
libchacha20poly1305 16384 1 wireguard
poly1305_x86_64 28672 1 libchacha20poly1305
chacha_x86_64 28672 1 libchacha20poly1305
libchacha 16384 1 chacha_x86_64
libblake2s 16384 1 wireguard
blake2s_x86_64 20480 1 libblake2s
libblake2s_generic 20480 1 blake2s_x86_64
veth 20480 0
iptable_raw 16384 1
ipt_SAME 16384 0
xt_NETMAP 16384 0
xt_REDIRECT 16384 0
xt_MASQUERADE 16384 3
xt_nat 16384 9
iptable_nat 16384 1
iptable_mangle 16384 2
ipt_TARPIT 16384 0
ipt_REJECT 16384 0
nf_reject_ipv4 16384 1 ipt_REJECT
iptable_filter 16384 1
nf_defrag_ipv4 16384 0
ipt_psd 16384 0
ip_tables 24576 4 iptable_filter,iptable_raw,iptable_nat,iptable_mangle
ipt_snif 16384 0
snif 16384 1 ipt_snif
ipt_ulog 16384 2
xt_tls 16384 2
xt_layer7 20480 0
xt_HL 16384 0
xt_DSCP 16384 0
xt_TCPMSS 16384 1
xt_CT 16384 0
xt_policy 16384 0
xt_addrtype 16384 6
xt_hl 16384 0
xt_realm 16384 0
xt_physdev 16384 0
xt_length 16384 0
xt_connbytes 16384 0
xt_helper 16384 0
xt_tcpmss 16384 0
xt_dscp 16384 0
xt_hashlimit 20480 0
xt_statistic 16384 0
xt_string 16384 2
xt_connmark 16384 15
xt_conntrack 16384 0
xt_multiport 16384 10
xt_mark 16384 14
xt_mac 16384 0
xt_tcpudp 16384 5
ts_kmp 16384 2
vmxnet3 45056 0
xt_misc 20480 42
x_tables 24576 41 xt_dscp,ipt_psd,xt_conntrack,xt_statistic,iptable_filter,ipt_SAME,xt_multiport,xt_length,xt_string,xt_tcpudp,xt_DSCP,xt_tcpmss,xt_hashlimit,xt_addrtype,xt_physdev,xt_nat,ipt_snif,xt_layer7,xt_helper,xt_NETMAP,xt_policy,ip6_tables,xt_HL,xt_mac,xt_tls,ipt_TARPIT,ipt_ulog,ipt_REJECT,xt_connmark,xt_CT,xt_realm,iptable_raw,ip_tables,xt_hl,xt_misc,xt_MASQUERADE,iptable_mangle,xt_TCPMSS,xt_REDIRECT,xt_mark,xt_connbytes
nf_conntrack_ipv4 16384 0
des3_ede_x86_64 40960 0
nf_nat 28672 6 ipt_SAME,xt_nat,xt_NETMAP,iptable_nat,xt_MASQUERADE,xt_REDIRECT
des_generic 16384 0
nf_conntrack_netlink 28672 0
libdes 24576 2 des_generic,des3_ede_x86_64
nfnetlink 16384 1 nf_conntrack_netlink
sha512_ssse3 45056 0
sstp 45056 1
sha256_ssse3 32768 1
blowfish_generic 16384 0
blowfish_common 20480 1 blowfish_generic
echainiv 16384 2
ovpn 24576 1
sha1_ssse3 28672 28
l2tp 69632 1
ppp_mppe 16384 0
sha512_generic 16384 1 sha512_ssse3
arc4 16384 0
af_key 28672 4
bridge2_netfilter 20480 0
libarc4 16384 1 arc4
sha1_generic 16384 1 sha1_ssse3
wlan 294912 3
xfrm_user 28672 2
vrf 20480 0
ppp_deflate 16384 0
aesni_intel 323584 56
zlib_inflate 20480 1 ppp_deflate
capsmanglue 12288 1 wlan
xfrm_algo 16384 6 esp6,af_key,esp4,ah6,ah4,xfrm_user
zlib_deflate 24576 1 ppp_deflate
ppp_generic 28672 132 l2tp,ppp_mppe,ppp_deflate,sstp
btest 16384 0
glue_helper 16384 1 aesni_intel
lm87 20480 0
hwmon_vid 16384 1 lm87
ledgroup 20480 0
tun 32768 0
slhc 16384 0
crypto_simd 16384 1 aesni_intel
cryptd 16384 29 crypto_simd
ulog 16384 2 ipt_ulog
bridge2 118784 1 bridge2_netfilter
switch 45056 1 bridge2
phy_helper 45056 1 switch
packet_hook 131072 18 bridge2,l2tp,switch,xt_layer7,wlan,vmxnet3,xt_misc
tunnel6 16384 1 packet_hook
nf_conntrack 73728 14 xt_conntrack,nf_conntrack_ipv4,nf_nat,packet_hook,xt_nat,xt_helper,xt_NETMAP,nf_conntrack_netlink,xt_connmark,xt_CT,xt_misc,xt_MASQUERADE,xt_REDIRECT,xt_connbytes
jiffies 16384 61
softdog 16384 2
wdat_wdt 16384 0
ipv6 299008 166 bridge2,l2tp,vrf,esp6,packet_hook,ovpn,bridge2_netfilter,ah6,wireguard
nf_defrag_ipv6 16384 2 nf_conntrack,ipv6
logring 40960 202
unix 32768 334
ALSO as per Linux Kernel documentation:
Iptables and nf_tables extensions
To use tproxy you’ll need to have the following modules compiled for iptables:NETFILTER_XT_MATCH_SOCKET
NETFILTER_XT_TARGET_TPROXY
Or the floowing modules for nf_tables:
NFT_SOCKET
NFT_TPROXY
So I think it is impossible to have a container on RouterOS which utilizes the “TPROXY” target for its purposes. Maybe Mikrotik Dev team will consider loading these modules into the RouterOS Kernel to provide the flexibility and functionality required by some containers.
P.S.
These are the above mentioned modules which are found on my VM running Ubuntu LTS:
root@ubuntu-lts-hyperv:~# locate NETFILTER_XT_MATCH_SOCKET NETFILTER_XT_TARGET_TPROXY NFT_SOCKET NFT_TPROXY
/usr/src/linux-headers-5.15.0-60-generic/include/config/NETFILTER_XT_MATCH_SOCKET
/usr/src/linux-headers-5.15.0-60-generic/include/config/NETFILTER_XT_TARGET_TPROXY
/usr/src/linux-headers-5.15.0-60-generic/include/config/NFT_SOCKET
/usr/src/linux-headers-5.15.0-60-generic/include/config/NFT_TPROXY
Great info. That actually make me feel better – you shouldn’t have been able to .
Totally get the need – it’s a router & now “software extendable” with containers SO yes that custom software (e.g. containers) might want to access the raw interfaces directly.
I think they’re taking it slow, to let the current features settle in first. /container is perfectly usable for “services” (e.g. one veth interface is fine for that). But for SDN/“packet processing things” – this where you want a lot more options to intact with network interfaces themselves. Whether it be a straight mapping to the Docker options --privilege, NET_ADMIN stuff, or something different, dunno. But MT had to have thought about the future SDN-like use cases for their containers.
It would be nice to have a TPROXY module in the mikrotik kernel.
But for now we have to use REDIRECT only for TCP traffic, without UDP support.
Tproxy is a task for a physical machine or a VM not for RouterOS.
It will not work anyway on any container as far as I can tell unless it uses the device network.