Ok, so recently had a few conversations/arguments regarding RouterOS firewall, and because of my novice knowledge level of network engineering, I would like to find clarification on the following:

The firewall is built on the idea that only specific IPs have access to Internet to specific Internet IPs, everything else is blocked. Now, when a system sends to packet for SYN and then the server on the other side responds with ACK, a session is being established for data transfer. On the RouterOS, I see session being 60 seconds and then renegotiates. So is the following true:

1. During that time, there is a possibility for someone to intercept the session / MITM. If so, how can it be further protected
2. If you have public IPs to which local IPs can connect, can a public IP attempt to connect to local first? (NOTE: all input is being blocked other then 'established' connections.)
3. If session is terminated, but the session on RouterOS is still showing the countdown of 50 seconds, does that mean, that during that 50 seconds, someone can try to connect presenting itself as approved public IP?
4. Upnp and port triggering, does it have anything to do with the above, in a sense that if you have approved public IP and open sessions etc, someone can connect? (I understand that this questions is not very clear, as I'm trying to understand how on the structural and operation levels Upnp (universal plug and play), and port triggering works on Mikrotik).

An established connection should be tracked for 24 hours at minimum, I don't know where you're seeing 60 seconds but that certainly doesn't sound right. You should be seeing SYN, SYN+ACK, ACK as the connection establishment procedure. I'm also not clear what you mean by renegotiating, all connection setup parameters are established in the initial three way handshake.

Once a connection is established, the firewall will permit (barring any other rules) any outside IP to send packets to the WAN IP:port opened by that specific connection. Obviously for TCP this doesn't make much sense as the endpoint will reject any TCP segments not from the peer, but for UDP this allows any remote host to connect to the internal host once a "connection" is open.

1) Protecting against a network MITM is not possible at the TCP/IP level. You should use ipsec or TLS to protect sensitive communications and ensure host authenticity.

2) Not entirely sure what you mean by this, by public IP do you mean on your own device or an external service? If the public IP is inside your network then it will already be bypassing any inbound firewall rules on your WAN interface, it depends how you routing is set up if it is able to route to a local IP. In the default configuration an external public IP outside of your network can not connect to anything.

3) If the session closes but the conntrack entry stays, then the shutdown was unclean (eg timeout) or UDP. As mentioned earlier, there is no endpoint restriction on an established conntrack entry, so any external IP would be able to send traffic to the endpoint that's still open.

4) UPNP is a means for a device to ask the firewall to forward a port to itself, so external public IPs can communicate with the internal LAN IP without requiring an outbound connection.

when a system sends to packet for SYN and then the server on the other side responds with ACK, a session is being established for data transfer. On the RouterOS, I see session being 60 seconds and then renegotiates.

The connection tracker is a complex piece of the firewall.

• when handling TCP, it tracks the protocol state of each session, which is explicitly established by (SYN>,<SYN+ACK,ACK>) and can be torn down in "normal" (FIN) and "emergency" (RST) mode. Plus, because the endpoint may restart and lose the TCP session state, the connection tracker uses an expiration timeout - if no packet in either direction is seen before the timeout expires, the connection is removed although the TCP session had not been actively terminated by any of the endpoints. Passage of any packet belonging to that connection resets the timeout to the initial value which is configurable and defaults to 24h. This is the reason why most TCP stack implementations send "keepalive" packets which carry no payload and just make the firewalls along the way keep deeming the connection alive.
• when handling UDP, there is no protocol state to track, so the firewall just looks at timeouts and packet directions. So when the initial packet goes in one direction, the connection tracker opens a time window during which a packet in opposite direction is expected to come; if it does not, the connection is removed, if it does, the connection is considered established and another timeout is used, which is reset by a packet in any direction. For generic UDP, the second timeout is 3m by default, but for particular application protocols (like SIP), a special software module of the connection tracker is used to track the application protocol state, and in such case, other timeout values may be used.

1. During that time, there is a possibility for someone to intercept the session / MITM. If so, how can it be further protected

It depends on what do you mean by interception. Anyone/anything on the path between the endpoints may see the contents of the packets; if the context is a plaintext one, he/it gets all the information. With more advanced techniques, it can even change the information. And with other techniques, it is possible to force the packets in either endpoint's LAN through a monitoring point which is not on the direct path between the endpoints.

In case of encrypted sessions, MITM attack often requires a change of the packet contents (in particular, the cryptographic information) so that the attacker could even decrypt the information and read it, because the encryption key is negotiated between the endpoints so passive decryption is not possible. Certificates confirming the identity of the endpoints are widely used to detect this. If we leave aside that some users ignore the security warnings, some enterprise policies work with local certification authorities which the users' devices are configured to trust and which the security device uses to sign forged certificates, making the user device accept them as valid ones. This is used where company security concerns are in conflict with company co-worker's privacy.

2. If you have public IPs to which local IPs can connect, can a public IP attempt to connect to local first? (NOTE: all input is being blocked other then 'established' connections.)

Not if the firewall is configured properly. The first packet of each connection must be let through (and thus establish the connection) only if it goes in the right direction. Plus, if you use NAT and you do want to permit external clients to connect to some servers in your LAN via your external address, you have to use additional means (commonly called "port forwarding") to link a certain port on the external address with a certain port on an internal address to tell the NAT device where to deliver the initial packet.

A packet is considered to belong to an existing connection if its source and destination socket addresses (IP address:port) match those of the connection, and in case of TCP, if the TCP flags come in "legal" combination and match the connection state (a packet containing a RST flag will not be processed as "new"). So another public IP cannot use an existing connection to establish a new one to the client protected by the firewall, but, as said above, a MITM can modify the contents of the previously established one and even completely hijack it. This is e.g. what the hotspot does (you open any web page in your browser and get the welcome page instead).

3. If session is terminated, but the session on RouterOS is still showing the countdown of 50 seconds, does that mean, that during that 50 seconds, someone can try to connect presenting itself as approved public IP?

Not exactly connect and not every someone, and only if the connection state is still open on the endpoint, but a MITM could "take over" the session, pretending to be the original remote participant of the session.

4. Upnp and port triggering, does it have anything to do with the above, in a sense that if you have approved public IP and open sessions etc, someone can connect? (I understand that this questions is not very clear, as I'm trying to understand how on the structural and operation levels Upnp (universal plug and play), and port triggering works on Mikrotik).

Yes, it does. Using UPNP, a device on LAN can dynamically configure port forwarding as mentioned in point 2. So if you permit UPNP, a web server in your LAN can tell the firewall "I'm here, listening at port 80, so forward to me whatever comes to port 80 on your external address". The UPNP agent then dynamically creates a corresponding rule in the firewall.

Similar thing happens with ftp, the ftp control session contains information regarding the transport session, so the ftp helper of connection tracker finds there at what socket address the server in LAN is listening and modifies the message with its own external address and port, so when the remote client sends a SYN packet to that socket, it is considered "related" and forwarded where necessary. However, in this case, no corresponding rule is visible in the firewall printout.

Not sure what you mean by port triggering.