Port Forwarding firewall rules

ilja · Sun Feb 23, 2020 6:01 pm

Hey all. Can some please help me to setup simple port forwarding which i really don't get.

Came from D-LINK where it was super simple out-of-box UI and am a little frustrated with Mikrotik firewall settings.

All i need is to do a port forwarding the following way:

WAN(10.10.10.10) --- Mikrotik ---- server(192.168.88.10:8123)
So i could access server by going to 10.10.10.10:8123 both locally and externally.

As well as SSH to the server by using 10.10.10.10:733
WAN(10.10.10.10) --- Mikrotik ---- server(192.168.88.10:733)

With what i currently have i was able to connect to the server 10.10.10.10:8123, but only externally. It doesn't work when i m trying that internally over wlan.

[admin@MikroTik] > export hide-sensitive  
# feb/23/2020 17:00:39 by RouterOS 6.46.3
# software id = 63WL-9G9C
#
# model = 2011UiAS-2HnD
# serial number = 467304B1DBAF
/interface bridge
add admin-mac=4C:5E:0C:43:D6:3E auto-mac=no comment=defconf name=bridge
/interface wireless
set [ find default-name=wlan1 ] band=2ghz-b/g/n channel-width=20/40mhz-XX country=sweden disabled=no distance=indoors installation=indoor mode=ap-bridge ssid="The Apartment" wireless-protocol=802.11
/interface list
add comment=defconf name=WAN
add comment=defconf name=LAN
/interface wireless security-profiles
set [ find default=yes ] authentication-types=wpa-psk,wpa2-psk mode=dynamic-keys supplicant-identity=MikroTik
/ip pool
add name=dhcp ranges=192.168.88.11-192.168.88.254
/ip dhcp-server
add address-pool=dhcp disabled=no interface=bridge name=defconf
/interface bridge port
add bridge=bridge comment=defconf interface=ether2
add bridge=bridge comment=defconf interface=ether3
add bridge=bridge comment=defconf interface=ether4
add bridge=bridge comment=defconf interface=ether5
add bridge=bridge comment=defconf interface=ether6
add bridge=bridge comment=defconf interface=ether7
add bridge=bridge comment=defconf interface=ether8
add bridge=bridge comment=defconf interface=ether9
add bridge=bridge comment=defconf interface=ether10
add bridge=bridge comment=defconf interface=sfp1
add bridge=bridge comment=defconf interface=wlan1
/ip neighbor discovery-settings
set discover-interface-list=LAN
/interface list member
add comment=defconf interface=bridge list=LAN
add comment=defconf interface=ether1 list=WAN
/ip address
add address=192.168.88.1/24 comment=defconf interface=ether2 network=192.168.88.0
/ip dhcp-client
add comment=defconf disabled=no interface=ether1
/ip dhcp-server network
add address=192.168.88.0/24 comment=defconf gateway=192.168.88.1
/ip dns
set allow-remote-requests=yes
/ip dns static
add address=192.168.88.1 comment=defconf name=router.lan
/ip firewall filter
add action=accept chain=input comment="defconf: accept established,related,untracked" connection-state=established,related,untracked
add action=drop chain=input comment="defconf: drop invalid" connection-state=invalid
add action=accept chain=input comment="defconf: accept ICMP" protocol=icmp
add action=accept chain=input comment="defconf: accept to local loopback (for CAPsMAN)" dst-address=127.0.0.1
add action=drop chain=input comment="defconf: drop all not coming from LAN" in-interface-list=!LAN
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
add action=drop chain=forward comment="defconf: drop invalid" connection-state=invalid
add action=drop chain=forward comment="defconf: drop all from WAN not DSTNATed" connection-nat-state=!dstnat connection-state=new in-interface-list=WAN
/ip firewall nat
add action=masquerade chain=srcnat comment="defconf: masquerade" ipsec-policy=out,none out-interface-list=WAN
add action=dst-nat chain=dstnat comment="Raspberry Pi" dst-port=8123 in-interface=ether1 protocol=tcp to-addresses=192.168.88.10 to-ports=8123
/system clock
set time-zone-name=Europe/Stockholm
/system routerboard settings
set auto-upgrade=yes cpu-frequency=700MHz silent-boot=yes
/tool mac-server
set allowed-interface-list=LAN
/tool mac-server mac-winbox
set allowed-interface-list=LAN

