HOW SIMPLE THINGS SHUT DOWN CONNECTIVITY

anav · Tue May 15, 2018 5:46 am

Here I was all fat and happy with my SOB induced filter set.
Some input rules, then a drop all for input
Some forward rules, then a drop all for forward.
Usual rules nothing funky including my rules to allow HOME LAN and DMZ LAN to the internet.

/ip filter
add action=fasttrack-connection chain=forward comment="defconf: fasttrack" \
    connection-state=established,related
add action=accept chain=forward comment="Allow FORWARD established & related" \
    connection-state=established,related
add action=drop chain=forward comment=\
    "Drop invalid/malformed packets" connection-state=invalid
add action=accept chain=forward comment="Allow HOMELAN to WAN" \****
    in-interface=HomeBridge out-interface-list=WAN
add action=accept chain=forward comment="Allow DMZLAN to WAN" \****
    in-interface=DMZ_Bridge out-interface-list=WAN
add action=accept chain=forward comment=\
    "Allow Port Forwarding -  DSTNAT" connection-nat-state=dstnat
add action=accept chain=forward comment=\
add action=drop chain=forward comment=\
    "DROP ALL other  FORWARD traffic"

All is hunky dory, and then I get an itch to change my two lan to wan allow rules.****
I decide that hey it would be cool to further define it by not only stating the in-interface homebridge, but also
state the source address list entry of: 192.168.0.0/24 (I also tried 192.168.0.2-.19.168.0.254)
No harm no foul, I am just being extra defining and its perfectly accurate and true.........

Guess what happened............ no more browsing and no more email, cut-off cold.
Can some explain what this innocent addition actually did??

Sob · Tue May 15, 2018 5:55 am

If you add src-address=192.168.0.0/24 to those two rules, then they will allow traffic from given in-interface and out-interface-list as before, but only when at the same time the source address is in 192.168.0.0/24. I don't remember what subnets you use, but since you have HOMELAN and DMZLAN, it's very likely that it's not just single 192.168.0.0/24.

anav · Tue May 15, 2018 2:22 pm

I should have more clearer!
The 192.168.0.0/24 in source address list was added to the HOMELAN bridge allow rule because the address range in this home lan is 192.168.0.1=192.168.0.254
The 192.168.2.0/24 in source address list was added to the dmzlan bridnge in its allow rule because the address range in this lan is 192.168.2.1-192.168.0.254

In any case, I was at my own computer in the 192.168.0.xx range for browsing and email and was stopped cold by adding in source address list.
It makes little sense to me.

Sob · Tue May 15, 2018 3:33 pm

Logging to the rescue! Take your working rule:

/ip firewall filter
add action=accept chain=forward comment="Allow HOMELAN to WAN" \
    in-interface=HomeBridge out-interface-list=WAN

And turn it into (duplicate the rule, add new condition to first one and enable logging for both):

/ip firewall filter
add action=accept chain=forward comment="Allow HOMELAN to WAN" \
    in-interface=HomeBridge out-interface-list=WAN src-address=192.168.0.0/24 \
    log=yes log-prefix="new rule"
add action=accept chain=forward comment="Allow HOMELAN to WAN" \
    in-interface=HomeBridge out-interface-list=WAN \
    log=yes log-prefix="old rule"

You should see new connections logged with "new rule" prefix. If you get "old rule" prefix instead, then look at source address and you should be able to see why it doesn't match the newly added condition.

anav · Tue May 15, 2018 6:58 pm

Thanks Sob, will do that later today and report back!

anav · Tue May 15, 2018 11:43 pm

Well I did both!
I activated both rules and put the OLD RULE first.......... I could see internet and email traffic with log prefix of OLD RULE.
I then put the new rule first. No difference. I could see internet and email traffic with log prefix of OLD RULE.

Conclusion: That the new rule is being ignored.

Next step. i decided to disable the Old rule. I did not see any log prefixes with NEW RULE, as if the rule was not active.

So for some reason, when I stick 192.168.0.0/24 in the source address as an additional part of the rule, the rule in effect disappears?????

