VLAN traffic / Firewall

RouterOS Beginner Basics
1

Guys, could you kindly advise what I’m doing wrong?
There is a very simple configuration, as shown in the attached pic (LAN_01.jpg).

The firewall rule is like that:
1 chain=forward action=accept src-address=192.168.30.29 dst-address=192.168.10.11 log=yes log-prefix=“30->10”

As you can see, the rule is at the top of the list.
Before it, there is just a “special dummy rule to show fasttrack counters”.

Unfortunately, when I try to ping 192.168.10.11 from 192.168.30.29 it doesn’t work :frowning:
I can see some traffic going through the firewall rule (screen_01.jpg), but the ping says “Request timed out”.

Any ideas?

btw. when connecting the PC to the VLAN10 there is obviously no problem with pinging 192.168.10.11
screen_01.jpg
LAN_01.jpg

2
  1. What is the purpose of VLAN-s in your configuration
  2. Post complete config…

O.K.?

3

As mentioned, the current config is necessary, especially the firewall rules (as interVLAN traffic is allowed by default).

You can use /export on the Terminal (i.e. /ip firewall export or /export).

4

/export file=anynameyouwish ( minus router serial # and any public WANIP information )

Additionally using notepad++ to open the exported file is easy and you can then cut and paste into the thread.
Ensure you use code tags if your config is long ( next to Bold etc… the square box with with square brackets.

5

Check firewall settings on 192.168.10.11. Some OSes (e.g. Windows) have default FW settings which block any kind of ingress connectivity originating outside own subnet. Which in your case is 192.168.10.0/24 … and obviously 192.168.30.29 is not part of it.

6

Thanks for all your answers.
I believe the problem is already solved, however it would be great if you could confirm that it’s the way how it should work.
To enable the traffic, I also had to add the other-way rule so from 192.168.10.11 to 192.168.30.29
After adding that rule, everything seems to be working fine.

7

ROS features stateful firewall which builds on connection tracking machine. Default firewall filter ruleset has a rule like “action=accept connection-state=established,related” … which makes sure also return packets are allowed. And in this case one certainly doesn’t need anotger rule accepting return traffic (which would be very difficult to construct if it’s a more general rule, like connecting to TCP port 80 worldwide).

So when you asked about what might be wrong, it was our fault not to immediately ask you to post full firewall rules … we somehow ecpected your firewall was at least remotely resembling default firewall, but it doesn’t or so it seems. Only you know the reason.

What you described in your last post … is not supposed to be this way.

8

So this is how it looks:

0 D ;;; special dummy rule to show fasttrack counters
chain=forward action=passthrough

1 ;;; defconf: accept established,related,untracked
chain=input action=accept connection-state=established,related,untracked log=no log-prefix=“Defcon: Accepted Established”

2 ;;; defconf: accept ICMP
chain=input action=accept protocol=icmp log=no log-prefix=“Ping”

3 ;;; allow pptp
chain=input action=accept protocol=tcp dst-port=1723

4 ;;; defconf: accept to local loopback (for CAPsMAN)
chain=input action=accept dst-address=127.0.0.1

5 ;;; defconf: drop invalid
chain=input action=drop connection-state=invalid log=no log-prefix=“Invalid”

6 ;;; defconf: drop all not coming from LAN
chain=input action=drop in-interface-list=!LAN log=no log-prefix=“DROP_from_WAN”

7 ;;; Printer Defcon → VLAN10
chain=forward action=accept src-address=192.168.88.249 dst-address=192.168.10.11 log=no log-prefix=“Printer 88 → 10”

8 ;;; Printer VLAN10 → Defcon
chain=forward action=accept src-address=192.168.10.11 dst-address=192.168.88.249 log=no log-prefix=“Printer 10 → 88”

9 ;;; defconf: accept in ipsec policy
chain=forward action=accept ipsec-policy=in,ipsec

10 ;;; defconf: accept out ipsec policy
chain=forward action=accept ipsec-policy=out,ipsec

11 ;;; defconf: fasttrack
chain=forward action=fasttrack-connection connection-state=established,related

12 ;;; defconf: accept established,related, untracked
chain=forward action=accept connection-state=established,related,untracked

13 ;;; defconf: drop invalid
chain=forward action=drop connection-state=invalid log=no log-prefix=“Defcon: Drop invalid”

14 ;;; defconf: drop all from WAN not DSTNATed
chain=forward action=drop connection-state=new connection-nat-state=!dstnat in-interface-list=WAN

–END–

Kindly notice that in the meantime, I’ve changed the configuration, and now the traffic I would like to setup is between VLAN 10 (192.168.10.0/24 and defcon 192.168.88.0/24). All other stuff remains as described at the beginning.

After reading what you wrote, I realized that I probably put the rule(s) in the wrong order. But kindly take a look at the above configuration export and advise how to enable traffic between those two hosts properly.

9

Sorry that doesnt look like an export file format so will pass… to hard on the eyes. ( nor is it complete…

10

So it’s based on default firewall.

IP addresses are not the same as you were mentioning in earlier posts and I’m not sure if that’s relevant here. But anyways, connections towards 192.168.10.11 initiated from 192.168.88.249 (including PINGs etc.) should be allowed simply by rule #7. However, it would be much better off if it was actually moved after (current) rule #12. Current rule #8 should not be necessary as current rule #11 should handle the return traffic.

Updating rule to cover whole subnet by changing src-address and dst-address to values you mentioned should be fine.

11

Yes, true. As I stated in the previous post, in the meantime, I’ve changed the configuration a bit. Instead of VLAN30 (192.168.30.0/24) I use defcon config. now (192.168.88.0/24).


But anyways, connections towards 192.168.10.11 initiated from 192.168.88.249 (including PINGs etc.) should be allowed simply by rule #7. However, it would be much better off if it was actually moved after (current) rule #12.
Current rule #8 should not be necessary as current rule #11 should handle the return traffic.

OK, clear. It makes sense. Thank you!

Another question.
If I want to ensure that no traffic is enabled between VLAN10 and any other LAN interface, does the following rule make sense, or should I do it differently?
chain=forward action=drop src-address-list=VLAN_10 out-interface-list=!WAN

12

If you want to develop your firewall further, then follow advice by @anav (I’m surprised he didn’t chime in with it already): change ultimate firewall rule with two rules

chain=forward action=accept connection-state=new connection-nat-state=dstnat in-interface-list=WAN
chain=forward action=drop

Then add any necessary accept rules above the pair shown above (and below the “accept established,related” pair of rules). Idea is that it’s safer to block everything not allowed. Default firewall ruleset relies on accurate membership of two interface lists: LAN and WAN and membership is orthogonal (unless inexperienced admin messes up). The default rule optimizes the pair I wrote above and optimization is based on assuption that all relevant interfaces are either WAN or LAN interface list member. In your case you’re deviating from this principle and it’s better to go with explicit drop all rule and allow (without too many twists such as negation which is tricky by itself) what’s needed. And remember, the “accept established,related” will (in principle) take care of all return traffic so you only have to care about initial packet of connection (or “connection”, many protocols - such as UDP or ICMP - don’t know about connections, but connection tracking machinery tries to identify packets in return direction to “fake” connection). So only think about what kind of initial packet should be allowed.

13

I did chime in, need new reading glasses their mate!!
My usual post, context required and full config as I hate playiing whackamole, see the scope creep of the OP, its not one question its 20 questions, all easily nipped in the bud with the full config to clean up the firewall and any related config items. You like the long torturous method, I dont :stuck_out_tongue_winking_eye:

14

Guys, thanks for all your answers and guidance.
All are very useful.
@anav - Would it be possible for you to share a link to the advice mentioned by @mkx.

@anav - I’m with you with long torturous, but… at some point, I would like not only to resolve one issue but also to understand how the firewall on Miktorik works, and it’s, unfortunately, a bit long process for me :wink:

15

Select para B - https://forum.mikrotik.com/viewtopic.php?t=182373