Jump seems not to capture all packets it should

Hello folks, since reading wiki and searching a bit about it I couldn’t solve that “problem”, I’ll ask the community in hope someone shed some light on it.

I have a mangle with about a hundred rules. I have a PPPoE client running, for internet access along with other 2 links with fixed IP. Each WAN in an different port. ether6 and ether8 has fixed IP and pppoe connection runs on ether4.

In the very beggining of the mangle, I have 3 rules, on prerouting chain with in-interface set to those WAN ports, that jumps to a custom chain, like this:

chain=prerouting action=jump jump-target=z-balance-inwan in-interface=ether6 connection-mark=no-mark
chain=prerouting action=jump jump-target=z-balance-inwan in-interface=ether8 connection-mark=no-mark
chain=prerouting action=jump jump-target=z-balance-inwan in-interface=pppoe-wan connection-mark=no-mark

After this rules I have some other that works with local traffic, all on prerouting chain, and a rule like this:

chain=prerouting action=mark-connection new-connection-mark=Conn-Impossible passthrough=yes connection-mark=no-mark

And after that some rules that works in the custom chain “z-ballance-inwan”. And among rules in that custom chain, in the bottom of it I have a rule that mark all connections that have not yet been mark so it will be droped on filter, like this:

chain=z-balance-inwan action=mark-connection new-connection-mark=Conn-Block passthrough=yes connection-mark=no-mark

The funny thing is, that rule that marks connection as “Conn-Impossible” are receiving packets comming from PPPoE client interface. It should be impossible I think, becase traffic comming from Internet, should be captured by the rule that send the packed to the custom chain, if it have no mark. And it will have no mark ONLY if it is a new connection, because after it pass through the “z-ballance-inwan” chain, it will absolutely have a mark,

Is there anything I am missing?

Another thing that is bothering me is that rule is also capturing lots of packets from the internal network. All the packets from internal network are also sent to a custom chain and they will get a connection mark, so they don’t need to get through all the rules again in the future. The local network are connected to the routerboard by pppoe, and this rule is capturing TCP ACK packets, FROM CLIENT INTERFACE with source addresses from INTERNET, and destination address to an address from that client internal network. By my understading, ACK packets should be sent FROM the client to the server. Also, strange enough is that those packets are getting here without a mark, because if the client request a connection, it will be sent to a custom chain that WILL mark that connection.

I know it is kind a long post, if anyone have an idea, it would be appreciated.
.

Hm! How you route traffic across WAN’s ? Also use jump rule on WAN pppoe client, and have a very poor performance on upload speed. I check tomorrow is that all packets catch.


Have a good day!

I have 3 routing tables, named “Route-Link1”, “Route-Link2” and “Route-Link3”. So,the very first packet of any connection request will be send to a custom chain to decide to what WAN that connection should be routed, so, after that, that connection will have a mark, and the second packet won’t go through that rules again because the “jump” rule have a criteria of “connection-mark=no-mark”. That’s why I think it is crazy that a rule AFTER that jump, is capturing packets from clients with ACK flag. Stranger even is the fact that those packets report their source address as an internet address (like “55.17.28.19” when the actual address of that client is acctualy like “172.16.253.25”), and the destination as an address that belongs to the internal network of the client, and by the internal network of the client I mean the interface that connects his devices inside his home, his smartphone, hist tablet, notebook, computer and so on. That network is not known by my gateway (CCR1009), his internal traffic should go through his router NAT before being sent to CCR1009.