Community discussions

MikroTik App
 
Zikasak
just joined
Topic Author
Posts: 6
Joined: Fri May 04, 2018 9:56 am

LAN availability from LAN by IP Cloud

Sat May 05, 2018 10:21 am

Hello.

I'm trying get access to my NAS by using mikrotik DDNS service. But connection succeed only from outside LAN. If device located inside LAN then i've got connection refused error.

Tryed to use Hairpin NAT by using this commands:
/ip firewall nat
add chain=srcnat src-address=192.168.1.0/24 \
  dst-address=192.168.1.231 protocol=tcp dst-port=80 \
  out-interface=private-bridge action=masquerade

add chain=srcnat src-address=192.168.1.0/24 \
  dst-address=192.168.1.231 protocol=tcp dst-port=5000 \
  out-interface=private-bridge action=masquerade
but got same error
 
User avatar
anav
Forum Guru
Forum Guru
Posts: 21986
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada
Contact:

Re: LAN availability from LAN by IP Cloud

Sun May 06, 2018 4:34 pm

I think you want to use action=srcnat not masquerade!
 
User avatar
CZFan
Forum Guru
Forum Guru
Posts: 2098
Joined: Sun Oct 09, 2016 8:25 pm
Location: South Africa, Krugersdorp (Home town of Brad Binder)
Contact:

Re: LAN availability from LAN by IP Cloud

Sun May 06, 2018 4:50 pm

I suspect your rule order is incorrect, can you paste the result of /ip firewall nat print?
 
Zikasak
just joined
Topic Author
Posts: 6
Joined: Fri May 04, 2018 9:56 am

Re: LAN availability from LAN by IP Cloud  [SOLVED]

Mon May 07, 2018 9:25 am

Problem solved by using this code:
/ip firewall nat
add chain=dstnat dst-address-type=local protocol=tcp dst-port=5000 \
  action=dst-nat to-address=192.168.1.231 to-port=5000

/ip firewall nat
add chain=srcnat src-address=192.168.1.0/24 \
  dst-address=192.168.1.231 protocol=tcp dst-port=5000 \
  out-interface=private-bridge action=masquerade
 
User avatar
anav
Forum Guru
Forum Guru
Posts: 21986
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada
Contact:

Re: LAN availability from LAN by IP Cloud

Wed May 09, 2018 7:30 pm

Problem solved by using this code:
/ip firewall nat
add chain=dstnat dst-address-type=local protocol=tcp dst-port=5000 \
  action=dst-nat to-address=192.168.1.231 to-port=5000

/ip firewall nat
add chain=srcnat src-address=192.168.1.0/24 \
  dst-address=192.168.1.231 protocol=tcp dst-port=5000 \
  out-interface=private-bridge action=masquerade
CZFan can you explain some of the code please. (or Sob, Sindy, Mangle Rule etc.......)

1. I am unfamiliar with dst address = local? Typically I don't use dst address in my Port Forward rules as the destination address is handled when selecting action=dst-nat and the TO line becomes available and thats where I put in the lan server address (or NAS address etc.). Which brings up another question?
2. Why do I typically use dst-port = (incoming port request) in the general setup but I dont use after selecting action dst-nat, the to PORT that becomes available? He has seemingly selected it redundantly a second time.

You can see the slight puzzlement on my face (or at least imagine it).
The only thing I can think of (probably wrong) is when you want to do port mapping.
External User needs to come in on port ZZZZ because ISP blocks server port VVVV, thus one uses the dst-port ZZZZ in the general setting and in the action menu to-port is filled in with VVVV.

3. Finally on this rule what happened to identifying the incoming interface in-interface=WAN or in-interface-list=WAN

4. Regarding the SourceNAT rule. Is it best to use 192.168.0.0/24 as stated to describe a LAN network, or can one physically write in the LAN range under the advanced tab as
source-address-list=192.168.0.2-192.168.0.254
OR create that range in IP Firewall Address list and use it in source-address-list?

5. There seems to be a missing interface entry - where on typically puts out-interface=WAN, or out-interface-list=WAN or out-interface=ether1 etc..................

6. Probably related is a direct destination address which confounds me totally, why would one setup a srcnat rule if not going out the WAn interface????

7. Again Probably associated is the term I have not seen used and that is out-interface=private-bridge?????
 
User avatar
CZFan
Forum Guru
Forum Guru
Posts: 2098
Joined: Sun Oct 09, 2016 8:25 pm
Location: South Africa, Krugersdorp (Home town of Brad Binder)
Contact:

Re: LAN availability from LAN by IP Cloud

Wed May 09, 2018 7:52 pm

My understanding from address is local, is any address on the local interface ports of router.

I think why OP did it this is because he is accessing the device, from internal via port forwarding. I have never been in a situation to use this and I am not sure if it is required and think only the Hairpin NAT should be sufficient.
 
Sob
Forum Guru
Forum Guru
Posts: 9188
Joined: Mon Apr 20, 2009 9:11 pm

Re: LAN availability from LAN by IP Cloud

Wed May 09, 2018 7:55 pm

