VLAN1 pppoe server, so only via VLAN2 shall be possible to get internet

vlan2 192.168.1.1/24
vlan1 pppoe 192.168.88.0/24

cannot get the principle in tik, i need to set default route of 192.168.88.0/24 to 1.1

if I simply set untagged port to 1.1 i get connection without any problems...

192.168.1.0/24 is zone for local servers, just for information. vlan5 gets internet connection.

I really don't follow your question here:

cannot get the principle in tik, i need to set default route of 192.168.88.0/24 to 1.1

if I simply set untagged port to 1.1 i get connection without any problems...

What do you mean by "set untagged port to 1.1"?

For what it's worth, the problem sounds to me like this - you're trying to connect a switch with VLANs in it onto a single port of the Mikrotik, and on the switch, you want to use VLAN1 on interfaces with pppoe clients, and vlan2 on interfaces with servers.

Most switches with a trunk interface will have a "native vlan" of 1, which means that vlan 1 is not tagged, but all other vlans use a tag.

I'm going to assume that the switch connection is on ether1 -

To work with this, you can build your pppoe server configurations directly on ether1 as if there were no vlans.
Then create a vlan type interface "vlan2" as a sub-interface of ether1. This way, vlan2 will work with tags, and 'vlan1' will just be the actual ether1 interface (no need to create a vlan1 sub-interface).

As for the default route of the pppoe clients - the vlan tag should not matter. If they are able to establish the session with the Mikrotik, then any default gateway / routing issues have nothing to do with VLAN tags.

actually i am playing right now on the table...

so yes, idea to pack 1gbps adapter with all stuff and combine two x86 machines into it.

right now:

ethernet fiber-ether1:
vlan2 -> to ISP
vlan3 -> LAN(server area)
vlan5 -> pppoe_gateway

in nat i have rule for both masquarade 192.168.1.0/24(serv) and 192.168.88.0/24(pppoe)
ofcourse both are working.
BUT i need to route all traffic from vlan5 to vlan3 firstly(or) optionaly vlan4 which will be kind of external interface from pppoe to LAN.

ether1 - trunk - switch

if i set on switch for example some port to vlan3 -> works like it should
if i set on switch pppoe_gw -> pppoe works like it should ( but traffic runs directly, due to masqarade... another way did not found yet) would be appreciate for help..

why? queue tree on LAN+ISP will be maintained..
so probably last suggestion will not work

actually i am playing right now on the table...

so yes, idea to pack 1gbps adapter with all stuff and combine two x86 machines into it.

right now:

ethernet fiber-ether1:
vlan2 -> to ISP
vlan3 -> LAN(server area)
vlan5 -> pppoe_gateway

in nat i have rule for both masquarade 192.168.1.0/24(serv) and 192.168.88.0/24(pppoe)
ofcourse both are working.
BUT i need to route all traffic from vlan5 to vlan3 firstly(or) optionaly vlan4 which will be kind of external interface from pppoe to LAN.

ether1 - trunk - switch

if i set on switch for example some port to vlan3 -> works like it should
if i set on switch pppoe_gw -> pppoe works like it should ( but traffic runs directly, due to masqarade... another way did not found yet) would be appreciate for help..

why? queue tree on LAN+ISP will be maintained..
so probably last suggestion will not work

OK - I think force to vlan3 first is not really needed. I suppose the IP address of vlan2 is something public, static, and larger than /30 - e.g. 190.0.2.32/29 where .33 is the default GW, .34 is your Mikrotik, and 35 - 38 are free for you to assign to servers. This is pretty easy to do.

in NAT table, have only this rule:
/ip firewall nat add chain=srcnat out-interface=vlan2 action=masquerade

That is 100% enough to make pppoe customers and LAN reach each other without NAT translation, but for all interfaces going out Internet to be NAT translated to the Mikrotik's IP address.

Now, if you want to add a rule to translate 190.0.2.34 -> 192.168.1.10 so this server has a dedicated public IP.
Add to the srcnat chain BEFORE the one "masquerade" rule:
chain=srcnat src-address=192.168.1.10 action=src-nat to-addresses=190.0.2.34
and add this to dstnat:
chain=dstnat dst-address=190.0.2.34 action=dst-nat to-addresses=192.168.1.10

Done.
Note that the two nat rules for the server do NOT mention the port this time. This is because you want the same public IP to work both inside and outside the mikrotik's network, so you only use IP addresses for NAT in this case.

If you want to limit services that hosts may reach the server on:
add to the filter table, forward chain:
acion=accept protocol=tcp dst-address=192.168.1.10 ports=22,25,110,80,443 (for a web/mail server with ssh)
action=accept protocol=udp dst-address=192.168.1.10 ports=53
action=drop dst-address=192.168.1.10

This way, all other ports on the server are protected, but connections to the services you want to make available are OK. Notice that I used the private IP because the forward filter comes after the dst-nat action has mapped its public IP address into its private one.

i have only one external IP )
so vlan3 shall be.. Thank You for hints I will try them soon on the table

i am still having idea to translate all traffic from pppoe customers to IP address that will be in vlan3 like 1.100.

it will be double routing, BUT - it's same - or double mangle rules or double nating rules. because i need to set up queue tree +mangle for traffic. so i need IN interface and OUT. vlan3 one of it, because there will be more 5 machines...

it will be double routing, BUT - it's same - or double mangle rules or double nating rules. because i need to set up queue tree +mangle for traffic. so i need IN interface and OUT. vlan3 one of it, because there will be more 5 machines...

I think you might be better off using simple queues for this, since the same queue can do TX and RX limits, and all from one parent point without having to virtually bend traffic through some arbitrary interface.
Also, simple queue processing has been made more efficient several times in the lifetime of v6.... (according to the release notes, anyway) specifically to handle a large number of queues. (hundreds and hundreds)