Community discussions

 
ilovepancakes
just joined
Topic Author
Posts: 11
Joined: Thu Oct 04, 2018 4:37 am

Simplifying my forward chain?

Fri Aug 23, 2019 4:08 pm

New to RouterOS and below is my forward chain. I am wondering if there is anyway to accomplish the below but simplify the rules into a lower amount. Mostly I am referring to the drop rules in the forward chain. Kind of like how the input chain just has a drop all at the end, is there a better practice of keeping these rules functions but simplifying what I have?

Really like how well RouterOS works so far!
0  D ;;; special dummy rule to show fasttrack counters
      chain=forward action=passthrough 

 3    ;;; Accept established and related packets
      chain=forward action=fasttrack-connection connection-state=established,related log=no log-prefix="" 

 4    ;;; Drop invalid packets
      chain=forward action=drop connection-state=invalid log=no log-prefix="invalid" 

 5    ;;; Drop all packets from local networks to internet which should not exist in public network
      chain=forward action=drop dst-address-list=NotPublic out-interface=ether1 in-interface-list=All LANs log=no log-prefix="NoPublic" 

 6    ;;; Drop all packets in local network which does not have local network address
      chain=forward action=drop src-address=!192.168.0.0/24 in-interface=combo1 log=no log-prefix="NoLocalAddress" 

 7    ;;; Rules for vlan80-guest to LAN
      chain=forward action=jump jump-target=vlan80>LAN in-interface=vlan80-guest out-interface=combo1 log=no log-prefix="" 

 8    ;;; Rules for vlan70-voice to LAN
      chain=forward action=jump jump-target=vlan70>LAN in-interface=vlan70-voice out-interface=combo1 log=no log-prefix="" 

 9    ;;; Drop All VLANs to LAN
      chain=forward action=drop out-interface=combo1 in-interface-list=All_VLANs log=no log-prefix="DropAll_VLANs>LAN" 

10    ;;; Drop all packets from public internet which should not exist in public network
      chain=forward action=drop src-address-list=NotPublic in-interface=ether1 log=no log-prefix="NoPublic" 

11    ;;; Drop new connections from internet which are not dst-natted
      chain=forward action=drop connection-state=new connection-nat-state=!dstnat in-interface=ether1 log=no log-prefix="NotDSTNAT”
 
mkx
Forum Guru
Forum Guru
Posts: 3183
Joined: Thu Mar 03, 2016 10:23 pm

Re: Simplifying my forward chain?

Fri Aug 23, 2019 4:13 pm

Safer (and sometimes easier) way is to construct a list of explicitly allowed connections and drop the rest at the end. Your current one is the opposite: drop watever you thought it should be dropped and (implicitly) allow the rest.

Any way you do it, there's an essential rule missing in your current setup (as they are it essence is in performance): similar as fast-track rule #3, but action=accept.

Well, probably it is there but you chose to play whack-a-mole with us by not showing us the whole story so we can guess what's missing ;-)
BR,
Metod
 
ilovepancakes
just joined
Topic Author
Posts: 11
Joined: Thu Oct 04, 2018 4:37 am

Re: Simplifying my forward chain?

Fri Aug 23, 2019 4:25 pm

Safer (and sometimes easier) way is to construct a list of explicitly allowed connections and drop the rest at the end. Your current one is the opposite: drop watever you thought it should be dropped and (implicitly) allow the rest.

Any way you do it, there's an essential rule missing in your current setup (as they are it essence is in performance): similar as fast-track rule #3, but action=accept.

Well, probably it is there but you chose to play whack-a-mole with us by not showing us the whole story so we can guess what's missing ;-)

The "missing rules" 1 & 2 are just passthrough rules I made to try and track a separate issue. I removed them from the post for simplicity so what you see is exactly what I have with real rules. I agree with your general strategy and this is what I have with input chain. So I guess what I am asking and what I am confused about is, I followed the wiki for general forward rules and these are the rules it suggested. It doesn't mention which accept rules would be needed to allow basic standard traffic like internet and LAN devices to talk to each other. So, if I make a forward chain drop all rule at the end, could you provide an example of the accept rules I need above it to allow just internet and LAN devices to talk I guess? That would provider a standard starting LAN setup right? Am I missing something else?
 
