Hello folks,
I am trying to use my ntfy instance to keep in touch with my new MikroTik. Has anyone of you had success in send a notification ? I have tried the following
/tool fetch http-method=post url="https://ntfy.mydomain.fr/mikrotik" http-data="Test" user=eric password="mypassword" mode=https http-header-field="Priority:1, Title:Test"
But it apparently doesn’t like it
status: failed
failure: Idle timeout - connecting
Any clue ?
patrikg
December 29, 2025, 3:17pm
2
Do you have a example of the api from that site with like another app like curl ?
So we can convert to MT syntax.
Sure! This is what I use for one app.
curl -H prio:5 -d "Text" -u eric:<password> https://ntfy.<mydomain>.fr/<topic>
I could have it to work by using http mode with the internal IP address of the server
/tool fetch http-method=post url="http://192.168.1.xxx:<port>/<topic>" http-data="Test" user=eric password="My password" http-header-field="Priority:1, Title:Test"
I presume I still have a problem with hairpinning …
Amm0
December 29, 2025, 7:43pm
5
Given the error message, it's not getting to the server. e.g. it's not an HTTP response failure. That does indicate some firewall issue. Although if you're using /tool/fetch on the router, you control the URL, so not sure why anything is going via any hairpin.
Anyway, I think you'd get more help if you posted your config and explained the path/IP to the server you're expecting to work.
patrikg
December 29, 2025, 7:59pm
6
If you are on an linux machine, you could test yourself to see what being posted and compare these two, what is the difference.
If you just run nc to listen on some port like this:
nc -l 8080
And bring another terminal up and run(xxx=Linux IP):
curl -H prio:5 -d "Text" -u eric:<password> "http://192.168.1.xxx:8080/<topic>"
And doing the same with RouterOS
/tool fetch http-method=post url="http://192.168.1.xxx:8080/<topic>" http-data="Test" user=eric password="My password" http-header-field="Priority:1, Title:Test"
So, my configuration is I have on my main server a docker container for ntfy. It binds ports 8089 on the host to 80 on the container.
I have a ntfy.mydomain.fr subdomain pointed to an nginx (actually linuxserver.io/docker-swag ) reverse-proxy pointed to port 8089, on the same host, in a docker container.
This part of the setup runs fine, before and after the setup of the MikroTik.
If I try to send a notification from the MikroTik through the subdomain, it fails in timeout. But if I send it through the : it is delivered.
I have the the nc trick but I must do something wrong
eric@odroid:~$ sudo nc -lvv 8089
8089: inverse host lookup failed: Unknown host
listening on [any] 40767 ...
I have set up the following NAT rules
[admin@MikroTik] > /ip firewall nat print
Flags: X - disabled, I - invalid; D - dynamic
0 ;;; defconf: masquerade
chain=srcnat action=masquerade out-interface-list=WAN ipsec-policy=out,none
1 ;;; hairpin tcp 443
chain=dstnat action=dst-nat to-addresses=192.168.1.xx to-ports=443 protocol=tcp dst-address=<public IP> dst-port=443 log=no log-prefix=""
2 ;;; hairpin tcp 465
chain=dstnat action=dst-nat to-addresses=192.168.1.xx to-ports=465 protocol=tcp dst-address=<public IP> dst-port=465 log=no log-prefix=""
3 ;;; hairpin tcp 993
chain=dstnat action=dst-nat to-addresses=192.168.1.xx to-ports=993 protocol=tcp dst-address=<public IP> dst-port=993 log=no log-prefix=""
4 ;;; hairpin tcp 25
chain=dstnat action=dst-nat to-addresses=192.168.1.xx to-ports=25 protocol=tcp dst-address=<public IP> dst-port=25 log=no log-prefix=""
5 ;;; hairpin udp2
chain=dstnat action=dst-nat to-addresses=192.168.1.xx to-ports=49273-49393 protocol=udp dst-address=<public IP> dst-port=49273-49393 log=no log-prefix=""
6 ;;; hairpin udp1
chain=dstnat action=dst-nat to-addresses=192.168.1.xx to-ports=3478 protocol=udp dst-address=<public IP> dst-port=3478 log=no log-prefix=""
7 ;;; hairpin tcp interne
chain=srcnat action=masquerade protocol=tcp src-address=192.168.1.0/24 dst-address=192.168.1.xx out-interface-list=!WAN log=no log-prefix=""
8 ;;; hairpin udp interne
chain=srcnat action=masquerade protocol=udp src-address=192.168.1.0/24 dst-address=192.168.1.xx out-interface-list=!WAN log=no log-prefix=""
9 ;;; swag
chain=dstnat action=dst-nat to-addresses=192.168.1.xx to-ports=443 protocol=tcp in-interface-list=WAN dst-port=443 log=no log-prefix=""
10 ;;; swag
chain=dstnat action=dst-nat to-addresses=192.168.1.xx to-ports=80 protocol=tcp in-interface-list=WAN dst-port=80 log=no log-prefix=""
11 ;;; mailserver
chain=dstnat action=dst-nat to-addresses=192.168.1.xx to-ports=25 protocol=tcp dst-port=25 log=no log-prefix=""
12 ;;; mailserver
chain=dstnat action=dst-nat to-addresses=192.168.1.xx to-ports=993 protocol=tcp dst-port=993 log=no log-prefix=""
13 ;;; mailserver
chain=dstnat action=dst-nat to-addresses=192.168.1.xx to-ports=465 protocol=tcp dst-port=465 log=no log-prefix=""
14 ;;; jabber
chain=dstnat action=dst-nat to-addresses=192.168.1.xx to-ports=5269 protocol=tcp dst-port=5269 log=no log-prefix=""
15 ;;; jabber
chain=dstnat action=dst-nat to-addresses=192.168.1.xx to-ports=5443 protocol=tcp dst-port=5443 log=no log-prefix=""
16 ;;; jabber
chain=dstnat action=dst-nat to-addresses=192.168.1.xx to-ports=5280 protocol=tcp dst-port=5280 log=no log-prefix=""
17 ;;; jabber
chain=dstnat action=dst-nat to-addresses=192.168.1.xx to-ports=49273-49393 protocol=udp dst-port=49273-49393 log=no log-prefix=""
18 ;;; jabber
chain=dstnat action=dst-nat to-addresses=192.168.1.xx to-ports=5222-5223 protocol=tcp dst-port=5222-5223 log=no log-prefix=""
19 ;;; wireguard
chain=dstnat action=dst-nat to-addresses=192.168.1.xx to-ports=51820 protocol=udp dst-port=51820 log=no log-prefix=""
Anyway, since the local approach works, the problem is insignificant.
patrikg
December 29, 2025, 9:29pm
8
This going more complex what you asked in the first post.
This maybe has not to do with MT device.
For more help, I think you have to draw some picture with some ip addresses, how you think it should work.
1 Like
Thank you for helping. As I said, since the local approach works, the problem is insignificant. I just hope that it won’t hide a bigger problem.
Thanks a lot!