I still had the the log rule copy of my drop rule and this time added a log prefix to it.
I can confirm that the rule with source address list in it, is totally ignored by the firewall.
Traffic is NOT matched and gets dropped. I dont see any other rule causing the drops..........

(by the way should not we drop invalid prior to accepting established, connected (which order is better)?

anav · Wed May 16, 2018 1:21 am

Solved: I was using 192.168.0.0/24 or 192.168.0.2-192.168.0.254 in the advanced tab under source address list.

When I removed this addition, it works as we know, it simply becomes the original rule (in-interface bridge, out-interface wan).
I then applied 192.168.0.0/24, or 192.168.0.2-192.168.0.254 under the general tab under source address.
This still works and all I see is the log prefix for this NEW rule as the old rule is then obviously not matched.

Conclusion do not use IN SOURCE ADDRESS LIST
a. a range 192.168.0.1-192.168.0.254
b. or subnet notation 192.168.0.0/24

Why I am not sure at the moment.
In any case I created an address list consisting of the two LANS, in the IP Firewall Address List TAB.
I placed this address list via its NAME in the rules advanced location for source address LIST and it works like a charm.

Thus the moral of the story if using SOURCE OR DESTINATION ADDRESS LIST, ensure it actually exists as a LIST item in the IP Firewall Address List.

Sob · Wed May 16, 2018 2:06 am

Well, if you had src-address-list=192.168.0.0/24, then it was looking for list named "192.168.0.0/24". And you thought RouterOS was broken, shame on you!

anav · Wed May 16, 2018 5:47 am

Haha, shame on all the 'so called' experts that didn't pick up on the issue before I did. ;-P, or perhaps you might claim you knew it all along and just wanted me to work it out on my own.

Seriously, really appreciated the help, especially using the log prefix, very cool.

(PS does it make any difference if invalid drop rule is after or before accept established, connected rule - i.e. any logic to apply here?)

RoadkillX · Wed May 16, 2018 1:21 pm

(PS does it make any difference if invalid drop rule is after or before accept established, connected rule - i.e. any logic to apply here?)

i'd say more along the lines of performance and not security, if you drop invalid before checking if it's connected or established you'll be saving cpu time in packet processing but i really think it'd be something barely noticeable. Rule order on something like packet marking really would matter i used to have my p2p connection and packet marking at the end of mangle and cpu was around 25-30% on a RB750Gr3 i changed p2p rules to be first and cpu went down to 7-10% since p2p rules where at the end all traffic was going through all rules youtube, netflix, tor, dns,https etc some of them use l7-matching so they were checking every p2p packet to see if it matched their condition, with the p2p rules at the start of mangle all marked-packets would leave the chain once maked and never go through any of the other rules and not l7-matching done on them. And for end a catch all rule to apply queue only mark-packet going up the down packet you can use no-mark and it would also save cpu time because you don't mark both. Hope you understand me.

anav · Wed May 16, 2018 6:09 pm

Not entirely but I would rather be in Spain too!

For example IF I have a much of DPI layer 7 rules it would be better to have my forward rules in this order......

1. fasttrack fast-forward default
2 drop invalid
3 allow established, connected
(order of 2 and 3 matters little I guess)

4. Allow DSN-NAT connections (since I have a last drop rule).
5. Allow any admin access across LANS
6. (allow ipsec in and out policies - if I had any)
7. DPI layer 7 rules -mostly to ensure nothing nasty going from LANs to WAN
8. ALLOW LAN TO WAN Traffic ( source address specific LAN, in-interface=appropriate_bridge, out-interface list=WAN (two ISPs)
9. DROP ALL

By the way, I have other rules in raw to drop anything I have in address lists from other sources or that I create (add to address list) and one additional rule due to
( PS what i cannot figure out is why my HW offloading which is checked off is showing as NOT on

)

RoadkillX · Wed May 16, 2018 6:36 pm

( PS what i cannot figure out is why my HW offloading which is checked off is showing as NOT on )

My RB750Gr3 went crazy once with the igmp snooping on the bridge in winbox it would be unticked and in the terminal it would show igmp-snooping=yes i disabled it in terminal and hw-offload started working.

Seems quite secure but i always ask how are your outbound rules, are you preventing internal hosts from openning a connection to publicip on port 80 or 443 with certain traffic? Reverse-shells, malware spreading, you probably won't get infected from the outside but if it happens inside from a usb are you preventing that from leaving the network? usually outbound is left wide open as in:

reject x.x.x.x
reject x.x.x.x
permit all

so you reject some sites (xxx, know malware, js bitcoin miners) but hosts are still allowed to open outbound connections if forward and src-nat not configured correctly. it should be.

permit related, established
permit dns
permit (allowed destination ports 80.443, etc)
drop all

just as we would configure the input chain.

Sob · Wed May 16, 2018 7:01 pm

Even though you did write about list, I don't think that anyone could expect what you actually did. I assumed you created the list and used its name, as usual. But you put right thing in wrong place. It would take different expert, the one with crystal ball.

About order of rules, generally most packets should be dealt with as soon as possible. I'd keep established/related before invalid, because vast majority of packets (under normal conditions) belong to established connections, so you have the match right away. If you put invalid first, then for most packets, you'll be checking two rules instead of one. I doubt that it would make big difference, because the actual check for connection state is likely very simple operation (all heavy work done by connection tracking is not repeated over and over), but why not try to make things effective as possible.

For rules in your last post, there will probably be much more LAN->WAN connections than e.g. admin accesses, so I'd move it higher. But again, it probably won't make much difference with just few rules. And I'm not sure what exactly you want to catch with L7 (#7), but lot of stuff will never get to this rule, e.g. tcp connections will become establieshed before you can see anything meaningful in them.

anav · Wed May 16, 2018 8:22 pm

roadkil in ref to hw offload, my iGMP snooping is off??

roadkil in ref to rules order, yes I allow all LAN to WAN, you are saying why not limit traffic ONLY to port 80 and 443?? probably a good idea, but only if Sob says so!

I do have sourcenat masquerade rule in place and my dst-nat rules are also defined by source IP (only known external users).

Sob,
concur on the order being more efficient with established, connected before invalid.
However for the other item, do you mean that a PC on the WAN, connecting to an external site ( bad guy on the WWW ), would get passed by the router under established, connected???
Wouldn't it be a new connection and thus keep going until it hit, my LAN to WAN allow rules? Unless I had a DPI rule in between that was aimed for such traffic/site??

Sob · Wed May 16, 2018 10:44 pm

Careful, I never said that I'd like to start a cult. Although they do have some appeal, if you're the man at the top and followers see you as god. It brings many possibilities. But I don't think I could ever get close to that. Don't be fooled by "guru" written under my name, it's just because I'm here for a long time and I posted a lot. With your posting rate, you'll be guru too, before you know it.

But back to routers, networks and stuff...

I'm not much for outgoing filtering. I'm not saying that it would be completely bad, it has something to it, but... I'd put it like this: If you want to be completely secure, pull the plug. If that's too much, only allow access to few selected addresses and ports. Then would be some other intermediate steps, and finally at the end is when you allow everything. It seems logical that the closer to beginning, the safer you are.

But think about what you want to protect against. When you infect your LAN from USB drive and you'd be worried about virus leaking some sensitive info from your computers, connect to some botnet control center and take orders, etc.., then outgoing filtering probably won't help much. Sure, there might be a botnet depending on use of port 666, but if the authors are not stupid, they will rather use standard https port 443 with valid certificate and everything. Even if you have just the most simple requirement to "be able to browse the web", you pretty much have to allow https unconditionally.

So in the end, outgoing filtering is not that much about you being safer, it's more about being a nice guy and not letting your infected machines doing port scans, sending spam, etc. On the other hand, not everything uses just few ports (http(s), ...), so the stricter filtering you use, the higher chance you have to break something for you. So you have to think about what's more important for you, and find a balance.

About established connections, when I add these logging rules at the beginning:

/ip firewall filter
add action=log chain=forward connection-state=new protocol=tcp dst-port=666 log-prefix="state_new:"
add action=log chain=forward connection-state=new protocol=tcp src-port=666 log-prefix="state_new:"
add action=log chain=forward connection-state=established protocol=tcp dst-port=666 log-prefix="state_est:"
add action=log chain=forward connection-state=established protocol=tcp src-port=666 log-prefix="state_est:"

then new tcp connection will log this:

21:30:44 firewall,info state_new: forward: in:internal out:public, src-mac 02:06:05:f5:21:f3, proto TCP (SYN), 192.168.80.1:35878->1.2.3.4:666, len 60 
21:30:44 firewall,info state_est: forward: in:public out:internal, src-mac 00:0c:42:32:5e:af, proto TCP (SYN,ACK), 1.2.3.4:666->192.168.80.1:35878, NAT 1.2.3.4:666->(5.6.7.8:35878->192.168.80.1:35878), len 60
21:30:44 firewall,info state_est: forward: in:internal out:public, src-mac 02:06:05:f5:21:f3, proto TCP (ACK), 192.168.80.1:35878->1.2.3.4:666, NAT (192.168.80.1:35878->5.6.7.8:35878)->1.2.3.4:666, len 52 
...

In other words, first SYN packet is new connection, but as soon as first SYN,ACK comes back, the connection is established. And when you're looking for something using L7 filters, it will only come later.

RoadkillX · Wed May 16, 2018 11:28 pm

roadkil in ref to hw offload, my iGMP snooping is off??

roadkil in ref to rules order, yes I allow all LAN to WAN, you are saying why not limit traffic ONLY to port 80 and 443?? probably a good idea, but only if Sob says so!

it sounds and is weird, on my RB750Gr3 in winbox it showed igmp snooping off on the bridge but in /interface bridge it would be enabled so hw-offload wasn't working, when disabling igmp-snooping by terminal hw-offload immediately switched on.

On the firewall topic unfortunately clients are almost always vulnerable to attackers (@Sob) that use allowed ports 80-443 unless you're running l7-matching for known reverse shells and malware but that is unlikely. I meant this more for servers in DMZ, if it doesn't need to connect to the outside don't let it if it provides a website there is no need for it to connect to a remote site on 80 or 443 it should only be able to answer related and established and other exceptions to your lan for dns queries and such. Situation were you might have an apache/ftp server if it gets hacked attacker would have to stop apache to be able to execute a bind shell on allowed incoming ports 80-443 because from the server new connections to the outside are not allowed, and you'll realize if your webserver goes down, so i do think it'll reduce the ways you can get attacked. To me on services accesible from the internet having outbound firewall rules is a must have.

RoadkillX · Wed May 16, 2018 11:31 pm

Well, if you had src-address-list=192.168.0.0/24, then it was looking for list named "192.168.0.0/24". And you thought RouterOS was broken, shame on you!

I guess in some way it is broken it shouldn't allow the name of a list that doesn't exist.

CZFan · Thu May 17, 2018 12:15 am

I will take a wild guess at your HW offload issue, bridges, many, many bridges.....

RoadkillX · Thu May 17, 2018 12:23 am

I will take a wild guess at your HW offload issue, bridges, many, many bridges.....

I always forget that, on RB only 1 bridge hw-offload on CRS only 7 something like that.

Sob · Thu May 17, 2018 12:32 am

@RoadkillX: If we're talking about servers and more towards enterprise stuff, then yes, if you know for sure that something doesn't need access to internet, then go ahead and block it. It will be safer and it won't break anything. But I'm under impression that anav is dealing with more home oriented setups. So if there's going to be a server, then most likely some all-purpose one and limiting its access to outside too much will cause problems.

I guess in some way it is broken it shouldn't allow the name of a list that doesn't exist.

Not really, you can have dynamic list that may not always contain something.

anav · Thu May 17, 2018 12:43 am

I have two bridges?
Are you saying if I remove one bridge suddenly HW off loading will magically appear.
Where is this magic information hiding LOL.
By the way, IGMP snooping is off on bridge and interface bridge.

{EDIT fixed: For some reason for the bridges I had STP setting of RTSP selected, turned it off and now have HW offload working!!)

Thanks SOB, I think I will be moving my L7 rules to before accept/established.

RoadkillX · Thu May 17, 2018 12:44 am

Not really, you can have dynamic list that may not always contain something.

Then it makes sense, didn't know that could be done, i've been using RouterOS for less than 2 months so still have to discover a lot of bells and whistles.

RoadkillX · Thu May 17, 2018 12:48 am

I have two bridges?
Are you saying if I remove one bridge suddenly HW off loading will magically appear.
Where is this magic information hiding LOL.

Can't remember were i read it but yes you can only have 1 bridge with hw-offload on RB devices and 7 on CRS devices, you can select which bridge to enable hw-offloading on, don't remeber how though i was looking for something else and read that as a pass by. what i gathered from that was if you need to split l2 domains use vlans not bridges

anav · Thu May 17, 2018 12:52 am

Got it working, I had RTSP selected in the RTP setting of the bridge for some strange reason.............

CZFan · Thu May 17, 2018 1:22 am

Got it working, I had RTSP selected in the RTP setting of the bridge for some strange reason.............

Only on your first bridge, 2nd bridge will not have HW offload

Sob · Thu May 17, 2018 1:39 am

Two questions come to mind:

1) Did the old master port config also have such limitation, e.g. if ether2 had master ether1 and ether4 had master ether3, was only one group using hw switching?

2) What about using the new bridge vlan filtering? Make ether1 and ether2 untagged vlan 10, then ether3 and ether4 untagged vlan 11, they should be isolated, it's only one bridge, so all four will have hw offload or not?

