I’m forwarding port 80 to a server in LAN. From outside, it works OK, however when I use my public ip from LAN (http://my.public.ip), I get to WebFig. If I wouldn’t get a reply, I would know I have to set up hairpin NAT, but even if I tried it, the hairpin NAT didn’t help.
Disabling the www service for specific ip range can’t help, because I would need to block LAN range…
Now, I’m clueless what to do to disable webfig on the public ip.
Thank you, troffasky. I still look for a better solution, though. Right now, I have local DNS entries with LAN address, so as long as I use only the domain and not ip, it works. But neither of these changes fix the issue, they only hide it.
The proposed solutions with limiting the www service to some IPs won’t work, I wrote that in my first post. I would have to forbid access from my LAN range, but then I wouldn’t be able to administrate the router through browser - I already tried to toy with this. Setting it to some different range is not a solution because:
changing ip to be able to log in into the router is a bad practice,
in my case, it is not even possible, as there is one more router between me and the gateway, and there are other users on it.
EDIT: And I see I forget to post, port changing won’t help too - the router is still taking itself as the target, so any request ends with no reply.
No. The router now listens for HTTP on the other port correctly.. The issue is I need to access a web server in LAN, but the router don’t pass the packets - the only difference now is that when I go to http://my-address:80 from LAN, I don’t get WebFig but a no-reply error, as the router still takes the packets like if they are for him.
Before Mikrotik, I had few SOHO routers and they all worked as I need:
when accessing its LAN IP, packets goes to the router
when accessing its WAN IP (no matter if from LAN or WAN), the packets are NATed and forwarded to a selected IP in LAN
I suppose this is a firewall configuration issue, but I was unable to find working rules.
Go ahead and remove any changes you made about restricting the port the http service listens on / the addresses it will respond to. The problem is in your nat rules.
I’m sure that your port forwarding rule has the criteria like this:
in-interface=WAN
protocol=tcp
dst-port=80
action=dst-nat
to-addresses=192.168.88.x
The thing that’s tripping you up is that your requests to the public IP address are not entering via the WAN interface.
I very much prefer to use the interface method like this, but if you want to use hairpin nat (public IP pinholes from inside) like you’re asking, then this rule won’t work.
Change this rule as follows:
If your public IP address is static, remove in-interface=WAN and add dst-address=x.x.x.x (public IP address of your router)
If your public IP address is dynamic, remove in-interface=WAN and add: dst-address-type=local dst-address=!192.168.88.1 (private IP address of your router)
Finally, in order for the hairpin to work, you’re also going to need this rule in the srcnat chain:
dst-address=192.168.88.0/24 src-address=192.168.88.0/24 action=masquerade
With all of my examples, I use 192.168.88.0/24 - obviously change these to match your actual addressing.
Thank you ZeroByte. This post helped me to configure this, and now it works exactly as you have described. I was working around it, but found this post and fixed it all up. I had to create a forum account to up vote your post and to say thanks.