srcnat is undesiredly applied with mark-routing

RouterOS Beginner Basics
21

You have four IP pools aka four vlans but you have identified 10 vlans??

Yes, I have 4 pools for the 4 vlans with a dhcp server. In the other vlans ip addresses are managed manually.


IP filter strict is not usual…loose is the preferred setup.

I tried to make it as secure as possible nowadays. I changed it now to “loose”, but this did not solve my problem.

I am still debugging and trying to find the problem. I am a little unsure if the routing rule really works as expected.

As you know I configured it as recommended:

  • a route with destination 0.0.0.0/0, gateway=192.168.71.244 (opnsense-lan) and routing mark=useOP
  • a routing rule with src-address=192.168.2.0/24, action=“lookup only in table” and table=useOP

To me it seems, as if the packets are looping: 192.168.2.21 tries to send a dns request to 8.8.8.8:53 results in:
192.168.2.21 → 192.168.2.254 (RB4011) → routing to 192.168.71.244 → 192.168.72.254 (RB4011) → routing to 192.168.71.244 → and so on

How shall the traffic “break out” to the internet after looping once above opensense?

22

It will only work I think if the etherport on the MT to opensense is considered a WANPORT ip dhcpclient.
You have to distinguish
a. a subnet from the MT is feeding the opensense and the opensense considers this as a WAN input.
b. the opensense has its own subnets, not on the MT and one of these subnets is on a cable heading back to a different port on the MT
c. The MT considers this port as a second WAN. and then you can route users out to this WAN for t lets say a VPN connection.

This technique may not apply to you, it is what one OP used to provide a VPN connection through his DDR WRT router.
THe DDR WRT used the normal subnet coming from MT as WAN input to reach out to a third party VPN provider.
From here it created a VPN tranparent link through the MT internet connection.
Then by creating another subnet behind the DDRWR router it created a path for MT users to access said tunnel.
The MT considered that second port as a WAN port.

Not sure if it applies here…