CZFan · Thu May 17, 2018 1:59 am

1. I am still new in Mikrotik world, so I am not sure how this was handled previously with single switch chip models. But if I take my RB2011, it has 2 switch chips, so before 6.41 I could create 2 switch groups.
1 Group for ports 1-5 + SFP which belonged to 1 switch chip, and another switch group for ports 6-10 which belongs to 2nd switch chip.
Then within each switch group, I will get wire speed, but between the switch groups I will get only 1Gb as it then goes via cpu. I would assume the same will happen now with the single bridge config, just managed by ROS, never tested it.

2. Vlan filtering with HW offload is only available on CRS3xx. If RB has a switch chip, you can still get HW offload with VLAN's if configured via switch chip. But this will then only be within same vlan, as soon as you cross VLAN's you have to do via routing and then this is done via cpu and not wire speed

Sob · Thu May 17, 2018 3:34 am

I use RouterOS for a long time, but switch features always somehow missed me. The most I did with them was setting master port for some home devices supposed to act as LAN switch and that was it. Plus one attempt to convince switch in RB493 to work with vlans in one hobby network, but I'm trying to forget about that (score was one for switch and zero for Sob).

I did few tests with new bridge and vlans and I like it, it seems nice, simple and intuitive. Something I couldn't say about old Switch menu. I did the testing with CHR and I'm a little disappointed since I learned that it won't be as straightforward with HW switches in older RB's.

