Hi ilja, Sobs recommendations seems the most foolproof and is easy. I just had to spend time trying to understand what he was doing.
The IP cloud method will yield up to possibly a 60 sec delay when the dynamic IP is changed by the ISP. You are also relying on the outside connectivity and a working IP cloud whereas Sobs suggestion is all contained within the router… Its nice to know how flexible these routers are though. 
Sob for a fixed static WANIP it seems there are two solutions…
The difference is in the second masquerade rule. Can you advise why one is better than another???
Solution 1: (three rules)
/ip firewall nat
add chain=srcnat src-address=192.168.0.0/24 dst-address=192.168.0.100 protocol=tcp dst-port=80
out-interface=LAN action=masquerade
add action=masquerade chain=srcnat comment=“NAT” out-interface=WAN
add action=dst-nat chain=dstnat comment=“PF-Lan&Wan” dst-port=80 protocol=tcp dst-address=staticwanip
to-addresses=192.168.0.100
Solution Sob: (three rules)
add action=masquerade chain=srcnat comment=“HairpinNAT” src-address=192.168.0.0/24 dst-address=192.168.0.0/24
add action=masquerade chain=srcnat comment=“NAT” out-interface=WAN
add action=dst-nat chain=dstnat comment=“PF-Lan&Wan” dst-port=80 protocol=tcp dst-address=staticwanip
to-addresses=192.168.0.100
Add ten new dstnat rules that should also work with hairpir NAT and you’ll see the difference.
Got it, its more generic and only need one rule vice 10 LOL…
(aside question does putting subnets on separate bridges provide L2 separation)
I’m not sure where are you going with that, but two bridges, like any other interfaces don’t have L2 connectivity between them.
duplicate
Oh, its because i see some configs of late with multiple bridges and of course i have a hard-on for vlans LOL.
Curious as to why one would prefer multiple Bridges over vlans in general and in the specific case if one is already using VLANs…
(ex. http://wiki.tuturutu.eu/doku.php/networking/mikrotik/wireless_vlan )
I didn’t study it in detail, but it looks like old style config from before bridge VLAN filtering was added to RouterOS.
Ahh that would explain it…
As you know the only problem with Bridges (since I keep it to one bridge only per device) is knowing when to tag or not tag the bridge on bridge vlan rules.
I know in general its if the bridge is involved in routing then it has to be tagged.
But that gets really fuzzy for me to figure that out for vlans. 
, especially if dealing with an access point bridge and its various configs and also within a router itself for ports that are access only.
(I dont think its as simple as trunk ports yes and access ports no). So what makes a vlan id qualify for tagging the bridge???
If the router itself does not need to participate in VLAN, i.e. it will be only working as switch/bridge for given VLAN, this VLAN does not need to be tagged on bridge interface and you don’t need VLAN interface for it. If the router should be part of VLAN (e.g. for management purposes), this VLAN needs to be tagged on bridge interface and you need VLAN interface for it on top of bridge.
Okay, I guess that begs the question, what do you mean by a management vlan?
Think capac. I need to be able to configure the capac or a 260GS switch.
So typically I put the capac on the homevlan (which in my case is also the management vlan since all other types of traffic (devices, guests etc) are on different vlans).
Is the fact that the capac has got an IP on my home vlan, and i access it through winbox REASON TO TAG the bridge for this vlanID??
(same for the switch)
Notes
I dont change the capac pvid (or switch pvid) default of one.
I dont use bridges for dhcp
It was just an example, it could be anything where the router needs to have access to that VLAN.
Let’s say you have ether1 connected to another router and there are two tagged VLANs on it, 20 and 30. You want this router to be in VLAN 20, i.e. have IP address there and be able to communicate with other devices in VLAN 20. You don’t care about VLAN 30, you just need to pass it between tagged form on ether1 and untagged on ether3.
One way is this:
/interface bridge
add name=bridge vlan-filtering=yes
/interface bridge port
add bridge=bridge interface=ether1
add bridge=bridge interface=ether2 pvid=20
add bridge=bridge interface=ether3 pvid=30
/interface bridge vlan
add bridge=bridge tagged=bridge,ether1 untagged=ether2 vlan-ids=20
add bridge=bridge tagged=ether1 untagged=ether3 vlan-ids=30
/interface vlan
add interface=bridge name=vlan20 vlan-id=20
/ip address
add address=192.168.20.100/24 interface=vlan20
But you can also do this:
/interface bridge
add name=bridge vlan-filtering=yes pvid=20
/interface bridge port
add bridge=bridge interface=ether1
add bridge=bridge interface=ether2 pvid=20
add bridge=bridge interface=ether3 pvid=30
/interface bridge vlan
add bridge=bridge tagged=ether1 untagged=bridge,ether2 vlan-ids=20
add bridge=bridge tagged=ether1 untagged=ether3 vlan-ids=30
/ip address
add address=192.168.20.100/24 interface=bridge
That second option…
That is so weird, set pvid of 20 on the bridge and then untag the bridge on the vlan rule.
Can you express what your are doing in words…
The first config a bit easier but to clarify
a. are you routing traffic through the bridge via the trunk port eth1 to the other router and that is why the bridge is tagged? or …
b. are you tagging the bridge so just to be able to config the router on the other side of eth1?
In other words How do I know if the bridge is acting simply as switch and not routing and thus dont need to tag it?
Is it based on firewall rules I have?
Second config has bridge itself in vlan 20 as untagged port, which allows you to put IP address on bridge directly, without need for extra vlan interface. But you can do this only for one vlan, because bridge interface has only one pvid.
First config, yes, ether1 can be trunk port. And bridge is always acting as switch for its ports, it doesn’t route. Well, there can be routing between bridge and other interfaces. Or between vlans on same bridge. But it’s on higher level, L3 stuff.
And whether you need it tagged on bridge and have vlan interface for it, it’s your choice, you must know why you create each vlan and what this router should route.
Back to Hairpin NAT, 3 nuanced questions come to mind.
If you recall, below is what came out of the discussion for dynamic hairpin nat, then modified for a static WANIP.
…
add action=masquerade chain=srcnat comment="HairpinNAT" src-address=192.168.0.0/24 dst-address=192.168.0.0/24
add action=masquerade chain=srcnat comment="NAT" out-interface=WAN
add action=dst-nat chain=dstnat comment="PF-Lan&Wan" dst-port=80 protocol=tcp dst-address=staticwanip \
to-addresses=192.168.0.100
…
- What happens if I have a second subnet wishing to access the server such as 192.168.10.0/24 is the below correct?
…
add action=masquerade chain=srcnat comment="HairpinNAT" src-address=192.168.0.0/24 dst-address=192.168.0.0/24
add action=masquerade chain=srcnat comment="HairpinNAT" src-address=192.168.10.0/24 dst-address=192.168.0.0/24
…
- a. Why, for the static example are we using Masquerade sourcenat action. I read somewhere that for fixed WANIPs one should use sourcnat action.
…
add action=src-nat chain=srcnat dst-address=staticWanIP out-interface=ethX (still need to note out-interface right?)
…
2 b. I often see source addresses associated with sourcenat action rules - is it required?? In otherwords with a fixed wanip folks are adding in source address subnetss (or source address lists as part of the rule. I thought by default they are all included all ready?
- Finally when I was comparing two methods of the sourcenat rule, the one we discarded (not as efficient) was this one
…
add chain=srcnat src-address=192.168.0.0/24 dst-address=192.168.0.100 protocol=tcp dst-port=80 \
out-interface=LAN action=masquerade
…
What is puzzling me is the need to state the out-interface=LAN, as we dont do it the more efficient rules…
- No. Hairpin NAT is needed only when client and server are in same subnet (you can re-read https://wiki.mikrotik.com/wiki/Hairpin_NAT to understand why). There’s no need for hairpin NAT for different subnets. It won’t break anything if you add it, but it won’t add anything useful either.
2a) Yes, srcnat with static address is better. There’s nice presentation from MikroTik why that is, but I don’t remember the link. But I’m sure you’ve seen it.
2b) It’s needed for example when you have multiple public addresses and want to use different ones based on source addresses. Someone may also use it as kind of protection against unauthorized LAN addresses going out to internet, but that would be better done in forward filter.
- It’s not like out-interface=LAN would be wrong. But if destination address is in LAN subnet, which is on LAN interface, it won’t go anywhere else anyway. Unless you make an extra effort to send it somewhere else. For example, if you have VPN using addresses from LAN subnet, connections between LAN devices and VPN client would be affected by hairpin rule. Adding out-interface=LAN would solve it for LAN->VPN, but VPN->LAN would still be affected, so you would need other rules to solve it. But there’s probably some config where out-interface=LAN would help.
Okay, but what about the sub question…
add action=src-nat chain=srcnat dst-address=staticWanIP out-interface=ethX (still need to note out-interface right?)
For the fixedwanip and sourcnat actions we dont use out-interface=wan, we use dst-address=x.x.x.x.x but is good practice to add out-interface=eth1 ?? or not required?
(We dont want sourcenat to be coming from wan side??)
…
We don’t use action=masquerade for static address (it’s replaced by action=src-nat). We still use out-interface=WAN. And we add to-addresses=, not dst-address=.
- No. Hairpin NAT is needed only when client and server are in same subnet (you can re-read https://wiki.mikrotik.com/wiki/Hairpin_NAT to understand why). There’s no need for hairpin NAT for different subnets. It won’t break anything if you add it, but it won’t add anything useful either.
I tried LOL… but the logic fails me…
regardless of which LANIP the request comes in from on the internal side…
Hmm think this is it…
See the standard case (same LAN)
the client sends a packet with a source IP address of 192.168.1.10 to a destination IP address of 1.1.1.1 on port tcp/80 to request some web resource.
the router destination NATs the packet to 192.168.1.2 and replaces the destination IP address in the packet accordingly. The source IP address stays the same: 192.168.1.10.
the server replies to the client’s request. However, the source IP address of the request is on the same subnet as the web server. The web server does not send the reply back to the router, but sends it back directly to 192.168.1.10 with a source IP address in the reply of 192.168.1.2.
The client receives the reply packet, but it discards it because it expects a packet back from 1.1.1.1, and not from 192.168.1.2. As far as the client is concerned the packet is invalid and not related to any connection the client previously attempted to establish.
So in the same LAN case, the webserver bypasses NAT in a sense and send the response directly back to the client because they are connected at Layer2??? Is this normal behaviour?
The client expecting a reply from the wanip rejects the incoming from the server.
So in the separate LAN case, assuming its NOT on the same bridge (or a separate VLAN), the clients normal behaviour to send back to wanip would occur??
If you don’t have srcnat rule (hairpin), then only dstnat applies. So when server gets the packet, it’s from 192.168.1.10. Server doesn’t know that it came from router and not directly from client (*). It’s not server’s fault to send response directly to 192.168.1.10, it doesn’t know any better, this is what it sees as source. It’s 100% correct behaviour.
Separate subnet doesn’t suffer from this problem. If client 192.168.1.10 connects to public 1.1.1.1 on router and it’s dstnatted to server 192.168.2.10, it’s fine, because server sees 192.168.1.10 as source, it knows that it’s not part of its IP subnet, so it sends response to its default gateway. There’s no difference is the requests came from other local subnet or from internet, all it matter is that it’s not in server’s subnet. Even if the other subnet was in same L2 segment, it would still work.
(*) Technically, it would be possible to find out by looking at source MAC address. You’d then have to configure server in a way that it would send responses to router, if request came for there. In a way, it would be perfect config, client would be able to connect to service using public address, at the same time server would see real client’s address, and everything would still work. Downside is that you’d have to do this for every server. Also depending on specific MAC address of gateway router would not be good, because if you’d replace it, new one would have different MAC address and this would break.