MikroTik

Posted: **Thu Mar 16, 2023 11:37 pm**

If one does go down the route of using some sort of DNS protection there are many options.

1. USE IPV4 servers from DNS providers that have some decent functionality against ads etc.
These seem to work well but do not provide any granularity into whats is happening with clients etc..... no dashboard LOL.

2. Instead of regular IPV4 servers, use the DOH function within the ROS to better hide I guess traffic request coming and going from the router?
Again no granularity or dashboard.

3. Then we get to other devices, which this thread is focused on, aka the Container/Docker approach.

We have the ability for the router to do DOH, and the router to do a container with adguard/pihole!
Q1. Is it possible to combine BOTH ?
Q2. If not, which is better to implement and why?

(4) Assuming we are going to go ahead with the adguard/pihole on a container/docker approach lets get REAL.
Not the simple cookie cutter examples on youtube that magically describe using this somewhat complex tool with a single bridge and single subnet.
PALEASE...............

(5) Lets at least solve a more typical home/soho MT user that has.
a. single bridge
b. multiple vlans

First problem: Does the container/docker get its own VLAN? Or does it have to be on a separate bridge?
Others: Too numerous to mention as I trip over all of them

(6) Other Assumptions/Problem areas

SEND USERS TO CONTAINER
- firewall rule allow interface-list=LAN dst-address=adguard/pihole IP { allow users to reach adguard/pihole on container }
- dst-nat rules in-interface-list=LAN dst-port=53 protocol=tcp/udp to-address=adguard/pihole IP exclude src-address=adguard/pihole IP { force users to adguard/pihole }
- input chain rules in-interface-list=LAN dst-port=53 protocols=tcp/udp { to give adguard/pihole access to DNS for initial connection }
- ip dhcp server-networks - set ALL vlan DNS server entries to adguard/pihole IP exclude adguard/pihole vlan (it gets same value as the gateway entry)

Note for Admin to configure adguard/pihole
- dst-nat rule dst-address=subnet gateway IP of container to=address=adguard/pihole IP { to reach pihole/adguard via web-browser }

IP DNS entries.
Allow Remote Requests = YES
Add Servers IPV4 to enable adguard pihole to reach its own servers. Should it be the same ones or different ones pihole/adguard uses.

SourceNAT: Nothing special that I am aware of. The docker/container will fall under the standard sourcnat rule ??? If the docker/container is in its own vlan, then no hairpin is required!

(7) What am I missing that I have not considered ( keeping it to ipv4 ).

Posted: **Fri Mar 17, 2023 1:44 am**

If one does go down the route of using some sort of DNS protection there are many options.
[...]

OMG! You may be close to installing the container package...

First problem: Does the container/docker get its own VLAN? Or does it have to be on a separate bridge?
[...]

Let's stick to pi-hole since Mikrotik has docs for that.

First skip creating the "docker" bridge. Why it's in the doc's example IDK. I'd just create the VETH and give it a unique subnet, skip the whole "docker" bridge:

/interface/veth/add name=veth-pihole address=10.10.10.10/24 gateway=10.10.10.1
/ip/address/add address=10.10.10.1/24 interface=veth-pihole

You could do the firewall a lot of ways, the example uses masquerade so if you had multiple VLANs it look like it was coming from the router's address and allow outbound internet access for pi-hole downloads:

/ip/firewall/nat/add chain=srcnat action=masquerade src-address=10.10.10.0/24

If you simply add the VETH to the LAN interface list, you should be able to use 10.10.10.10 as the DNS server anywhere you'd like. This avoid any dst-nat rules being needed.

/interface/list/member add list=LAN interface=veth-pihole

I know you run a tighter firewall than that. So for any container, you can look at its Dockerfile, often they have EXPOSE commands. Mikrotik doesn't NOT use these for anything – a container can listen on ANY port (regardless of what's listed in the Dockerfile0, but ONLY on its container IP address assigned by associated VETH interface. But these can be a guide to what needs to might need to dst-nat'ed to the container IP address, should you not want to allow all ports between the pi-hole container.

e.g. https://github.com/pi-hole/docker-pi-ho ... Dockerfile show pi-hole will listen on these ports:

EXPOSE 53 53/up
EXPOSE 67/up
EXPOSE 80

Unlike built-in service like www (port 80), DNS (port 53) or DHCP (port 67) that listen on ALL interface, a container will ONLY listen on the VETH address assigned to the container. So you may need dst-nat rules for those ports listed EXPOSED, specifically 53, to various VLANs that have drop rules. For something like pi-hole's web GUI you'd NAT dst-nat rule for dst-address=10.10.10.10 dst-port=80, with the allowed input either the IP or interface list for the "MGMT VLAN"

I'd also get the web GUI working before doing anything else with the actual DNS configuration.

That's the quick highlight. I think the key is YOU DO NOT NEED A SEPARATE BRIDGE.

Posted: **Fri Mar 17, 2023 3:29 am**

Thats fine but I have a single bridge with multiple VLANS.
So you are saying create a separate vlan for the docker??

Posted: **Fri Mar 17, 2023 5:23 am**

Thats fine but I have a single bridge with multiple VLANS.
So you are saying create a separate vlan for the docker??