anav · Thu May 17, 2018 11:21 pm

https://i.dslr.net/syms/2d82fca41ac6b46 ... dfe55a.jpg

For CZFans reading pleasure, was that a bottle of wine as your wager??

# may/17/2018 17:16:12 by RouterOS 6.42.1
# model = RouterBOARD 750G r3

/interface bridge
add ageing-time=5m arp=enabled arp-timeout=auto auto-mac=yes disabled=no \
    fast-forward=yes igmp-snooping=no mtu=auto name=DMZ_Bridge protocol-mode=\
    none vlan-filtering=no
add admin-mac= ageing-time=5m arp=enabled arp-timeout=auto \
    auto-mac=no disabled=no fast-forward=yes igmp-snooping=no mtu=auto name=\
    HomeBridge protocol-mode=none vlan-filtering=no
/interface bridge port
add auto-isolate=no bridge=HomeBridge broadcast-flood=yes comment=defconf \
    disabled=no edge=auto frame-types=admit-all horizon=none hw=yes \
    ingress-filtering=no interface=ether2 internal-path-cost=10 learn=auto \
    path-cost=10 point-to-point=auto priority=0x80 pvid=1 restricted-role=no \
    restricted-tcn=no unknown-multicast-flood=yes unknown-unicast-flood=yes
