I see issue with NAT rules on bridge with VLAN filtering enabled (ROS v6.43..
Bridge has bunch on ports (tagged , untagged) and what i’m trying to do is to write bridge NAT rule for one port which is connected as untagged to the bridge and has set PVID.
Rule i’m trying to write is “dstnat”, “In.Interface” is the port i’m talking about and i’m trying to classify either only IP packets (eth.type 0x800) or optionally ARP packets (eth.type 0x806).
However, what i’m seeing is that at this point in dstnat, i don’t see other eth. packets types except vlan ones (0x8100). Well ok, let’s assume vlan encapsulation (by port pvid) is happening before bridge dstnat rules processing, no issue with that - because in rule classification i can set up match for 0x8100 frames and then i can further classify based on “VLAN/VLAN Encap” protocol. And this classification based on “VLAN Encap” seems to be not working properly.
What i found with this rule is:
MAC Protocol-Num is matching for 0x8100 (vlan) frames
VLAN Encap is not matching 0x800 (ip), neither 0x806 (arp), nor ! 0x800 (ip) - which doesn’t make sense completely.
Completely strange behavior is happening (in winbox) when i set VLAN Encap to 0x800 (ip). Counter for this rule (and also other nat rules, if any present) gets some strange random number, like Bytes: 5255520.0 GiB Packets: 100895145455555555 (immediately after setting up that rule, so i guess something is overflowing somewhere …)
Not sure if i’m doing something wrong and missing something, or this is a bug.
This is definitely a bug.
My scenario:
I have bridge vlan filtering enabled and 2 vlans, one for management and second for pppoe traffic.
I’m trying to use bridge filter and once I set vlan Encap, wierd things start to happen.
vlan encap=pppoe discovery does not work.
vlan encap=pppoe session does not work.
vlan id works.
I also saw this wierd HUGE number in BYTES increase when setting vlan encap to IP.
Mikrotik please fix this.
Yes, its still a bug. I did report it, gave them examples how to repeat the issue, offered them access to envirnoment where it’s set up to see the issue in real time, but they either have difficulty to read and understand or i’m simply living in the different world.
However, I found workaround. At least how to filter/NAT IPv4(0x800) packets in the bridge with VLANs enabled.
The trick is, to not use VLAN Encap = 0x0800 (ipv4), but just “8” and voilà, it’s working. Now you can see how they have the byte identification shifted in those rules. Don’t even let me to tell you how long it took me to find whats going on there …
So for vlan enabled bridge filtering/nat-ing for ipv4, use :
MAC proto-num (hex): 8100 (vlan)
VLAN Encap (hex) = 8
Unfortunately for your 0x8863 (pppoe-discovery) and 0x8864 (pppoe-session) it will not work, the bytes are shifted in the wrong way, for ipv4 (0x0800) its fine, there are zeroes.
Man you have a bad luck with the protocol you trying to match.
Maybe if you write to IEEE Registration Authority, they will change pppoe-xxx EtherType to something which has zeroes at the 2nd byte of Ether type header so it will be “Mikrotik filtering friendly”.
At this moment i don’t even want them to fix it, i have several rules relaying on this workaround already (working like charm for like a year).
Chapeau, it didn’t come to my mind that the issue could be this simple. However, as you have shown the direction, I have a bit of good news - the bytes are not shifted, the bytes are swapped (as in “big Endian/little Endian problem”): if I set vlan-encap=0x0608, the rule matches on frames carrying ARP packets. To double-check that it is not just a coincidence, I’ve tried the same with pppoe-discovery:
/interface bridge filter
add action=log chain=output log-prefix=pppoe-rule mac-protocol=vlan out-interface=pppoe-vlan vlan-encap=0x6388 vlan-id=234
and it does work:
The drawback is that the matching on fields of the inner protocol (such as ip-protocol, src-port and dst-port for vlan-encap=ip, or arp-opcode for vlan-encap=arp) doesn’t work when the vlan-encap is set this way. So you cannot use the full potential of bridge filtering with vlan-tagged frames.
I wondered whether the issue doesn’t exist only on some architectures, so I’ve tested also on a CHR (so Intel which uses little Endian) - but no, the issue exists there as well.
Man you nailed it, you are guru. Nothing is more simple then to test it, so i set up simple forward passthrough filter rule to match 0x0806 (arp) as vlan encap. = 0x0608 and yes its working, so you are correct, bytes are swapped not shifted. I have RB3011 where i tested it right now.
Little bit misleading is, if they are just swapped then why those counters are overflowing or whatever they are doing if you put there eg. 0x0800 (ip4). That’s what stopped me trying to put there double byte values, because i saw that i’m also writing something somewhere where i should not.
You wrote:
The drawback is that the matching on fields of the inner protocol (such as ip-protocol, src-port and dst-port for vlan-encap=ip, or arp-opcode for vlan-encap=arp) doesn’t work when the vlan-encap is set this way. So you cannot use the full potential of bridge filtering with vlan-tagged frames.
Ok but that’s by the design. It’s not caused by this bug. I don’t see there any possibility to eg. filter vlan encapsulated ip ethertype based on ip-protocol type and src/dst port, etc… I see that kind of filtering only if you choose mac-protocol-num directly as ‘ip’ (0x0800), which means no vlan encapsulation.
I have neither hardware to test nor test case … so, could it have something to do with big-endina VS. little-endian architecture? We all know that ethernet is big-endian, but some of our routers are little-endian… So perhaps someone developing this part of UI forgot about that?
That’s why I’ve tried on both hAP ac² and a CHR and got the same result. 3011 is ARM like hAP ac², so no difference. However, as you’ve come back to that, I’ve tried on Powerbox (hEX lite PoE, RB70Pr2) which is a mipsbe CPU, and the issue is non-existent there, in 6.42.8 nor in 6.46.6. So although I didn’t think so initially, it’s most likely really is an endianness handling issue.
A filter rule on br-C-vlan which logs and matches on mac-protocol=vlan vlan-id=X vlan-encap=pppoe-discovery logs if the mapping is correct, and with vlan-encap=0x6388 it logs when the mapping is wrong.
.