Unable to Access Port for Specific IP

Hi all,

ISSUE
I’m unable to access a port (5555) of a specific IP that I can successfully ping

Details

  • The IP is the IP of a dynamic dns host name that resolves to my local server (192.168.x.x) to support a service that’s running there on port 5555


  • I can successfully ping the IP of the dynamic dns host name (ping ip_of_dynamic_dns)


  • I can successfully access the service that runs on my local server successfully (https://192.168.x.x:5555)


  • hEX Router


  • RouterOS v6.48.1 (stable)

Error trying to access the service via the IP of a dynamic dns host name (https://ip_of_dynamic_dns):

  • “ERR_CONNECTION_REFUSED” - Chrome/Brave


  • “RESOURCE_NOT_FOUND” - IE (I believe this is a HTTP Status 404)

What I’ve tried

Router.jpg

RouterRule.jpg

  • Firewall - I’ve completely turned it off (I also tried adding inbound and outbound rules (Windows 10)

FirewallIn.jpg
FirewallOut.jpg

How does dynamic dns resolve to your private IP?

If you are using mikrotik cloud service (dynamic dns) than it will resolve to the public IP you have at the moment…now you have to pass (dst-nat) the traffic from internet to the specific port on your public (dynymic) IP - to some IP on your private network
Something like…

add action=dst-nat chain=dstnat comment=MyServer dst-port=5555 in-interface=InInterfaceName protocol=tcp to-addresses=192.168.x.x to-ports=5555

It’s very important to hide private only address 192.168.x.x or someone inside your network can read this topic and can ping your pc…

:slight_smile: don't you think that he is confused enough already?

Please post your config

/export hide-sensitive file=anynameyouwish

Thank you @satman1w, @rextended, and @anav for your responses. My apologies for my delayed response as I’ve been on vacation - I was trying to get this settled before I left.

@satman1w

  • I’ve added the ip firewall filter you suggested. I actually originally had it setup to restrict forwarding per a specific IP address (in this case the dynamic DNS IP address) per instructions from https://forum.mikrotik.com/viewtopic.php?t=121397 - but I removed that restriction to follow your specific steps - see the export fragment from my config (below)


  • The dynamic dns is actually for my VPN


  • I can ping the dynamic DNS IP address successfully


  • Within my internal network, https://ip_of_dynamic_dns (though I initially get a warning that it’s not secure, “do you want to continue”)


  • Outside my internal network https://ip_of_dynamic_dns produces the issue/message in the OP

@anav

  • Here is a fragment from my export - I’m a little shy about posting my config (even with “hide-sensitive” as I’ve noticed it still exposes my internal IP addresses - I had to “xxx” them myself) per my concern about security - see my below reply to @rextended


add action=accept chain=forward comment=
https://forum.mikrotik.com/viewtopic.php\?t=121397
connection-nat-state=dstnat connection-state=new in-interface=ether1
add action=dst-nat chain=dstnat comment=MyServer dst-port=5555 in-interface=ether1
protocol=tcp to-addresses=xxx.xxx.x.x to-ports=5555


@rextended

* > "It's very important to hide private only address 192.168.x.x or someone inside your network can read this topic and can ping your pc..."

- I admit I'm an example of "just knowledgeable to be dangerous" :slight_smile:.  I'm not sure if what you're saying is that posting 192.168.x.x is too much information in case someone somehow accesses my internal network.  I'm conscientious of security for sure but admittedly lighter on network security as I'd like to be

https://forum.mikrotik.com/viewtopic.php?t=179343

If you are trying to reach the server from (users or you) from the same subnet that the server is located, then you are running into a situation that calls for hairpin nat.
add chain=srcnat action=masquerade dst-address=192.168.x.0/24 src-address=192.168.x.0/24 as your first source-nat rule.

Thanks @anav, thanks for the link! I tried what you’ve specified that but unfortunately had no luck (same result as described in my OP). Just to verify though, the dst-address and src-address should be the same and represent my internal server where I want the ip_of_dynamic_dns to resolve to, correct? Also, just double-checking, would the hairpin scenario apply in my case where I try to access https://ip_of_dynamic_dns from my phone via cell service (wi-fi turned off) with the same result?

No hairpin nat is required only if the user and server are on same subnet, if coming in externally, from the internet, not required.
If you want further help full config is required.
/export hide-sensitive file=anynameyouwish

Just ensure no public IPs or gateways are visible. rest is normally fine.

Ok, here’s my backup (JimsExportClean.rsc), I cleaned it up putting xxx’s in places of IPs. Let me know what you think
JimsExportClean.rsc (4.32 KB)

xxx

I said public IPs, a config where you cover all the private internal IPs makes no sense from a security point and also really makes the config less useful for problem solving LOL, but will have a look.

(1) Typical error:
/ip address
add address=xxx.xxx.x.1/24 comment=defconf interface=ether2 network=
xxx.xxx.x.0

Should be
/ip address
add address=xxx.xxx.x.1/24 comment=defconf interface=bridge network=
xxx.xxx.x.0

(2) Highly recommend you keep your input chain rules together and your forward chain firewall rules together, makes it very easy to spot mistakes and is simply an efficient organized approach. IN addition the order of some of your rules is non standard.

From this
add action=accept chain=forward comment=
https://forum.mikrotik.com/viewtopic.php?t=121397
connection-nat-state=dstnat connection-state=new in-interface=ether1

TO THIS
add action=accept chain=forward connection-nat-state=dstnat
comment=“allow port forwarding”

(3) Specifically the forward chain rule above should be AFTER these ones!
add action=accept chain=forward comment=“defconf: accept in ipsec policy”
ipsec-policy=in,ipsec
add action=accept chain=forward comment=“defconf: accept out ipsec policy”
ipsec-policy=out,ipsec
add action=fasttrack-connection chain=forward comment=“defconf: fasttrack”
connection-state=established,related
add action=accept chain=forward comment=
“defconf: accept established,related, untracked” connection-state=
established,related,untracked

—> { put the destination nat rule here in the order }

(4) This rule is now redundant as you have already allowed port forwarding from both LAN and WAN… so we will get rid of it, but replace the parts still necessary.
add action=drop chain=forward comment=
“defconf: drop all from WAN not DSTNATed” connection-nat-state=!dstnat
connection-state=new in-interface-list=WAN

What this rule also did was block all WAN to LAN traffic which is a good thing!
However we will do one better, as the LAST rule in the forward chain.
add chain=forward action=drop comment=“drop all else”

This drops all wan to lan traffic and drops all LAN to LAN traffic and drops all LAN to WAN traffic at layer 3.
In other words, unless you specifically allow it, (proper control) traffic is not permitted, - best approach.

What does this mean, well it means that probably the only additional change you will need is to allow LAN to WAN traffic for internet
add chain=forward action=accept in-interface-list=LAN out-interface-list=WAN comment=“allow internet traffic”

(4) I want you to disable raw rules when testing the port forwarding in case there is something funky going on there, using raw in the hands of the beginner can be dangerous!

(5) Why is upnp enabled? Normally recommended to keep this disabled.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

You do not need to replace something like 192.168.1.x with xxx.xxx.x.x …

If the ether2 do not have C4:AD:34:14:FE:B7, put the ether2 MAC inside the appropriate filed on the bridge

Paste this on new terminal

/user group
set full policy="local,telnet,ssh,ftp,reboot,read,write,policy,test,winbox,password,web,sniff,sensitive,api,romontikapp"

why: dude right deprecated (now use winbox)

rextended, the answer to all problems is not porn! ;-PP

Oh, right… tooooooo many time on hospital…

Hi @rextended, thanks so much for your response! I get "input does not match any value of policy" when I try what you've suggested - see attached image
SetPolicy.jpg

Hi @anav first off, than you SO much for your detailed post/response!!! I recognize that all replies to my (or any) question (especially one as detailed as yours) represent time people are generous enough to offer.

Unfortunately so far, after following your steps I haven’t been able to resolve my issue just yet.

Having said that, to keep me honest and be able to ensure I’ve done what you’ve asked, I’ve attached another export of my config, this time with my internal IPs :slight_smile:

Just a couple of notables:

  • I’m confused by “(5) Why is upnp enabled? Normally recommended to keep this disabled.” The attached screenshot of my upnp shows it’s disabled though I do see this in my export
/ip upnp interfaces
add interface=bridge type=internal
add interface=ether1 type=external



  • I removed the following section as I didn’t think it’s needed
/ip dhcp-server lease



  • I only initially removed the internal IPs because you mentioned “It’s very important to hide private only address 192.168.x.x or someone inside your network can read this topic and can ping your pc…”. I’m the first to recognize what I don’t know and not willing to dismiss any advice so I did what I thought you were suggesting but I must be misunderstanding something here, I have been known to do that for sure :slight_smile:
    UPNP.jpg
    JimsExportClean.rsc (4.65 KB)

I have removed too much “,” inside your export

/user group
set full policy="local,telnet,ssh,ftp,reboot,read,write,policy,test,winbox,pas\
    sword,web,sniff,sensitive,api,romon,dude,tikapp"

correct: (or simply open winbox / system / users / groups / full and remove dude right and apply)

/user group
set full policy="local,telnet,ssh,ftp,reboot,read,write,policy,test,winbox,password,web,sniff,sensitive,api,romon,tikapp"

This:

/ip upnp interfaces
add interface=bridge type=internal
add interface=ether1 type=external

not mean than upnp is enabled, just some (unused) settings are still stored inside the config.

only that lines, NOT PRESENTS on your export, mean than upnp is enabled

/ip upnp
set enabled=yes

This is my dummy sarcasm...

You write something like on OP: "my server is 192.168.x.x"

Censoring 192.168.x.x or similar is useless...