NAT Problems: Port Forwarding/Hairpin - Port 80 redirected

Hi everyone :slight_smile:

after I had a long fight with the hairpin NAT rule, I just updated to version 6.7rc1. On my first try after that the hairpin NAT still didn’t work.
Then I noticed that every of dst-nat rules has the “in-interface” set to “ether1”, whats my WAN interface. As in the wiki described, I removed “ether1” from the dst-nat rules and then the hairpin NAT seemed to work. But later I had to realize that ALL port-80-requests from inside the LAN are going to my internal webserver. Surfing the web is now not possible any more. :confused:

I found only one thread related to this problem, but the solution doesn’t fix it for me: http://forum.mikrotik.com/t/port-forward-on-port-80-http/15175/1

I’m on a cable modem, the MT gets a public IP via DHCP on ether1; ether2 and wlan0 are bridged to “LAN-WLAN-Bridge”.

NAT:

Flags: X - disabled, I - invalid, D - dynamic
 0   ;;; HTTP
     chain=dstnat action=dst-nat to-addresses=192.168.10.4 to-ports=80
     protocol=tcp dst-port=80

 1   ;;; IMAP
     chain=dstnat action=dst-nat to-addresses=192.168.10.4 to-ports=143
     protocol=tcp dst-port=143

 2   chain=dstnat action=dst-nat to-addresses=192.168.10.4 to-ports=993
     protocol=tcp dst-port=993

 3   ;;; SMTP
     chain=dstnat action=dst-nat to-addresses=192.168.10.4 to-ports=25
     protocol=tcp dst-port=25

 4   chain=dstnat action=dst-nat to-addresses=192.168.10.4 to-ports=587
     protocol=tcp dst-port=587

 5   chain=dstnat action=dst-nat to-addresses=192.168.10.4 to-ports=465
     protocol=tcp dst-port=465

 6   ;;; OpenVPN
     chain=dstnat action=dst-nat to-addresses=192.168.10.8 to-ports=1194
     protocol=udp dst-port=1194

 7   ;;; Hairpin NAT
     chain=srcnat action=masquerade src-address=192.168.10.0/24
     dst-address=192.168.10.0/24 out-interface=LAN-WLAN-Bridge

 8   ;;; Standard Masquerade Regel
     chain=srcnat action=masquerade out-interface=ether1

Firewall:

Flags: X - disabled, I - invalid, D - dynamic
 0   ;;; Accept Ping
     chain=input action=accept protocol=icmp

 1   ;;; Accept Established
     chain=input action=accept connection-state=established in-interface=ether1

 2   ;;; Accpet Related
     chain=input action=accept connection-state=related in-interface=ether1

 3   ;;; OpenVPN
     chain=input action=accept protocol=tcp in-interface=ether1 dst-port=1195

 4   ;;; Drop Brute Forcers
     chain=input action=drop protocol=tcp src-address-list=winbox_blacklist dst-port=8291,22

 5   chain=input action=add-src-to-address-list connection-state=new protocol=tcp
     src-address-list=winbox_stage3 address-list=winbox_blacklist address-list-timeout=1w3d
     dst-port=8291,22

 6   chain=input action=add-src-to-address-list connection-state=new protocol=tcp
     src-address-list=winbox_stage2 address-list=winbox_stage3 address-list-timeout=2m dst-port=8291,22

 7   chain=input action=add-src-to-address-list connection-state=new protocol=tcp
     src-address-list=winbox_stage1 address-list=winbox_stage2 address-list-timeout=2m dst-port=8291,22

 8   chain=input action=add-src-to-address-list connection-state=new protocol=tcp
     address-list=winbox_stage1 address-list-timeout=2m dst-port=8291,22

 9   ;;; WinBox Remote Access
     chain=input action=accept protocol=tcp dst-port=8291

10   ;;; SSH Remote Access
     chain=input action=accept protocol=tcp dst-port=22

11   ;;; Drop Invalid
     chain=input action=drop connection-state=invalid protocol=tcp

12   ;;; Drop den Rest
     chain=input action=drop in-interface=ether1

I hope somebody can help me with that.. :slight_smile:

If you need more information, let me know..

I think you should either specify the in-interface or the dst-address option on your NAT rules.
Otherwise the rules are also applied when initiated from inside.
Also maybe changing the order of your src-nat rules could help?

Initially all my dst-nat rules had the “in-interface” set to “ether1” (WAN).. with this the hairpin NAT doesn’t work.
The same problem with the set “dst-address” to the corresponding IP of the server, no hairpin NAT working.
And without “dst-address” or “in-interface” (as in the wiki described) all requests go to the internal server.. :frowning:

Changing the order of the src-nat rules makes no difference..

//EDIT:

If I set the “dst-address” instead of the “in-interface” there is no access from outside the LAN via dynDNS-address and no hairpin NAT working.

http://wiki.mikrotik.com/wiki/Hairpin_NAT has an example you could use. Instead of using dst-address use in-interface like Rudios suggested. Also you could use DNS entries on your router to resolve to the internal address of your servers instead of the Hairpin NAT.

Thank you a lot for your answers. But I was hoping for a “real” solution.

Over the last weeks almost everybody suggested the static dns workaround for the hairpin NAT problem. Maybe it’s a acceptable alternative for those who have all the services, they want to access from in and outside via dynDNS-address, hosted on one server. But if you have several services on different servers.. a static DNS entry pointing to one of them is not the solution.

Now with the hairpin NAT fixed in 6.7rc1, I tought in works as it should.

What’s new in 6.7rc1 (2013-Nov-08 15:54):
*) fixed hairpin nat on bridge with use-ip-firewall=yes;

Ha :smiley: , while I was writing this post I tested what happens if I set the dst-address of my dst-nat rule to my dynamic public IP (as in the wiki described: http://wiki.mikrotik.com/wiki/Forwarding_a_port_to_an_internal_IP). I was able to reach the server from outside via dynDNS-address, from inside via dynDNS-address and I was able to surf the web. Wow! :open_mouth: After that I asked google and came across this thread: http://forum.mikrotik.com/t/port-forwarding-with-dynamic-wan-ip/45913/1 ..first I thought I have to tinker this kind of script but the “dst-address-type=local” hint seemes to work, too :wink:

Maybe its not the solution and the next problem is already waiting for me.. I’ll test it and give feedback.

After some days everything is fine. :wink:

Merry Christmas …