add auto-isolate=no bridge=HomeBridge broadcast-flood=yes comment=defconf \
    disabled=no edge=auto frame-types=admit-all horizon=none hw=yes \
    ingress-filtering=no interface=ether3 internal-path-cost=10 learn=auto \
    path-cost=10 point-to-point=auto priority=0x80 pvid=1 restricted-role=no \
    restricted-tcn=no unknown-multicast-flood=yes unknown-unicast-flood=yes
add auto-isolate=no bridge=DMZ_Bridge broadcast-flood=yes comment=defconf \
    disabled=no edge=auto frame-types=admit-all horizon=none hw=yes \
    ingress-filtering=no interface=ether4 internal-path-cost=10 learn=auto \
    path-cost=10 point-to-point=auto priority=0x80 pvid=1 restricted-role=no \
    restricted-tcn=no unknown-multicast-flood=yes unknown-unicast-flood=yes
/interface bridge settings
set allow-fast-path=yes use-ip-firewall=no use-ip-firewall-for-pppoe=no \
    use-ip-firewall-for-vlan=no

CZFan · Fri May 18, 2018 12:07 am

https://i.dslr.net/syms/2d82fca41ac6b46 ... dfe55a.jpg

For CZFans reading pleasure, was that a bottle of wine as your wager??

