[HOWTO] DNS tunneling with iodined on TurrisOS HBK [5.2.3]

Software SW help
,
1

Hi,

I am trying to set up a DNS tunnel with iodined (0.7.0) and the current (5.2.3 - HBK) version of TurrisOS and I systematically fail. For now I want the server to work before I go into the client.

What I tried:
I’ve setup my domain stuff:
t.mydomain.tld NS ns.mydomain.tld
ns.mydomain.tld A $MY_PUBLIC_ROUTER_IP

I also forwarded ports because of running kresd and I runned iodine like that:

/etc/config/firewall:
config redirect
option src ‘wan’
option name ‘DNS Tunnel’
option src_dport ‘53’
option target ‘DNAT’
option dest_ip ‘$MY_LOCAL_ROUTER_IP’
option dest ‘lan’
option src_dip ‘$MY_PUBLIC_ROUTER_IP’
option dest_port ‘153’
list proto ‘udp’

root@router:~# LC_ALL=C iodined -f -DD -u nobody -d dns0 -m 1500 -l $MY_LOCAL_ROUTER_IP -p 153 -P testpassword 10.222.111.254/28 t.mydomain.tld:
ALERT! Other dns servers expect you to run on port 53.
You must manually forward port 53 to port 153 for things to work.
Debug level 2 enabled, will stay in foreground.
Add more -D switches to set higher debug level.
Opened dns0
Setting IP of dns0 to 10.222.111.254
Setting MTU of dns0 to 1500
Opened IPv4 UDP socket
Limiting to 13 simultaneous users because of netmask /28
Listening to dns for domain t.mydomain.tld

But whenever I try to test the setup with: https://code.kryo.se/iodine/check-it/ it fails:

Troubleshoot your iodine setup

Analyzing DNS setup for tunnel domain ‘t.mydomain.tld’… (might take some time)

Looking for nameserver for mydomain.tld… got ns3.afraid.org (at 67.220.81.190).
Resolving delegation of t.mydomain.tld at 67.220.81.190… to ns.mydomain.tld (at $MY_PUBLIC_ROUTER_IP).

Expecting iodined to be accessible at $MY_PUBLIC_ROUTER_IP… no reply.

Error: Make sure iodined is running and the firewall accepts UDP port 53. Also check any port forwards in use.

Try again

Back to iodine

EDIT (some more info):
root@router:~# netstat -tulpn | grep 53
tcp 0 0 0.0.0.0:853 0.0.0.0:* LISTEN 19807/kresd
tcp 0 0 0.0.0.0:53 0.0.0.0:* LISTEN 19807/kresd
tcp 0 0 :::53 :::* LISTEN 19807/kresd
tcp 0 0 :::853 :::* LISTEN 19807/kresd
udp 0 0 $MY_LOCAL_ROUTER_IP:5353 0.0.0.0:* 10949/python3
udp 0 0 10.111.222.254:5353 0.0.0.0:* 10949/python3
udp 0 0 $MY_PUBLIC_ROUTER_IP:5353 0.0.0.0:* 10949/python3
udp 0 0 127.0.0.1:5353 0.0.0.0:* 10949/python3
udp 0 0 10.111.111.1:5353 0.0.0.0:* 10949/python3
udp 0 0 0.0.0.0:5353 0.0.0.0:* 10949/python3
udp 0 0 224.0.0.251:5353 0.0.0.0:* 11204/umdns
udp 0 0 $MY_LOCAL_ROUTER_IP:5353 0.0.0.0:* 11204/umdns
udp 0 0 0.0.0.0:53 0.0.0.0:* 19807/kresd
udp 0 0 $MY_LOCAL_ROUTER_IP:153 0.0.0.0:* 24249/iodined
udp 0 0 ff02::fb:5353 :::* 11204/umdns
udp 0 0 fe80::da58:d7ff:fe00:20ac:5353 :::* 11204/umdns
udp 0 0 :::53 :::* 19807/kresd

Also sudo nmap (from the world) mydomain.tld -Pn -sU -p 53 gives:

Starting Nmap 7.80 ( https://nmap.org ) at 2021-07-02 16:12 CEST
Nmap scan report for mydomain.tld ($MY_PUBLIC_ROUTER_IP)
Host is up.

PORT STATE SERVICE
53/udp open|filtered domain

Nmap done: 1 IP address (1 host up) scanned in 11.37 seconds

Anybody tried something similar? How does it comply with Turris honeypots enabled?

Thanks,
AreYouLoco?

2

kresd doesn’t need to listen on WAN addresses. Your /etc/config/resolver probably retained lines like

        list interface '0.0.0.0'
        list interface '::0'

If you remove those, it will only listen on localhost and LAN. After that I don’t think there should be problem with iodined simply listening directly on port 53 of your WAN address(es).

3

I believe the honeypots do nothing with port 53.

4

I commented out the lines and did /etc/init.d/resolver restart now kresd listens only on localhost and my lan adresses. So I started iodined with:
root@router:~# LC_ALL=C iodined -f -DDDD -u nobody -d dns0 -m 1500 -l $MY_PUBLIC_ROUTER_IP -p 53 -P testpassword 10.222.111.254/28 t.mydomain.tld

And made sure it listens on public IP port 53
But the tool provided to check the server still complains. Also android iodine client cannot connect.

EDIT:

From the firewall point of view it shouldn’t matter if a port is forwarded or accessed directly right?

5

Default firewall denies the connections (to router’s port 53). I’m no firewall expert, but I know that the luci interface for it makes a difference between “lan” and “this device”.

By the way, I don’t know iodined in particular, but full DNS service generally requires both UDP and TCP port 53.

6

I opened port 53 from WAN both TCP and UDP with this rule:

/etc/config/firewall:
config rule
option dest_port '53'
option src 'wan'
option name 'DNS Tunnel'
option family 'ipv4'
option target 'ACCEPT'
list dest_ip '$MY_PUBLIC_ROUTER_IP'
list proto 'tcp'
list proto 'udp'

I made sure its enabled and reloaded firewall → /etc/init.d/firewall reload

7

Is it possible that my ISP is doing some MITM filtering/blocking?

8

Just in case, if your address is in 10.x.x.x, that’s not even a public IP. It’s still possible that you arranged with your ISP that they forward some public IP to you this way; however that often makes the IP inaccessible (by default) when accessed from your connection (and maybe even from some other people connected to the same CGNAT).

I think all firewall refusals get logged, so I’d try accessing from some other network (say, mobile) and look e.g. into Turris’s tail /var/log/iptables and – perhaps in case the packets came through inside – also some tcpdump output (or if iodined can log them).

9

I have two IPs assigned to my wan interface one is private IP from ISP network and second is normal reachable from outside public IP assigned only for me and I can normally connect from outside of my network with OpenVPN. So lets just skip that part. I even have mwan running on the top of that but that’s not important.

I will indeed check the logs.
EDIT:
There is lot of junk broadcast traffic hitting my WAN from my ISP network spamming all the log but nothing port 53 related while connecting. So indeed it seems like a ISP filtering. I will consult my ISP when possible and try again.

1 Like
10

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.