One little problem, we didn't define exact setup for the example, so there are multiple ways how to handle it. What I posted could be for one ISP connection with two public addresses. That's how I understood your "WANIP 1234/5678", as two public addresses assigned to router, and that rule #2 should work with one and rule #3 with the other. And in-interface=<WAN> (or in-interface-list=<WANs> if there would be more than one internet connection) in rules #1 and #4 is the basic port forwarding config, where you don't care about destination (and which is in many cases wrong; sorry, I took a shortcut)...
See, that's the thing, there are too many ways how to handle things. Even with clearly defined setup, there's usually more than one way how to reach target goal. And they are often not 100% right or wrong, you can use shortcuts that are perfectly fine for one situation and better solution would be just waste of resources, but they would not work well for seemingly similar setups, only because there's one tiny little difference that changes everything. And now when we don't have exact setup to work with, I can imagine all missing details any way I want and number of possible solutions is endless. And it can also be confusing, when you expect something else.
So, lets try it like this:
Port forwarding uses NAT (dstnat), and it's nothing special, it's just a very simple action that changes destination address and/or ports. It's just one processing step. Packets come to router, dstnat changes destination, router finds out where to send it based on destination address (in this case the changed one), then it goes through forward filter and if it's not stopped there, router will send it out, but there's still srcnat which could change source. And that's it. When I have conditional dstnat rule, then when the condition is not met, dstnat does not happen, packets keeps original destination address (public IP of router), which will send them to input chain and there they will be dropped by default firewall.
About dstnat rules and possible ways to match packets, probably the most correct is to use dst-address. When you're connecting to e.g. http://yourserverbehindnat.domain.tld, the hostname resolves to one specific address, so you should be looking for that. But the address is often not static, so you can't do that, without updating the rule all the time. That's why people often use in-interface, with reasoning (if they have any) that it must be for the right address, when it came to router from internet. Which is not exactly correct, it might be also fake packet from evil hacker or something (and it's whole different story). It's also bad habit, because even though it's mostly fine when you have only one address, people get used to it and then they wonder why it makes problems when they get more addresses.
Another possible problem is that sometimes you want to be able to access same hostname also from LAN (the same one where's the target server). For that, you need another thing called hairpin NAT, but it can't work when your dstnat rules don't work for connections from LAN. And with in-interface=WAN they won't.
Yet another approach it to use dst-address-type=local, and it will match when destination address is assigned to router. No matter how often your WAN address changes, it will still work. But it will match any of them. So when you do this for e.g port 80, it will work great for connections from outside and inside (if you add hairpin NAT rule), but you'll block yourself from accessing WebFig on <router's LAN IP>:80, because it also matches dst-address-type=local and dstnat will redirect the request to webserver machine. So you'll have to add extra dst-address=!<router's LAN IP> and it will finally work. At least for most simple cases, I can still imagine some more complex ones, where it could be wrong.
About jumps example, imagine you have several WANs, you want different sets of dstnat rules for each, and you have a lot of them:
Code: Select all
/ip firewall natadd action=dst-nat chain=dstnat in-interface=WAN1 <other conditions><other 998 rules for WAN1>add action=dst-nat chain=dstnat in-interface=WAN1 <other conditions>add action=dst-nat chain=dstnat in-interface=WAN2 <other conditions><other 998 rules for WAN2>add action=dst-nat chain=dstnat in-interface=WAN2 <other conditions>add action=dst-nat chain=dstnat in-interface=WAN3 <other conditions><other 998 rules for WAN3>add action=dst-nat chain=dstnat in-interface=WAN3 <other conditions>If you do it like this and a new incoming connection comes to WAN4, router will have to check all 3000 rules, before realizing that none is applicable. But if you do:
Code: Select all
/ip firewall natadd action=jump chain=dstnat in-interface=WAN1 jump-target=<dedicated chain for WAN1>add action=jump chain=dstnat in-interface=WAN2 jump-target=<dedicated chain for WAN2>add action=jump chain=dstnat in-interface=WAN3 jump-target=<dedicated chain for WAN3>add action=dst-nat chain=<dedicated chain for WAN1> <other conditions>...Then for the same connection, only three rules will be checked.
Somehow then, the Router Has the ability to check the traffic against the NAT rules to see if it matches a DST NAT RULE and if so says JUMP or GO TO PORT FORWARD process.
There's really no "port forward process", it's just a simple change of destination address, as described above. And similar to this, all conditions you can use for any rule are just simple checks, if current packet has given property or not. Don't look for anything complicated, it's not there.
Ok, there is some "magic" involved, a connection tracking, which understands the traffic flow, recognizes packets that belong to same connection, etc. It's the thing that makes stuff like connection-nat-state work. But don't worry about that, just know it's there and it "just works".
I am not seeing any advantage or savings but instead see creating more rules and processes than is required??????
Again, it doesn't do much, when you have only few rules and it might not be worth it to do something like this. Some things only start to make sense when you're dealing with large amount of stuff.
