chain=input is used for packets destined to the router itself. If the router IP is 1.1.1.1 but there’s a dst-nat rule forwarding tcp 80 traffic to 192.168.1.1 and a connection from the internet comes in to 1.1.1.1:80 will this traffic match the input or forward chain? or both?
And again with Src NAT. If there’s an outgoing connection from 192.168.1.1 to 5.5.5.5 and the router has a srcnat rule to change the source IP to 1.1.1.1 (itself) is this still only in the forwarding chain, or the output chain?
DST-NAT happens in PREROUTING chain which is matched by anything what comes into router. after DST-NAT happens and whole PREROUTING chain ends, it goes to “routing decision” which decide if it is INPUT or FORWARD. As the DST-IP does not match any of router’s IP anymore, it will continue to FORWARD chain (not into INPUT)
Same applies for SRC-NAT which happens in POSTROUTING chain, which occurs after FORWARD chain ended (so no OUTPUT)
Thanks for info! I didnt know as there is “Changes in RouterOS v6” section, I somehow thought is up to date. (and I obviously totally missed note that there is new diagram.. all those years )
Fortunately, answer is correct even according to new diagram
@Večerník, ne tak úplně… in both the old and the new diagram, the srcnat chain follows not only the forward chain but also the output chain. So although it is rarely useful, you can src-nat also locally generated packets.
Just one remark for the OP - srcnat and dstnat rule chains are only traversed by the initial packet of each connection; once the connection context is created by the initial packet, it stores the src-nat and dst-nat result and applies it appropriately (i.e. depending on their direction) to all subsequent packets of that connection. So it is impossible to change the src-nat and dst-nat handling mid-connection.
I am aware of the fact that postrouting happens after both forward and output chains. But in this case, OP was asking specifically, which chain does his example go through, so I tried to stress out that his examples are not going through input/output chain. Apparently, I should express myself better way.
Sorry for the confusion and thanks for correction so other people don’t get confused as well.
So in short
Input chains only if the ‘final’ destination of the packet after all NAT/redirects etc are processed is the router
Output chain only if the router itself generated the packet. Does not apply to packets that are srcnat’d packets even if they use the routers IP address
Almost correct.
Only exception is IP-encapsulated data, which might be forwarded but due to the fact that encapsulation/decapsulation is done by router, encapsulated packet is actually generated/received by router and therefore encapsulated packet must go through input/output chain as well.
Packet is IPv4 (because EOIP is IP-based-tunnel)
I-J) This is not really well shown in example and you need to look at routing detailed diagram
From (I) it goes to Prerouting
then Routing decision
then Input - because dst-ip of eoip packet is router
then ipsec policy
then (J) - because it does not need IPsec
<decapsulate?> yes (because it is recognized as EOIP)
[decapsulation] - now we are getting to real “internal” frame which no longer has router as destination so it gets forwarded via bridge in steps 7-9
… rest is clear, right?
The <decapsulate?> and [decapsulation] blocks are practically internal router processes but it can’t be visualized that way because it needs clear distinction between packets really processed by router (ping reply, http, ssh etc..) and packets encapsulated/decapsulated by router
)