Sob
Forum Guru
Forum Guru
Posts: 4798
Joined: Mon Apr 20, 2009 9:11 pm

Re: Simplifying my forward chain?

Fri Aug 23, 2019 5:16 pm

- fasttrack established,related
- accept established,related,untracked
- drop invalid
- accept from LAN interface and 192.168.0.0/24 to WAN interface and not to NotPublic
- jump to vlan80>LAN (where you allow what should pass)
- jump to vlan70>LAN (same as previous)
- accept dstnatted if not from NotPublic (you can also move the not from NotPublic condition to dstnat rules)
- drop/reject the rest (reject is better for you when you forget to allow something, because instead of silently lost packets, client will get icmp with info from router)
People who quote full posts should be spanked with ethernet cable. Some exceptions for multi-topic threads may apply.
 
ilovepancakes
just joined
Topic Author
Posts: 11
Joined: Thu Oct 04, 2018 4:37 am

Re: Simplifying my forward chain?  [SOLVED]

Fri Aug 23, 2019 5:32 pm

- fasttrack established,related
- accept established,related,untracked
- drop invalid
- accept from LAN interface and 192.168.0.0/24 to WAN interface and not to NotPublic
- jump to vlan80>LAN (where you allow what should pass)
- jump to vlan70>LAN (same as previous)
- accept dstnatted if not from NotPublic (you can also move the not from NotPublic condition to dstnat rules)
- drop/reject the rest (reject is better for you when you forget to allow something, because instead of silently lost packets, client will get icmp with info from router)

OK, this is making sense now, I think I wasn't thinking of the accept from LAN one correctly and that was confusing me because I knew if I just added that it still would allow Not Public address, etc... but I see how you combined the not at the end there with it. A couple questions if you don't mind?

1.) What is the point of accept established, related, untracked if there is fastrack established and related before that?

2.) The accept from LAN interface rule... what is that actually doing? Just allowing new connections that start from LAN and go to WAN as long as destination address is NOT a NotPublic address?

3.) Also on the above rule, should this above rule also be added to each VLAN jump list? Assuming I want the VLAN to have internet? Or should I change the rule as you wrote it to /16 so it covers all the VLAN subnets? (192.168.x.y is my network where x is the same as VLAN ID for simplicity)

4.) Is the point of accept dstnatted rule to allow "port forwards" in my NAT tab to work (as long as the source address is NOT a NotPublic address)?
 
Sob
Forum Guru
Forum Guru
Posts: 4798
Joined: Mon Apr 20, 2009 9:11 pm

Re: Simplifying my forward chain?

Fri Aug 23, 2019 6:39 pm

1) Fasttrack doesn't work for everything. I don't use it, so I'm not very good with it, but I read somewhere that even fasttracked connections need to let some packets take the normal path.

2) Yes. And if source address is 192.168.0.0/24, so no spoofing from LAN will be possible. There's no reference to connection state, because previous rules already dealt with established, related, untracked and invalid, so the only one left is new.

3) If you want to keep the anti-spoofing part, you'll need individual rules. Also checking only for source address can be dangerous, because packet from spoofed address can come from anywhere, WAN included. It probably won't and if it does, it won't be able to establish proper connection, but for example a single unwanted udp packet could sneak in this way.

4) Yes.
People who quote full posts should be spanked with ethernet cable. Some exceptions for multi-topic threads may apply.
 
ilovepancakes
just joined
Topic Author
Posts: 11
Joined: Thu Oct 04, 2018 4:37 am

Re: Simplifying my forward chain?

Fri Aug 23, 2019 10:48 pm

1) Fasttrack doesn't work for everything. I don't use it, so I'm not very good with it, but I read somewhere that even fasttracked connections need to let some packets take the normal path.

2) Yes. And if source address is 192.168.0.0/24, so no spoofing from LAN will be possible. There's no reference to connection state, because previous rules already dealt with established, related, untracked and invalid, so the only one left is new.

3) If you want to keep the anti-spoofing part, you'll need individual rules. Also checking only for source address can be dangerous, because packet from spoofed address can come from anywhere, WAN included. It probably won't and if it does, it won't be able to establish proper connection, but for example a single unwanted udp packet could sneak in this way.

4) Yes.

Awesome, that makes a lot more sense. Thank you!

Who is online

Users browsing this forum: MSN [Bot] and 47 guests