1) The dst-address-type=local means exactly what it says, any IP address assigned to router.
2) If you want to keep same port number, you don't need to set to-ports. People add it because... I don't really know why, maybe they are used to it from other routers, they just like it, have OCD, anything...
3) When doing hairpin NAT, limiting dstnat rules for WAN interface is exactly what you don't want to do, because it wouldn't work. Request from LAN, even though they have WAN address as destination, still have in-inteface=LAN.
4) It's up to you. Using src-address=<LAN range>/<mask> is probably just the most straightforward. Address list is not bad idea, if you can reuse it elsewhere. Or using it with range, to exclude router's own LAN address is perhaps a little better, because you avoid srcnatting connection from router itself. On the other hand, it doesn't really hurt, if that happens. And you can achive the same by adding extra src-address-type=!local. So in most cases, it's whatever you like best.
5) That would be for main NAT rule, which is not shown here.
6) It's the thing known as hairpin NAT.
7) It's name of OP's LAN interface. You can name them any way you like.
 
User avatar
anav
Forum Guru
Forum Guru
Posts: 21986
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada
Contact:

Re: LAN availability from LAN by IP Cloud

Wed May 09, 2018 8:51 pm

1) The dst-address-type=local means exactly what it says, any IP address assigned to router
2) If you want to keep same port number, you don't need to set to-ports. People add it because... I don't really know why, maybe they are used to it from other routers, they just like it, have OCD, anything...
3) When doing hairpin NAT, limiting dstnat rules for WAN interface is exactly what you don't want to do, because it wouldn't work. Request from LAN, even though they have WAN address as destination, still have in-inteface=LAN.
4) It's up to you. Using src-address=<LAN range>/<mask> is probably just the most straightforward. Address list is not bad idea, if you can reuse it elsewhere. Or using it with range, to exclude router's own LAN address is perhaps a little better, because you avoid srcnatting connection from router itself. On the other hand, it doesn't really hurt, if that happens. And you can achive the same by adding extra src-address-type=!local. So in most cases, it's whatever you like best.
5) That would be for main NAT rule, which is not shown here.
6) It's the thing known as hairpin NAT.
7) It's name of OP's LAN interface. You can name them any way you like.
1. Say what, do you mean that its a way of indicated the destination address is public IP address of the router? or do you mean a LANIP on the router??
2. Fine
3. Say what, so he could have had an in-interface LAN rule and that would have been okay??
4. Thanks
5. Would have to see both NAT rules to understand. :-(
6. Okay but painful, I will add a graphic of how I achieved this in the past.........
7. Okay that clears up what that name referred too.

OVerall still a rats nest.
Goal, use WANIP to access LAN server from LAN.

Need a dst-nat rule that doesn't identify a wan interface but instead you simply state dst=local as a way of telling the router that the request for server access is actually internal (special case). In other words, since your mimicking WAN access in a way, one has to pretend to simulate unsolicited traffic.
Further you need a special source nat rule, because one is carrying on the charade of outgoing and return traffic, that says anyone from the LAN with intended traffic to (HERE IS THE CONFUSING PART) to an internal LANIP (WHY THE EFFING FFF is this not the public WANIP) and finally its going out the LAN interface (which is also weird as one does not use WAN interface )

So what is actually physically happening here.............. does the request actually leave the router and hit the ISP gateway and come back.... I amma lost.
 
Sob
Forum Guru
Forum Guru
Posts: 9188
Joined: Mon Apr 20, 2009 9:11 pm

Re: LAN availability from LAN by IP Cloud

Wed May 09, 2018 10:56 pm

1) It means any address the router has, assigned to any interface.
3) Yes for connections from inside. But then you would need either another rule for connections from outside, or you'd need address list with both LAN and WAN, which for typical setup would be all interfaces, so it would be kind of pointless.
5) Main NAT rule is usually simple /ip firewall nat add chain=srcnat out-interface=WAN action=masquerade. That takes care of outgoing connections to internet.

And it's all actually simple (as possible).

Ideally you'd use dst-address=<public address on WAN> for dstnat rule, because it's exactly what you need. But since many setups use dynamic address on WAN, you can't really do that, because you don't know the address (= it can change at any time) and there's no dst-address=the-address-currently-on-WAN shortcut. Using dst-address-type=local is a compromise. It matches even those addresses you don't need, but it's usually not a problem. And if you really need some to not match (typically router's LAN address), you can exclude it.

And changing addresses is simple too. First the packet goes to public address and dstnat changes it to internal address of server. And then there's srcnat (hairpin) rule that changes source to router's LAN address (when using masquerade). It's nicely described on hairpin NAT page in wiki.

If you would ask why it has to be router's LAN address, the answer is that it doesn't. In fact, it can be any address that's not in LAN subnet. For example, hairpin NAT rule on my home router (which has static public address) is:
/ip firewall nat
add action=src-nat chain=srcnat dst-address=192.168.80.0/24 src-address=192.168.80.0/24 to-addresses=<public address on WAN>
And when I connect to webserver (with ports forwarded from public IP to internal machine), the connection looks like it's coming from my public address (I like it more than router's LAN address). And you don't have to stop there. You can use any random addres (preferably some that's not used anywhere else). Or you can map requests from LAN client to some other virtual subnet and be able to tell them from each other.

Final point, no, traffic does not go back to ISP, connections from inside don't touch WAN interface at all.

Who is online

Users browsing this forum: No registered users and 21 guests