chuckt · Sun Feb 23, 2020 6:23 pm

Just use the local IP inside the LAN

192.168.88.10:8123

Alternatively you might be able to use “hairpin NAT” or loopback.

ilja · Sun Feb 23, 2020 7:29 pm

Just use the local IP inside the LAN

192.168.88.10:8123

Alternatively you might be able to use “hairpin NAT” or loopback.

Thank you, @chuckt, for your answer. I would still want/need to make it work internally with the same public ip(it's more of a domain).

Thank you for referring to Hairpin NAT, i looked at https://wiki.mikrotik.com/wiki/Hairpin_NAT and tried:

/ip firewall nat
add action=masquerade chain=srcnat comment="defconf: masquerade" ipsec-policy=out,none out-interface-list=WAN
add action=dst-nat chain=dstnat comment="Raspberry Pi" dst-port=8123 in-interface=ether1 protocol=tcp to-addresses=192.168.88.10 to-ports=8123
add action=masquerade chain=srcnat dst-address=192.168.88.10 dst-port=8123 protocol=tcp src-address=192.168.88.0/24 src-port=8123

But it doesn't work.

anav · Sun Feb 23, 2020 7:30 pm

For port forwarding you need to make a dst nat rule for each port forwarding you would like to accomplish.
To allow port forwarded traffic through the firewall, a single FORWARD chain rule needs to be in place.
The default firewall rules already contain this rule last time I checked.

Quite separately from above which is external access, in internal access.
To be able to access the server via the WANIP address I believe there are two viable methods to do this./
1. Via hairpin nat - the official prescribed way. Works very well and covers a wide range of possibilities (most comprehensive).
2. Via static DNS ENTRY - believe this may be easier, work for most cases.

hairpin the packets go to the router and back to the server when server is accessed from the LAN
DNS, the packets go direct to the server when the server is accessed from the lan.

ilja · Sun Feb 23, 2020 7:41 pm

For port forwarding you need to make a dst nat rule for each port forwarding you would like to accomplish.
To allow port forwarded traffic through the firewall, a single FORWARD chain rule needs to be in place.
The default firewall rules already contain this rule last time I checked.

Quite separately from above which is external access, in internal access.
To be able to access the server via the WANIP address I believe there are two viable methods to do this./
1. Via hairpin nat - the official prescribed way. Works very well and covers a wide range of possibilities (most comprehensive).
2. Via static DNS ENTRY - believe this may be easier, work for most cases.

hairpin the packets go to the router and back to the server when server is accessed from the LAN
DNS, the packets go direct to the server when the server is accessed from the lan.

Thank you, @anav, for you reply. I like the idea of the first option - to do it correctly. Could you please take a look on my previously posted message, where i have attempted setting up Hairpin NAT according to the manual, but missed something? Maybe you would be able to help spotting it

Sob · Sun Feb 23, 2020 9:16 pm

Copy & paste from another thread:

You can't have dstnat rules with in-interface=ether1, they can't work from inside, because connections will be coming from LAN interface. The best is dst-address=<public address>, but if it's dynamic, you can use dst-address-type=local instead and it will match all local addresses. In case you need those ports also on router, e.g. for management from LAN using WebFig, add additional dst-address=!<192.168.1.x> as exception (where 192.168.1.x is router's local address; don't forget "!" which means "not").

ilja · Sun Feb 23, 2020 11:23 pm

Copy & paste from another thread:

You can't have dstnat rules with in-interface=ether1, they can't work from inside, because connections will be coming from LAN interface. The best is dst-address=<public address>, but if it's dynamic, you can use dst-address-type=local instead and it will match all local addresses. In case you need those ports also on router, e.g. for management from LAN using WebFig, add additional dst-address=!<192.168.1.x> as exception (where 192.168.1.x is router's local address; don't forget "!" which means "not").

That's exactly what i have tried setting, but with no luck :/

/ip firewall nat
add action=masquerade chain=srcnat comment="defconf: masquerade" ipsec-policy=out,none out-interface-list=WAN
add action=masquerade chain=srcnat comment="hairpin nat" dst-address=!192.168.88.1 dst-port=8123 protocol=tcp src-address=192.168.88.0/24 src-port=8123
add action=dst-nat chain=dstnat comment="Raspberry Pi" disabled=yes dst-port=8123 in-interface=ether1 protocol=tcp to-addresses=192.168.88.10 to-ports=8123
add action=dst-nat chain=dstnat dst-address=!192.168.88.1 dst-address-type=local dst-port=8123 protocol=tcp to-addresses=192.168.88.10 to-ports=8123

anav · Sun Feb 23, 2020 11:58 pm

Sob, I got confused reading your cryptic reply lol.
What about Stevocee's basic approach to hairpin nat for dynamic IP.

Step 1. Add a second masquerade rule and put that as the first rule in the NAT chain. (as we want to capture lan to lan traffic before any real lan to wan traffic).

/ip firewall nat
add chain=srcnat src-address=192.168.1.0/24 dst-address=192.168.1.0/24
action=masquerade comment="Hairpin Nat"
(assuming that we have one subnet and the server is also on that subnet)

Step 2 . The dynamic IP doesn't allow us to use destination address as it changes (dst- address works better in the dst-nat rule then the usual In-interface=wan because now we are trying to handle both incoming from WAN and incoming from LAN instances.). A static IP address would be dirt simple and we would be done already.
The idea here is to use IP Cloud!!
(1) a. enable ip cloud
b. put in current WANIP and
c. capture the DNS name given

(2) a. create a firewall address list called MYWANIP and use the name from c. above for the address entry.
b. now modify the current dst-nat port forwarding rule ----> remove in-interface=wan and use destination address-list and put in the MYWANIP entry.

So this would look like. ILJA try this............
/ip firewall nat
add action=masquerade chain=srcnat comment="HairpinNAT" src-address=192.168.88.0/24 dst-address=192.168.88.0/24 (new rule)
add action=masquerade chain=srcnat comment="NAT" out-interface=WAN (standard rule)
add action=dst-nat chain=dstnat comment="Server RPi" dst-port=8123 protocol=tcp dst-address-list=MYWANIP to-addresses=192.168.88.10 (modified standard rule)

Done and simple!

Question. Is there not a case where DNS is a better option?
I seem to recall there are two cases to consider
a. where one is attempting to reach the server when its on the same subnet as the server and
b. where one is attempting to reach the server from a different subnet but still behind the router etc....

anav · Mon Feb 24, 2020 12:02 am

That's exactly what i have tried setting, but with no luck :/

/ip firewall nat
add action=masquerade chain=srcnat comment="defconf: masquerade" ipsec-policy=out,none out-interface-list=WAN
add action=masquerade chain=srcnat comment="hairpin nat" dst-address=!192.168.88.1 dst-port=8123 protocol=tcp src-address=192.168.88.0/24 src-port=8123
add action=dst-nat chain=dstnat comment="Raspberry Pi" disabled=yes dst-port=8123 in-interface=ether1 protocol=tcp to-addresses=192.168.88.10 to-ports=8123
add action=dst-nat chain=dstnat dst-address=!192.168.88.1 dst-address-type=local dst-port=8123 protocol=tcp to-addresses=192.168.88.10 to-ports=8123

To many rules depending on which method you use and probably some in conflict and order is important.

First rule should be new masquerade rule!
Second rule is the standard masquerade rule to cover lan to wan traffic
Only one NAT RULE is required for destination NAT you seem to have two??????
If you like the ugly and confusing ;-P second dst nat rule with local address with ! , I would bet this rule has to come before the standard dst nat rule in the order.

chuckt · Mon Feb 24, 2020 1:16 am

@anav

This IP Cloud looks interesting, but when I look at the documentation I see this note:

Note: IP/Cloud requires a working license on Cloud Hosted Router (CHR).

I'm not sure what this CHR is. Is that something we can setup through Mikrotik, or is that some 3rd party?

NVM:
I used my Google Fu and found that the service is available for download through Mk and the license is free up to 1Mbps upload per interface.

chuckt · Mon Feb 24, 2020 2:18 am

@ilja

I don’t know if you have it working yet, but I looked at your exports and I don’t see where you’ve done what’s in the Wiki link for Hairpin NAT.

Did you try it as documented there? Also, do you have a dynamic IP form your ISP?

Sob · Mon Feb 24, 2020 2:30 am

@ilja: This:

/ip firewall nat
add action=masquerade chain=srcnat comment="hairpin nat" dst-address=!192.168.88.1 dst-port=8123 protocol=tcp src-address=192.168.88.0/24 src-port=8123

is wrong. The src-port=8123 is complete nonsense, it shouldn't be there. If you remove it, it will work, but can affect some traffic it shouldn't, so better use @anav's:

/ip firewall nat
add action=masquerade chain=srcnat comment="HairpinNAT" src-address=192.168.88.0/24 dst-address=192.168.88.0/24

It's universal rule, common for all ports, so if you add another forwarded port in future, you won't need to add another srcnat rule.

@anav: DDNS method is not wrong and it will work, but it's not ideal, because there will be always a short period when router already has new address, but there's still old one in address list, so port forwarding won't work until current address list entry expires. If you want to use dst-address with dynamic address, use dhcp lease script to update it. Only case when you can't avoid using DDNS is when you need hairpin NAT with double NAT and your router is the second one without public address.

Edit: One more, if you have:

/ip firewall nat
add action=masquerade chain=srcnat comment="HairpinNAT" src-address=192.168.88.0/24 dst-address=192.168.88.0/24
add action=masquerade chain=srcnat comment="NAT" out-interface=WAN

then the order doesn't matter, because it will never happen that both these rules would match for same packet (unless you come up with some creative misconfiguration). When 192.168.88.0/24 is your LAN, out-interface for first rule will be always LAN. In fact, it's better to have main NAT first, because vast majority of connections will be from LAN to internet and only few hairpin ones from LAN back to LAN. So by having main NAT first, you'll save 0,00nothing% resources (not much, but still > 0).

anav · Mon Feb 24, 2020 4:19 pm

Hi Sob, thanks for the clarifying info and the delay between address update and IP change cannot really be that significant..........?

Sob · Mon Feb 24, 2020 5:03 pm

I don't remember what TTL MikroTik's DDNS uses, I think it was only a minute, so not really a problem, but why not make things perfect when you can?

mkx · Mon Feb 24, 2020 7:33 pm

I don't remember what TTL MikroTik's DDNS uses, I think it was only a minute ...

Yup, 60 seconds.

anav · Mon Feb 24, 2020 8:00 pm

Okay Sob, I am game, will go on your merry go round and hope I dont puke.........

So lets say we agree on the first two source nat rules.......
/ip firewall nat
add action=masquerade chain=srcnat comment="HairpinNAT" src-address=192.168.88.0/24 dst-address=192.168.88.0/24
add action=masquerade chain=srcnat comment="NAT" out-interface=WAN

Then we can debate having ONE DST NAT RULE aka Stevee's method Or
Doing it via two rules without the need for IP cloud

Would this be correct??
add action=dst-nat chain=dstnat comment="PF- From WAN" dst-port=8123 protocol=tcp in-interface=ether1 to-addresses=192.168.88.10
add action=dst-nat chain=dstnat comment="PF- From LAN" dst-port=8123 protocol=tcp dst-address=!192.168.88.1 \
dst-address-type=local to-addresses=192.168.88.10

As per the source nat rules, would it be fair to say, order does not matter?

Sob · Mon Feb 24, 2020 8:18 pm

One dstnat rule is enough. Look closely at the options, your "PF- From LAN" rule will work for both connections from LAN and WAN, there's no need to have the other one ("PF- From WAN") as extra rule. And I already explained how it is with order of srcnat rules, just scroll a little bit back.

anav · Mon Feb 24, 2020 8:56 pm

Well I never.............hmmmmmmm You cant be right ;-P
Okay here is where I lose it................. the destination address type is where I get confused never having usied this line/parameter.

Okay here is what I think your are doing, (must have a unicorn on your head).
The destination address bit covers any external incoming attempt at destination nat to that port.
The local address bit covers any internal coming attempt of destination nat to that port BUT HOW>>>>>>>>>>>??

Nope thats not right either........... egads feel like a pretzel.
Okay from the end user perspective sure, the destination part of the rule works.
Regardless of source of request two things are true, attempt is made to connect to WANIP on that port or to connect to any IP other than that described by the LAN.
( seems wide open and a security concern to me..... just a gut feeling LOL )

But what is the purpose of the second bit, the local address bit????????

AHH OKAY, so local means - local - if dst-address is assigned to one of router's interfaces

In other words, one is stating, for any destination nat request targetting port 8123 that is destined for or being directed at ANY IP address that can be described as:
a. any IP except that coming from the LAN (as I stated not a good idea not secure) and
b. that destination IP described at a., HAS TO BE assigned one of the routers interfaces (which includes wan - and thus where we get security back)

You are a tricky soul mr sob!!
If I had to buy you a case of beer every time you were right, you would be on your third liver transplant!!

Sob · Mon Feb 24, 2020 11:42 pm

It's not ideal, but not necessarily insecure either. Yes, dst-address-type=local will match any address on router, except 192.168.88.1, which we excluded using dst-address=!192.168.88.1, because we want to keep it for accessing services on router like WinBox, WebFig and such (well, probably not on port 8123, but generally we don't want to forward connections to 192.168.88.1 elsewhere).