# may/17/2018 17:16:12 by RouterOS 6.42.1
# model = RouterBOARD 750G r3

/interface bridge
add ageing-time=5m arp=enabled arp-timeout=auto auto-mac=yes disabled=no \
    fast-forward=yes igmp-snooping=no mtu=auto name=DMZ_Bridge protocol-mode=\
    none vlan-filtering=no
add admin-mac= ageing-time=5m arp=enabled arp-timeout=auto \
    auto-mac=no disabled=no fast-forward=yes igmp-snooping=no mtu=auto name=\
    HomeBridge protocol-mode=none vlan-filtering=no
/interface bridge port
add auto-isolate=no bridge=HomeBridge broadcast-flood=yes comment=defconf \
    disabled=no edge=auto frame-types=admit-all horizon=none hw=yes \
    ingress-filtering=no interface=ether2 internal-path-cost=10 learn=auto \
    path-cost=10 point-to-point=auto priority=0x80 pvid=1 restricted-role=no \
    restricted-tcn=no unknown-multicast-flood=yes unknown-unicast-flood=yes
add auto-isolate=no bridge=HomeBridge broadcast-flood=yes comment=defconf \
    disabled=no edge=auto frame-types=admit-all horizon=none hw=yes \
    ingress-filtering=no interface=ether3 internal-path-cost=10 learn=auto \
    path-cost=10 point-to-point=auto priority=0x80 pvid=1 restricted-role=no \
    restricted-tcn=no unknown-multicast-flood=yes unknown-unicast-flood=yes
add auto-isolate=no bridge=DMZ_Bridge broadcast-flood=yes comment=defconf \
    disabled=no edge=auto frame-types=admit-all horizon=none hw=yes \
    ingress-filtering=no interface=ether4 internal-path-cost=10 learn=auto \
    path-cost=10 point-to-point=auto priority=0x80 pvid=1 restricted-role=no \
    restricted-tcn=no unknown-multicast-flood=yes unknown-unicast-flood=yes
/interface bridge settings
set allow-fast-path=yes use-ip-firewall=no use-ip-firewall-for-pppoe=no \
    use-ip-firewall-for-vlan=no

Sorry, not sure what you getting at?

mkx · Fri May 18, 2018 12:16 am

I guess @anav is trying to show setup with two bridges and both have hw offload enabled.

What seems suspicious to me is that one bridge has only one interface active and other bridge has all interfaces disabled. I guess if both bridges would have active devices then things might change. Meanwhile have another glass of wine

CZFan · Fri May 18, 2018 1:54 am

I don't see that, I see home bridge with hardware offload active on 2 ports, which is expected, but I also see dmz bridge not having HW offload active, which is also expected.

Anyway, here goes another sip, cheers

anav · Fri May 18, 2018 2:00 pm

Yes showing that router is telling me HW is a YES for both bridges. No I dont have anything plugged into DMZ bridge at the moment but what has that got to do with anything.

CZFan · Fri May 18, 2018 2:33 pm

