Buying - RB1100AHx4 Dude Edition - Questions about Firewall

RouterOS Beginner Basics
21

Mana kļūda, ko es pieņēmu horvātu valodā, ir tā, ka LOL ir slikta lieta

22

Are we having language lessons for the rats? :lol:

23

I think we’re rather having fun with our favourite on-line translating tools.

24

I did just compare old 6.x default IPv4 rules with those from 7.18 and there are no much difference.

6.x

add chain=forward action=fasttrack-connection connection-state=established,related comment="defconf: fasttrack"

7.18 (added hw-offload)

add chain=forward action=fasttrack-connection connection-state=established,related > hw-offload=yes > comment="defconf: fasttrack"

6.x

add chain=forward action=drop > connection-state=new > connection-nat-state=!dstnat > in-interface-list=WAN > comment="defconf: drop all from WAN not DSTNATed"

7.18 (swapped around some of the commands. Should not make any changes)

add chain=forward action=drop > in-interface-list=WAN > connection-nat-state=!dstnat connection-state=new comment="defconf: drop all from WAN not DSTNATed"

So its not changed much

25

@Jotne yes,

I reorder parameters and align pure default items for better readability, but the line is the same, for keep exactly the defaults.

26

For the release of 7.21, hw-offload=yes should be removed from the fasttrack rule, due to these changes:

  • firewall - hide hw-offload setting from devices that do not support it;
  • firewall - make hw-offload=yes default setting in /ip/firewall/filter menu;

If we copy the content of your post and paste into a CHR installation or all the non-CRS/CCR devices with blank firewall running 7.21beta, that fasttrack line fails to import due to the presence of hw-offload=yes which those devices no longer support.

And for the CCR/CRS devices that setting will be default anyway.

27

I fix the post, thanks!

28

Note that as far as I understand the ipv6 address space for 6bone has been returned to the address pool in 2006

29

Yes, but are the default rules, and until inside RouterOS is not changed something, must be on this way.

And until 3ffe::/16 is not assigned, still a bogon/bad is not a problem...

30

True, and backed by RFC-3701 which states in part:

   Thus after the 6bone phaseout date June 6, 2006, it is the intent
   that no 6bone 3FFE prefixes, of any size/length, be used on the
   Internet in any form.  Network operators may filter 3FFE prefixes on
   their borders to ensure these prefixes are not misused.
31

Ah perfect. Thanks for the clarification.

32

Interesting ! for my house I have a 10G fibre connection to a SFP+ and a CRS309-1G-8S+ in RouterOS to be the router. Does that CRS has the capacity to handle that connection speed ?

Thx for your help

33

CRS309 can do routing and firewalling "in hardware" if configured properly. And if it is doing it in hardware, then it does it wirespeed ... so yes, 10Gbps in ideal conditions.

However, if the configuration doesn't allow for HW offload, then CR309 with its relatively slow CPU will mightily struggle ... official test results (look at ethernet test results) indicate routing/firewalling speed at around 500Mbps (give or take).

Read more about L3 HW offload.

34

thx for the info!
I have the created the default firewall rules listed above and activated the HW offload and I’ve seen some great improuvent in speed.

35

In 7.22beta this rule has been updated with more conditions:

/ip firewall filter
add chain=input action=accept src-address=127.0.0.1 dst-address=127.0.0.1 \
    in-interface=lo comment="defconf: accept to local loopback (for CAPsMAN)"

No idea why the extra checks are need.

36

Also removed connection-state=new on forward drop:

Changes:

7.21: filter add chain=input action=accept                       dst-address=127.0.0.1                 comment="defconf: accept to local loopback (for CAPsMAN)"
7.22: filter add chain=input action=accept src-address=127.0.0.1 dst-address=127.0.0.1 in-interface=lo comment="defconf: accept to local loopback (for CAPsMAN)"

7.21: filter add chain=forward action=drop connection-state=new connection-nat-state=!dstnat in-interface-list=WAN comment="defconf: drop all from WAN not DSTNATed"
7.22: filter add chain=forward action=drop                      connection-nat-state=!dstnat in-interface-list=WAN comment="defconf: drop all from WAN not DSTNATed"
37

I think to avoid spoofing and errors, it is explicitly named "lo",
while in the other what remains from the other rules is necessarily "new" and therefore unnecessary to specify.

38

Rules updated with the new paradigm, as they cannot alter or damage anything existing.

39

Thanks, you give me the idea of this topic

40

Refreshed for 7.20.8 ; 7.21.2 -> 7.21.3 ; 7.22rc1 -> 7.22rc2

No changes.