So if there is another address on router, it could be for example 192.168.99.1 used by VPN server or another LAN, connection coming from internet to this address will be also forwarded to internal server. But is that a problem? Most likely not. The goal is to forward port from public address to internal server, so anyone can use the public address to reach it, and this other, much more complicated way to reach the same server doesn't make a difference.

But if you don't like it, you can exclude also other addresses if you use dst-address-list=!<list of local address>. If you know that you'll have public address directly on router, you can add whole 192.168.0.0/16 and other local ranges.

Or if you want it completely clean, then use only dst-address=<public address> as if it was static and keep it updated using lease script. You can use the same simplified way as with routes (viewtopic.php?p=748218#p748218).

ilja · Thu Feb 27, 2020 9:06 pm

Hey, gentleman.

Thank you so much for all your comments and help! Unfortunately, i have been a little caught up with work the past week. Will try to implement all your recommendations during the weekends and get back to you.
Thank you!

anav · Thu Feb 27, 2020 10:13 pm

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.

anav · Thu Mar 05, 2020 6:37 pm

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

Sob · Thu Mar 05, 2020 6:45 pm

Add ten new dstnat rules that should also work with hairpir NAT and you'll see the difference.

anav · Thu Mar 05, 2020 7:06 pm

Got it, its more generic and only need one rule vice 10 LOL..........
(aside question does putting subnets on separate bridges provide L2 separation)

Sob · Thu Mar 05, 2020 8:54 pm

I'm not sure where are you going with that, but two bridges, like any other interfaces don't have L2 connectivity between them.

anav · Thu Mar 05, 2020 9:09 pm

duplicate

anav · Thu Mar 05, 2020 9:10 pm

I'm not sure where are you going with that, but two bridges, like any other interfaces don't have L2 connectivity between them.

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/networ ... eless_vlan )

Sob · Thu Mar 05, 2020 9:48 pm

I didn't study it in detail, but it looks like old style config from before bridge VLAN filtering was added to RouterOS.

anav · Fri Mar 06, 2020 3:36 am

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???

Sob · Fri Mar 06, 2020 4:32 pm

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.

anav · Fri Mar 06, 2020 9:49 pm

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

Sob · Sat Mar 07, 2020 2:06 am

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

anav · Sat Mar 07, 2020 5:28 am

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?

Sob · Sat Mar 07, 2020 5:10 pm

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.

anav · Sat Mar 07, 2020 5:38 pm

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

.......

1. 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

......

2. 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?

3. 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........

Sob · Sat Mar 07, 2020 6:09 pm

1) 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.

3) 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.

anav · Sat Mar 07, 2020 6:19 pm

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??)

.....

Sob · Sat Mar 07, 2020 6:28 pm

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=<WAN IP>, not dst-address=<WAN IP>.

anav · Sat Mar 07, 2020 7:23 pm

1) 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??

Sob · Sat Mar 07, 2020 9:37 pm

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.