Yes showing that router is telling me HW is a YES for both bridges. No I dont have anything plugged into DMZ bridge at the moment but what has that got to do with anything.

Still, I disagree.

What you showed, is that you enabled "ticked" hw offload, but you also showed ( in the screenshot that has now been removed) that HW offload is not active on DMZ bridge.

FYI, attached is a screenshot on a bridge where HW ofload is "active", it even shows it on a port that is inactive, i.e. nothing plugged in.

HWOffload.JPG

anav · Fri May 18, 2018 7:35 pm

Bugger, HW is showing NO now. So basically one can set HW as on, and it turns itself off on its own. Not sure how long it takes but it does.
Damn, well okay the next wine I buy will be SAfrican.

mkx · Fri May 18, 2018 7:52 pm

Damn, well okay the next wine I buy will be SAfrican.

You should try to stay away from Canadian wine, looks like it contains some really weird substances

anav · Sat May 19, 2018 1:39 am

Actually you mean Californian, gonna stay away from dat sheet.

mkx · Sat May 19, 2018 6:33 pm

Wait a minute ... you're saying Canada and California are not the same? I always thought weird that you Californians would be good at ice hockey so I reverted to calling you Canadians

I tend to drink wine produced in my own timezone. Which makes SAfrican wine a plausible choice for me

anav · Sat May 19, 2018 8:40 pm

So If I dont use bridges at all, I can still achieve hw offloading on all future VLANS. I is confused..........
Cause eventually I want to have at least 2 or 3 (guest wifi, devices vlan, etc)

RoadkillX · Sat May 19, 2018 9:03 pm

from what i understand, If you have on switch-chip then add all interfaces to a bridge then do vlans in /interface ethernet switch you'll get hw-offload on all interfaces in the bridge, if you have 2 switch-chips then each bridge will have the ether interfaces for it according to docs, but you'll treat each bridge as a different switch each with its own vlans. if you were to set 1 port from each bridge on the same vlan, that traffic would go through the cpu, just like any other traffic between bridges would use the cpu.

from that understanding i've got a RB750Gr3, CRS112, hAP AC all with vlans and all with hw-offload so i guess am not doing it totally wrong.

anav · Sat May 19, 2018 9:28 pm

Awesome, who needs the ghostbusters, call RoadkillX

RoadkillX · Sat May 19, 2018 9:44 pm

Awesome, who needs the ghostbusters, call RoadkillX

break some, fix some, learn in the process.

CZFan · Sat May 19, 2018 9:55 pm

When the bridge ports indicate HW is active, does not necessarily mean you will get hardware offload on all traffic, it just means that it is enabled and active, and managed by the bridge software and hardware offload will occur when certain conditions are met.

As an example:
If you have a switch chip, created bridge with ports 2 - 5 in this bridge, HW enabled. Then create 2 vlans with ports 2&3 on VLAN100 and ports 4&5 on VLAN200, then theoretically, you will get HW offload functionality between ports 2&3 and also between ports 4&5, but should you have traffic between the 2 vlans, i.e. from port 2 to 4, this will need to be routed, which will then go via CPU and you will not get wire speed / HW offload functionality

Also keep in mind, according to the wiki, there are devices that has "switching only" chips, which does not have the extra switch functionality and assume will not have the HW Offload functionality or might not be VLAN aware, I am not sure which models these are, so best you research your model

EDIT: I am no VLAN expert, but this is my understanding from what I have learned so far and the likes of @sindy, @sob, @sebastia, @zerobyte, @pe1chl, etc is welcome to correct me or add if I left out

RoadkillX · Sat May 19, 2018 10:19 pm

As an example:
If you have a switch chip, created bridge with ports 2 - 5 in this bridge, HW enabled. Then create 2 vlans with ports 2&3 on VLAN100 and ports 4&5 on VLAN200, then theoretically, you will get HW offload functionality between ports 2&3 and also between ports 4&5, but should you have traffic between the 2 vlans, i.e. from port 2 to 4, this will need to be routed, which will then go via CPU and you will not get wire speed / HW offload functionality

Can't correct it if it's dead on. if it's going through a L3 vlan interface forget hw-offload.

Who is online