A VETH is kind of like an EOIP interface. If you make it a member of a bridge (and tag it to a particular VLAN's PVID), then you can assign it an IP in the subnet for that bridge (or VLAN).

Or, since it's also just an interface on the router, you can give it an address in a unique subnet and all VLANs that use the router as the gateway will be able to talk directly to it. If desired, you could add a NAT rule to replace a legacy DNS server's address on a particular VLAN.

Posted: **Fri Mar 17, 2023 6:02 am**

Since Mikrotik is steering folks to using one bridge for all containers. To adapt the Mikrotik Pi-Hole example for a vlan-filtering=yes in the @pcunite style... The only two main changes. The rest of Mikrotik's instructions be exactly the same.

One is Create network, it look like this instead:

/interface vlan 
add interface=BR1 name=CONTAINER_VLAN vlan-id=98
/ip address 
add address=172.17.0.1/24 interface=CONTAINER_VLAN

/interface veth
add name=veth-mycontainer address=172.17.0.2/24 gateway=172.17.0.1
/interface bridge port
add bridge=BR1 interface=veth-mycontainer pvid=98

/interface bridge vlan
add bridge=BR1 tagged=BR1 vlan-ids=98

# Mikrotik use masquerade with IP, this may not be needed, but harmless
/ip firewall nat
add chain=srcnat action=masquerade src-address=172.17.0.0/24

# CONTAINER_VLAN should be in an some TBD interface list...
/interface list member 
# if using @pcunite style
add interface=CONTAINER_VLAN  list=BASE
# for the defconf config
add interface=CONTAINER_VLAN  list=LAN

Two, Forward ports to internal Docker is different for vlan-filtering=yes...

Here we'd need to know your firewall rules. In general, with the "Docker" bridge in the "LAN" interface list, you may not need to do anything with the firewall.

You shouldn't need a dst-nat to Pi-Hole's web GUI, assuming your current VLAN can access to the VLAN 98.
Similar if you more complex filter rules, those may need to allow/block...
- tcp to port 80 at 172.17.0.2 - forward should be allowed ONLY from an management vlan

If you go set Pi-Hole via DHCP server for client, and you have restricted VLANs, then also:
- tcp and udp to port 53 at 172.17.0.2 - forward needs to be allowed from ANY VLAN as it's the DNS.
If you use mikrotik DNS in DHCP server, and Mikrotik's DNS servers point to Pi-Hole, Mikrotik's DNS is like allowed by your firewall already.

In either case, the upstream DNS used for client is what ever DNS server is configured in Pi-Hole's web GUI

Pi-Hole does also support acting like a DHCP Server too. I'm not sure is necessary or a good idea on a Mikrotik, especially if you already have working VLANs etc. I'd make sure it's disabled in Pi-Hole's ui – it be better if RouterOS controlled what DNS servers clients use IMO.

Posted: **Fri Mar 17, 2023 9:05 am**

Good stuff here !!

You could do the firewall a lot of ways, the example uses masquerade so if you had multiple VLANs it look like it was coming from the router's address and allow outbound internet access for pi-hole downloads:

DANG ! So that's the reason I only saw my router's IP ... time to evaluate this option again and move that little Pi-bugger from NAS to router again.
(my reason: my router is on 24/7. I'd like to power down my NAS when I know I'm not home. Also, I'm not too happy having network stuff running on a NAS.)

Posted: **Fri Mar 17, 2023 5:55 pm**

Mikrotik's Pi-Hole example isn't great IMO. In their design, the container's IP is always hidden to the rest of the network (e.g. masquerade'd) & the ports exposed by the container (Pi-Hole here) are dst-nat from one/all of router's IP to container. This isn't a bad approach per se (it models what Docker Desktop does for network)... but since RouterOS already has stuff typically running on port 53 and port 80, you'd need have may have to disabl those so a dst-nat from the router's IP/port to the container's IP/port could work for DNS (port 53) and HTTP (port 80) - this need is determine if you want to put the Mikrotik "in front of" Pi-Hole, or just use Pi-Hole as the only DNS (thus disable /ip/dns allow-remote-requests).

By adding an IP address to the VLAN and VETH, you'll get a "connected" network in /ip/routes. So outside of firewall filter rules, the container IP should be routable from the rest of the networks. It's just in a lot of the "all-VLAN" approach you may have drop rules in the firewall filter that block inter-VLAN traffic.

Since the OP that doesn't show his config

... flying blind here. But instead of masquerading+dst-nat'ing the container, you should be able to allow the needed container IP/ports as "accept" in /ip/firewall/filter. A quick fix is to add the VETH (or VLAN) as a "LAN" in /interface/list/member, as that will avoid the !LAN drop rule. But it may be better to just be specific in the IP/port in the "accept" before any inter-VLAN "drop" rules, so again that's port 80 and 53. You can than either
- tell DHCP to use the Pi-Hole container's IP as the DNS server
- OR, change Mikrotik's DNS to use Pi-Hole as it's upstream DNS

In all cases, any DOH can happen inside the Pi-Hole's configuration before going to the internet, but internal LANs DNS still use normal port 53 DNS to either RouterOS or PiHole's DNS server. So you'd like NOT want any DOH server listed in /ip/dns if your using Pi-Hole/etc – let that do the DOH.

Posted: **Fri Mar 17, 2023 6:38 pm**

Lets forget Pi-hole its so yesterday (betamax). Either discuss adguard or blocky for example.

Posted: **Fri Mar 17, 2023 7:02 pm**

FWIW, I'm more supportive of this approach for IP only services... But more food for thought here, than specific recommendations...

Or, since it's also just an interface on the router, you can give it an address in a unique subnet and all VLANs that use the router as the gateway will be able to talk directly to it. If desired, you could add a NAT rule to replace a legacy DNS server's address on a particular VLAN.

I get the "all VLAN" approach, but for stuff that really only does Layer 3/IP stuff, you really don't need ANY bridge. A DNS server container (or web server, storage server, etc) does NOT need Layer2.

So you can also treat VETH IP address more like you would Wireguard instead – you give the each VETH some unique subnet to use, just like you do on for WG interface. Perhaps thinking about the VETH IP as the "WG peer" address, and the gateway address as the "WG interface" address may be more helpful at explaining this approach. So what you use as the gateway address in the VETH for a container, is what you'd set in /ip/address for the VETH. And the IP/subnet you use for VETHs should be one you are NOT using elsewhere in your network.

A DNS Server (or most container) only "EXPOSE" a few IP ports. So in some ways this make the firewall configuration maybe easier, since you can refer use the VETH as the src-interface or dst-interface (or it's IP address) in your firewall rules. The indirection of any bridge makes the firewall rules a tad more complex IMO.

But you may want to do this since it make the "all VLAN" config consistent, at the expense of slightly more complex firewall rules. So not wrong a design to run all contiainer's VETH's through the main vlan-filtering=yes bridge as bridge ports.

And since some container do need Layer 2, and those need to be some bridge. That be another arguement for just always using a new VLAN for each container, since it provide consistency. If we take another example, like the netinstall container here: viewtopic.php?t=189485 that does needs to be in a bridge, since need to bridge some physical port with the netinstall container for it to work! And those instructions can be adapted similarly to a PVID and bridge port, instead of create a separate bridge. And you'd adapt the above Pi-Hole example, to create some VLAN 97 for a netinstall container.

And some container may even NEED to be on a vlan-filtering=yes bridge. For example, the various mDNS proxy container – these need to listen for multicast on MULTIPLE VLANs, so the container needs to be configured as a TRUNK port to do so & inside the container it's actually VLAN aware (most container are NOT VLAN aware, so they act as access ports). See here: viewtopic.php?p=985190&hilit=mdns+container#p985190

Posted: **Fri Mar 17, 2023 7:56 pm**

Lets forget Pi-hole its so yesterday (betamax). Either discuss adguard or blocky for example.

Since I'm 100% positive you can figure out any firewall needs. I'm an agnostic guy, but pi-hole is pretty porky and perhaps dated. Never heard of Blocky:
https://0xerr0r.github.io/blocky/installation/

In theory, that's just changing Mikrotik's Pi-Hole example to use a different image name, "spx01/blocky", mounts and env.. And the networking options for VETH are now well described – pick your poison there.

Blocky look interesting, but it requires you to creating mount(s), and then likely use ROSE or SMB to allow editing of the files (e.g. blocky's config.yaml here) within the mount as well.

See Blocky using a YAML configuration file it seems, so not a web UI to edit. So you need to wired up the container's mount to your desktop to edit the files... You'd still need to decide how you'd want that work, while they have "reference configuration" here: https://0xerr0r.github.io/blocky/v0.20/configuration/ – it's complex.
So getting the container part working is only the first step, you'd have to decide how you want Blocky to work... They support a lot of things around white/black lists, and those all require creating additional mount points.

Further, Blocky maps a specific file config.yaml in a mount in their example. You cannot do that in RouterOS – only directories can be mounts – so you'd need use a different directory in the mount, like /app/config, then use their BLOCKY_CONFIG_FILE as container env a value of /app/config/config.yaml & have a mount used by Blocky container with "dst=/app/config" (and you'd place your edited config.yaml in the src=... of that same container mount). Basically you'd have to learn more about mounts with container to use it.

FWIW, I'd really recommend you'd start with the Cloudflare ZeroTrust as your "first" container... It's a lot simplier – since all of the DNS container require decisions on how you want DNS handled on top of some container basics. And Blocky likely entail also learning the new ROSE package to better be able to deal with all the files/mounts used by Blocky. Or enabling /ip/smb to allow access to the container's mount. And then there is whole editing YAML and Blocky config commands. Quite the commitment....

In short, Blocky be a very complex example.

Posted: **Fri Mar 17, 2023 8:10 pm**

Cloudflare container is a good suggestion for anav.
Then he would be completely prepared on all ins and outs when the ATP package becomes available to educate all us mere mortals.
viewtopic.php?p=989786&hilit=ATP#p989785

Posted: **Fri Mar 17, 2023 8:33 pm**

I feel like a shill in his "cloudflare zerotrust as a TILE package" campaign. e.g. see how difficult containers are!!!

But it's DNS that makes this complex! (And Mikrotik showing a bridge when one isn't really needed IMO).

Posted: **Fri Mar 17, 2023 11:14 pm**

Yes but AMMO clearly MT and others are pushing the idea of a separate bridge just for containers but I prefer a separate VLAN for each service/functionality.

Posted: **Sat Mar 18, 2023 12:38 am**

Agreed — if you're using vlan-filtering=yes, then the "new VLAN per container" approach makes TOTAL sense – "if you go VLAN, go all the way!!!" (to paraphrase you, sans color/font). It's the half-way house in Mikrotik's example that does more harm than good.

But your becoming the poster child for problematic posters

...
- no config!
- no diagram!
- changing/unclear requirements!
- XY problem!

So are we past the /system/device-mode and setting the container registry stuff?

p.s. oh, and cross-posting: viewtopic.php?t=194302#p990440 - (although in fairness that's discussing how a generic container get it's DNS)

Posted: **Sat Mar 18, 2023 5:49 pm**

Lets forget Pi-hole its so yesterday (betamax). Either discuss adguard or blocky for example.

How is Pi-hole so yesterday?

Blocky uses the very same hosts file as PiHole and Adguard is very hit and miss IMO ....

Pi-Hole does what it supposed to do BUT its not an end-user Tool ... meaning that it must be paid attention too [understood] plus it works much better when installed on a Raspberry 4+ due to a better CPU.

Key POINT ... Tik allow Containers to run under their ARM devices but TIK do not update the Docker binary as quickly as they should so IMO NOT a good way to use 3rd party stuff to augment your deficiencies when updates are lagging ... IN actual fact the very same thing can said for Tik and Linux .... which means that Tik developers cannot keep up with the changes.

Posted: **Sat Mar 18, 2023 7:16 pm**

I'm using Pi-hole and Unbound as recursive resolver for some time in containers. So far so good, still, local recursive resolver has side effect - slower dns responses when host is not in cache, depends on quality of internet connection and MT device performance.

dns-diag.png

Posted: **Sat Mar 18, 2023 9:16 pm**

TIK do not update the Docker binary as quickly as they should so IMO NOT a good way to use 3rd party stuff

It is ARM only, and that is annoying. But there is NO "Docker binary" to update. It's essential a soup'ed up "choot" that uses the OCI container format, and chroot been same for 40+ years.
And it's unclear what issues you're actually run into...

Posted: **Sat Mar 18, 2023 9:20 pm**

I'm using Pi-hole and Unbound as recursive resolver for some time in containers. So far so good, still, local recursive resolver has side effect - slower dns responses when host is not in cache, depends on quality of internet connection and MT device performance.

Mind sharing how you setup the firewall and bridging? That seem to be the sticking point here.

Posted: **Sat Mar 18, 2023 9:50 pm**

And to the point, if it aint vlans ( and one or more bridges ) not interested.

Posted: **Sat Mar 18, 2023 10:10 pm**

I'm using Pi-hole and Unbound as recursive resolver for some time in containers. So far so good, still, local recursive resolver has side effect - slower dns responses when host is not in cache, depends on quality of internet connection and MT device performance.
Mind sharing how you setup the firewall and bridging? That seem to be the sticking point here.

Router config

Posted: **Sat Mar 18, 2023 10:32 pm**

And it's unclear what issues you're actually run into...

My bad Amm0 … not binary —- but refer to viewtopic.php?p=985966&hilit=Docker+update#p985966

Posted: **Fri May 19, 2023 3:04 am**

I was searching for blocky with MikroTik, and came across this topic...

I wanted to use blocky over PiHole due to blocky's native DoH support, whereas PiHole needs an additional binary (CloudFlared) for DoH (and probably not possible on the MT?)...

Regardless - it seems like running either blocky or PiHole (or any container for that matter?) on the MikroTik is probably more hassle than it's worth? -- Increased complexities with decreased performance, compared to a dedicated server or RPi - is this a fair assumption to make?

Posted: **Fri May 19, 2023 3:56 am**

Dont necessarily agree. If the load is not signifcant to the router, doesnt slow other traffic down, why not.
Why should DNS be any slower one way or the other////

Posted: **Fri May 19, 2023 11:17 pm**

Regardless - it seems like running either blocky or PiHole (or any container for that matter?) on the MikroTik is probably more hassle than it's worth? -- Increased complexities with decreased performance, compared to a dedicated server or RPi - is this a fair assumption to make?

Depends on device, I have Pi-Hole and Unbound in different containers (Pi-Hole uses Unbound recursive as upstream DNS), 40 Firewall rules, 124 mangle rules, 39 queue tree rules, working every day from home, at evening mostly streaming torrents, etc...:

average_cpu.png

Posted: **Wed Jul 05, 2023 3:04 pm**

I'm trying to do this on my CCR2116, the Pi-Hole works fine, but the Unbound doesn't, it doesn't resolve domain names and I don't know why.

----------------------------------------------
santi@santi-NUC:~$ dig google.com @192.168.4.3 -p 5353

; <<>> DiG 9.18.12-0ubuntu0.22.04.2-Ubuntu <<>> google.com @192.168.4.3 -p 5353
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 54933
;; flags: qr rd ad; QUERY: 0, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; Query time: 0 msec
;; SERVER: 192.168.4.3#5353(192.168.4.3) (UDP)
;; WHEN: Wed Jul 05 13:59:10 CEST 2023
;; MSG SIZE rcvd: 12
----------------------------------------------

192.168.4.3 is the veth IP of the Unbound container, logically.
It doesn't matter if you configure port 5353 or 53 on Unbound, the result is the same.

Can you tell me exactly how you have it configured?
I know you've shared your setup, but it's hard for someone like me to parse it.
In such a setup I also can't see what containers they are using for what.

For example, for my CCR2116, for Pi-Hole I am using:

remote-image=pihole/pihole:latest

I'm using Pi-hole and Unbound as recursive resolver for some time in containers. So far so good, still, local recursive resolver has side effect - slower dns responses when host is not in cache, depends on quality of internet connection and MT device performance.
dns-diag.png

Posted: **Wed Jul 05, 2023 7:22 pm**

;; WARNING: recursion requested but not available

This is an error from unbound, you will need to configure it to work as recursive resolver. Maybe just do-not-query-localhost setting is just causing problem (https://serverfault.com/questions/69909 ... works-fine) in your configuration, it needs to be configured to no value.
But there also other stuff that needs to be configured, depends on your neeeds and device resources. I'm using mvance/unbound-rpi:latest docker image in my ROS container with modified unbound.conf:

server:
    cache-max-ttl: 86400
    cache-min-ttl: 0
    directory: "/opt/unbound/etc/unbound"
    edns-buffer-size: 1232
    interface: 0.0.0.0@53
    do-ip4: yes
    do-udp: yes
    do-tcp: yes
    do-ip6: no
    prefer-ip6: no
    rrset-roundrobin: yes
    username: "_unbound"
    log-local-actions: no
    log-queries: no
    log-replies: no
    log-servfail: no
    logfile: /opt/unbound/etc/dev/null
    verbosity: 0
    aggressive-nsec: yes
    delay-close: 10000
    do-daemonize: no
    do-not-query-localhost: no
    neg-cache-size: 4M
    qname-minimisation: yes
    access-control: 127.0.0.1/32 allow
    access-control: 192.168.0.0/16 allow
    access-control: 172.16.0.0/12 allow
    access-control: 10.0.0.0/8 allow
    auto-trust-anchor-file: "var/root.key"
    root-hints: "/dns/root.hints"
    chroot: "/opt/unbound/etc"
    deny-any: yes
    harden-algo-downgrade: yes
    harden-below-nxdomain: yes
    harden-dnssec-stripped: yes
    harden-glue: yes
    harden-large-queries: yes
    harden-referral-path: no
    harden-short-bufsize: yes
    hide-http-user-agent: no
    hide-identity: yes
    hide-version: yes
    http-user-agent: "DNS"
    identity: "DNS"
    private-address: 10.0.0.0/8
    private-address: 172.16.0.0/12
    private-address: 192.168.0.0/16
    private-address: 169.254.0.0/16
    private-address: fd00::/8
    private-address: fe80::/10
    ratelimit: 1000
    tls-cert-bundle: /etc/ssl/certs/ca-certificates.crt
    unwanted-reply-threshold: 10000
    use-caps-for-id: no
    val-clean-additional: yes
    infra-cache-slabs: 2
    incoming-num-tcp: 10
    key-cache-slabs: 2
    msg-cache-size: 32m
    msg-cache-slabs: 2
    num-queries-per-thread: 4096
    num-threads: 3
    outgoing-range: 8192
    rrset-cache-size: 64m
    rrset-cache-slabs: 2
    minimal-responses: yes
    prefetch: yes
    prefetch-key: yes
    serve-expired: yes
    so-reuseport: yes
    include: /opt/unbound/etc/unbound/a-records.conf
    include: /opt/unbound/etc/unbound/srv-records.conf
remote-control:
    control-enable: no

You have more resources in CCR2116 so you can optimize configuration for your device, like increase threads count, cache memory sizes, etc... See unbound configuration documentation https://nlnetlabs.nl/documentation/unbo ... ound.conf/

Posted: **Wed Jul 05, 2023 9:46 pm**

This Unbound (remote-image=mvance/unbound-rpi:latest) works perfectly for me, I have used all the lines of the configuration that you shared, which refer to Unbound, logically adapting them to the configuration of my CCR2116.

But I haven't even used the "unbound.conf" customization. It works for me directly once the container is created.

The Unbound container is for ARM architecture, but it works perfectly on the ARM64 of the CCR2116.

Could you tell me which container is the Linux you have installed?

And the Shadowsocks?

And if they would work on 64bit architecture.

Thank you very much for your help !!!

;; WARNING: recursion requested but not available

This is an error from unbound, you will need to configure it to work as recursive resolver. Maybe just do-not-query-localhost setting is just causing problem (https://serverfault.com/questions/69909 ... works-fine) in your configuration, it needs to be configured to no value.
But there also other stuff that needs to be configured, depends on your neeeds and device resources. I'm using mvance/unbound-rpi:latest docker image in my ROS container with modified unbound.conf:

server:
    cache-max-ttl: 86400
    cache-min-ttl: 0
    directory: "/opt/unbound/etc/unbound"
    edns-buffer-size: 1232
    interface: 0.0.0.0@53
    do-ip4: yes
    do-udp: yes
    do-tcp: yes
    do-ip6: no
    prefer-ip6: no
    rrset-roundrobin: yes
    username: "_unbound"
    log-local-actions: no
    log-queries: no
    log-replies: no
    log-servfail: no
    logfile: /opt/unbound/etc/dev/null
    verbosity: 0
    aggressive-nsec: yes
    delay-close: 10000
    do-daemonize: no
    do-not-query-localhost: no
    neg-cache-size: 4M
    qname-minimisation: yes
    access-control: 127.0.0.1/32 allow
    access-control: 192.168.0.0/16 allow
    access-control: 172.16.0.0/12 allow
    access-control: 10.0.0.0/8 allow
    auto-trust-anchor-file: "var/root.key"
    root-hints: "/dns/root.hints"
    chroot: "/opt/unbound/etc"
    deny-any: yes
    harden-algo-downgrade: yes
    harden-below-nxdomain: yes
    harden-dnssec-stripped: yes
    harden-glue: yes
    harden-large-queries: yes
    harden-referral-path: no
    harden-short-bufsize: yes
    hide-http-user-agent: no
    hide-identity: yes
    hide-version: yes
    http-user-agent: "DNS"
    identity: "DNS"
    private-address: 10.0.0.0/8
    private-address: 172.16.0.0/12
    private-address: 192.168.0.0/16
    private-address: 169.254.0.0/16
    private-address: fd00::/8
    private-address: fe80::/10
    ratelimit: 1000
    tls-cert-bundle: /etc/ssl/certs/ca-certificates.crt
    unwanted-reply-threshold: 10000
    use-caps-for-id: no
    val-clean-additional: yes
    infra-cache-slabs: 2
    incoming-num-tcp: 10
    key-cache-slabs: 2
    msg-cache-size: 32m
    msg-cache-slabs: 2
    num-queries-per-thread: 4096
    num-threads: 3
    outgoing-range: 8192
    rrset-cache-size: 64m
    rrset-cache-slabs: 2
    minimal-responses: yes
    prefetch: yes
    prefetch-key: yes
    serve-expired: yes
    so-reuseport: yes
    include: /opt/unbound/etc/unbound/a-records.conf
    include: /opt/unbound/etc/unbound/srv-records.conf
remote-control:
    control-enable: no

You have more resources in CCR2116 so you can optimize configuration for your device, like increase threads count, cache memory sizes, etc... See unbound configuration documentation https://nlnetlabs.nl/documentation/unbo ... ound.conf/

Posted: **Thu Jul 06, 2023 7:36 pm**

But I haven't even used the "unbound.conf" customization. It works for me directly once the container is created.

Default configuration from that image doesn't setup Unbound as recursive resolver. It uses Cloudflare as upstream DNS, see /opt/unbound/etc/unbound/forward-records.conf from container shell. You can use directly in Pi-hole Cloudflare DNS if you want to use it as upstream and not local recursive. I removed line which includes that configuration in unbound.conf among other modifications.

Could you tell me which container is the Linux you have installed?

linuxserver/openssh-server:latest

And the Shadowsocks?

teddysun/go-shadowsocks2:latest

And if they would work on 64bit architecture.

Yes, both have arm64 build, you can see that in Tags tab on Docker page for image, eg. https://hub.docker.com/r/linuxserver/op ... erver/tags

Posted: **Fri Jul 07, 2023 8:07 pm**

As you know I was interested in several things that I saw in your configuration, linux works perfectly for me, but I can't do anything that I know how to do with it, I suppose that you have it to facilitate other functionalities, it doesn't seem that you have anything configured by whim, or I don't get to know it. For example, I can't install any package, or at least I haven't known how to do it.

I also tried to find out what Shadowsocks is, but I still didn't have time to learn anything about it, only to understand that I was interested. What did happen to me is that I tried to install the container and when it didn't start, it stopped immediately, I guess I did something wrong, I share the lines I added.

--------------------------------------------------------------
/interface/veth/add name=veth4 address=192.168.4.5/24 gateway=192.168.4.1 comment=Shadowsocks
/interface/bridge/port add bridge=dockers interface=veth4 comment=Shadowsocks
--------------------------------------------------------------

--------------------------------------------------------------
/container/envs/add name=shadowsocks_envs key=TZ value="Europe/Madrid"
/container/envs/add name=shadowsocks_envs key=DNS_ADDRS value=192.168.4.2 <---- This is the Pi-Hole veth address
/container/envs/add name=shadowsocks_envs key=PASSWORD value="xxxxxxx" <---- obviously my password don't apears
/container/envs/add name=shadowsocks_envs key=SERVER_PORT value=443
/container/envs/add name=shadowsocks_envs key=METHOD value=AEAD_AES_128_GCM
/container/envs/add name=shadowsocks_envs key=ARGS value="-plugin v2ray-plugin -plugin-opts server;tls;host=xxx;logLevel=none" <---- and I don´t know if "host=xxx" is the problem
--------------------------------------------------------------

--------------------------------------------------------------
/container/mounts/add name=shadowsocks_acme src=nvme1-part1/disk1/shadowsocks/root/acme.sh dst=/root/.acme.sh
/container/mounts/add name=shadowsocks_tmp src=nvme1-part1/disk1/shadowsocks/root/tmp dst=/root/tmp
--------------------------------------------------------------

--------------------------------------------------------------
/container/add remote-image=teddysun/go-shadowsocks2:latest interface=veth4 root-dir=nvme1-part1/disk1/shadowsocks envlist=shadowsocks_envs mounts=shadowsocks_acme,shadowsocks_tmp comment="[SS] Shadowsocks" workdir=/root dns=192.168.4.2
--------------------------------------------------------------

But I haven't even used the "unbound.conf" customization. It works for me directly once the container is created.
Default configuration from that image doesn't setup Unbound as recursive resolver. It uses Cloudflare as upstream DNS, see /opt/unbound/etc/unbound/forward-records.conf from container shell. You can use directly in Pi-hole Cloudflare DNS if you want to use it as upstream and not local recursive. I removed line which includes that configuration in unbound.conf among other modifications.

Could you tell me which container is the Linux you have installed?
linuxserver/openssh-server:latest

And the Shadowsocks?
teddysun/go-shadowsocks2:latest

And if they would work on 64bit architecture.
Yes, both have arm64 build, you can see that in Tags tab on Docker page for image, eg. https://hub.docker.com/r/linuxserver/op ... erver/tags

Posted: **Fri Jul 07, 2023 11:39 pm**

As you know I was interested in several things that I saw in your configuration, linux works perfectly for me, but I can't do anything that I know how to do with it, I suppose that you have it to facilitate other functionalities, it doesn't seem that you have anything configured by whim, or I don't get to know it. For example, I can't install any package, or at least I haven't known how to do it.

Image is based on Alpine linux distribution which is using apk package manager https://wiki.alpinelinux.org/wiki/Alpine_Package_Keeper. You can install other software pakages using that tool.

--------------------------------------------------------------
/container/envs/add name=shadowsocks_envs key=TZ value="Europe/Madrid"
/container/envs/add name=shadowsocks_envs key=DNS_ADDRS value=192.168.4.2 <---- This is the Pi-Hole veth address
/container/envs/add name=shadowsocks_envs key=PASSWORD value="xxxxxxx" <---- obviously my password don't apears
/container/envs/add name=shadowsocks_envs key=SERVER_PORT value=443
/container/envs/add name=shadowsocks_envs key=METHOD value=AEAD_AES_128_GCM
/container/envs/add name=shadowsocks_envs key=ARGS value="-plugin v2ray-plugin -plugin-opts server;tls;host=xxx;logLevel=none" <---- and I don´t know if "host=xxx" is the problem
--------------------------------------------------------------

--------------------------------------------------------------
/container/mounts/add name=shadowsocks_acme src=nvme1-part1/disk1/shadowsocks/root/acme.sh dst=/root/.acme.sh
/container/mounts/add name=shadowsocks_tmp src=nvme1-part1/disk1/shadowsocks/root/tmp dst=/root/tmp
--------------------------------------------------------------

These environment variables are described at https://hub.docker.com/r/teddysun/go-shadowsocks2, PASSWORD is masked because I don't want to share it, must be set same at server and client side (METHOD also must be the same on both sides since this defines protocol cipher algorithm).
Arguments for v2ray-plugin (in ARGS) and tls certificate creation/renewal with acme.sh script are described here: https://github.com/teddysun/v2ray-plugin#usage and some not described arguments can be found in source code https://github.com/teddysun/v2ray-plugi ... er/main.go (part of source

var ( ... flag.*

). Also these plugin options must be aligned in your client configuration (tls;host;path).
Masked host argument must be set to your public host.domain if you have or you can create it on some dyndns service and tls certificate must be created for it. Created cretificate with full chain (all certificates in chain must be in single PEM file with name fullchain.cer) and key (PEM file with name <your_public_host_domain>.key) must be placed into /root/.acme.sh/<your_public_host_domain>, more info about acme.sh at https://github.com/acmesh-official/acme.sh. Eg, if you have host with name myhost.net it will be:

/root/.acme.sh/myhost.net/fullchain.cer
/root/.acme.sh/myhost.net/myhost.net.key

I mounted /root/.acme.sh dir so that its content is persisted if I need to recreate container with new version and /root/tmp is for file transfer from ROS to container (read-only in container).

I guess your container is not starting because you didn't place any certificate but it is mandatory when using tls. To troubleshoot service, enable logging for this container and also set v2ray-plugin argument logLevel=debug and examine log in ROS.

Posted: **Fri Jul 14, 2023 1:05 pm**

Question...

I'm using Adguard in a Container (adguard/adguardhome:v0.108.0-b.25)

Everything works fine, except when i lose power for a second (storms) on the 5009 (and also on modem) where Containers are running. Then, for some reason Adguard Would not start after power is restored. I get bunch of errors in LOG but don't realy know what they mean. Then after few minutes if i reboot 5009 one more time via reboot command Adguard starts without problem and works normaly. What could be causing this? Ironicly this often happen when i'm not at home, and then DNS isn't working so nothing is working until i come home. If i put another DNS server as an option, for safety, then i get bombed with ads everywhere.

Any ideas?

Other Container, that i use, UDPXY, starts and works normally.

Posted: **Thu Aug 10, 2023 11:40 am**

Could you share the configuration for deploying the go-shadowsocks2 client mode container?

As you know I was interested in several things that I saw in your configuration, linux works perfectly for me, but I can't do anything that I know how to do with it, I suppose that you have it to facilitate other functionalities, it doesn't seem that you have anything configured by whim, or I don't get to know it. For example, I can't install any package, or at least I haven't known how to do it.
Image is based on Alpine linux distribution which is using apk package manager https://wiki.alpinelinux.org/wiki/Alpine_Package_Keeper. You can install other software pakages using that tool.

--------------------------------------------------------------
/container/envs/add name=shadowsocks_envs key=TZ value="Europe/Madrid"
/container/envs/add name=shadowsocks_envs key=DNS_ADDRS value=192.168.4.2 <---- This is the Pi-Hole veth address
/container/envs/add name=shadowsocks_envs key=PASSWORD value="xxxxxxx" <---- obviously my password don't apears
/container/envs/add name=shadowsocks_envs key=SERVER_PORT value=443
/container/envs/add name=shadowsocks_envs key=METHOD value=AEAD_AES_128_GCM
/container/envs/add name=shadowsocks_envs key=ARGS value="-plugin v2ray-plugin -plugin-opts server;tls;host=xxx;logLevel=none" <---- and I don´t know if "host=xxx" is the problem
--------------------------------------------------------------

--------------------------------------------------------------
/container/mounts/add name=shadowsocks_acme src=nvme1-part1/disk1/shadowsocks/root/acme.sh dst=/root/.acme.sh
/container/mounts/add name=shadowsocks_tmp src=nvme1-part1/disk1/shadowsocks/root/tmp dst=/root/tmp
--------------------------------------------------------------
These environment variables are described at https://hub.docker.com/r/teddysun/go-shadowsocks2, PASSWORD is masked because I don't want to share it, must be set same at server and client side (METHOD also must be the same on both sides since this defines protocol cipher algorithm).
Arguments for v2ray-plugin (in ARGS) and tls certificate creation/renewal with acme.sh script are described here: https://github.com/teddysun/v2ray-plugin#usage and some not described arguments can be found in source code https://github.com/teddysun/v2ray-plugi ... er/main.go (part of source
Code: Select all
var ( ... flag.*
). Also these plugin options must be aligned in your client configuration (tls;host;path).
Masked host argument must be set to your public host.domain if you have or you can create it on some dyndns service and tls certificate must be created for it. Created cretificate with full chain (all certificates in chain must be in single PEM file with name fullchain.cer) and key (PEM file with name <your_public_host_domain>.key) must be placed into /root/.acme.sh/<your_public_host_domain>, more info about acme.sh at https://github.com/acmesh-official/acme.sh. Eg, if you have host with name myhost.net it will be:
Code: Select all
/root/.acme.sh/myhost.net/fullchain.cer
/root/.acme.sh/myhost.net/myhost.net.key
I mounted /root/.acme.sh dir so that its content is persisted if I need to recreate container with new version and /root/tmp is for file transfer from ROS to container (read-only in container).

I guess your container is not starting because you didn't place any certificate but it is mandatory when using tls. To troubleshoot service, enable logging for this container and also set v2ray-plugin argument logLevel=debug and examine log in ROS.

Posted: **Thu Aug 10, 2023 5:54 pm**

Could you share the configuration for deploying the go-shadowsocks2 client mode container?

ShadowsocksX-NG (Mac) Server Preferences:

ss-ng.png

Posted: **Thu Aug 10, 2023 7:41 pm**

Could you share the configuration for deploying the go-shadowsocks2 client mode container?
ShadowsocksX-NG (Mac) Server Preferences:
ss-ng.png

I meant something else. Is it possible to run this container in client mode on Mikrotik. My server is set to ubuntu

Posted: **Fri Aug 11, 2023 1:21 pm**

I meant something else. Is it possible to run this container in client mode on Mikrotik. My server is set to ubuntu

I think yes, at least for non transparent proxy, but I never tried so I don't have something to share. Ofc, for non transparent setup you will need manually to add proxy address (container's IP/hostname) and proxy port in client OS/browser.
For transparent connection over proxy you will need something like tun2socks (https://github.com/xjasonlyu/tun2socks) in container and route traffic over it, but I'm not sure is this possible with container virtual interface. Alternative is to setup this in some external OpenWRT/Linux device.

MikroTik

Container/Docker -Adguard/Pihole For REAL.

Container/Docker -Adguard/Pihole For REAL.

Re: Container/Docker -Adguard/Pihole For REAL.

Re: Container/Docker -Adguard/Pihole For REAL.

Re: Container/Docker -Adguard/Pihole For REAL.

Re: Container/Docker -Adguard/Pihole For REAL.

Re: Container/Docker -Adguard/Pihole For REAL.

Re: Container/Docker -Adguard/Pihole For REAL.

Re: Container/Docker -Adguard/Pihole For REAL.

Re: Container/Docker -Adguard/Pihole For REAL.

Re: Container/Docker -Adguard/Pihole For REAL.

Re: Container/Docker -Adguard/Pihole For REAL.

Re: Container/Docker -Adguard/Pihole For REAL.

Re: Container/Docker -Adguard/Pihole For REAL.

Re: Container/Docker -Adguard/Pihole For REAL.

Re: Container/Docker -Adguard/Pihole For REAL.

Re: Container/Docker -Adguard/Pihole For REAL.

Re: Container/Docker -Adguard/Pihole For REAL.

Re: Container/Docker -Adguard/Pihole For REAL.

Re: Container/Docker -Adguard/Pihole For REAL.

Re: Container/Docker -Adguard/Pihole For REAL.

Re: Container/Docker -Adguard/Pihole For REAL.

Re: Container/Docker -Adguard/Pihole For REAL.

Re: Container/Docker -Adguard/Pihole For REAL.

Re: Container/Docker -Adguard/Pihole For REAL.

Re: Container/Docker -Adguard/Pihole For REAL.

Re: Container/Docker -Adguard/Pihole For REAL.

Re: Container/Docker -Adguard/Pihole For REAL.

Re: Container/Docker -Adguard/Pihole For REAL.

Re: Container/Docker -Adguard/Pihole For REAL.

Re: Container/Docker -Adguard/Pihole For REAL.

Re: Container/Docker -Adguard/Pihole For REAL.

Re: Container/Docker -Adguard/Pihole For REAL.

Re: Container/Docker -Adguard/Pihole For REAL.

Re: Container/Docker -Adguard/Pihole For REAL.

Re: Container/Docker -Adguard/Pihole For REAL.