Community discussions

MikroTik App
 
knctrnl
just joined
Topic Author
Posts: 3
Joined: Thu Mar 01, 2018 4:56 am

Access Control between VLANs

Thu May 10, 2018 11:30 pm

I have 2 bridges created. One for primary use and the other for guest.
I have two wlans to match each bridge.
All traffic seems to be allowed between each of the segments,vlans.
I have no policy allowing guest network to access the primary network in the firewall however its still allowed.
I have even tried adding a blockrule.
Is there something I am missing?
 
mkx
Forum Guru
Forum Guru
Posts: 3930
Joined: Thu Mar 03, 2016 10:23 pm

Re: Access Control between VLANs

Thu May 10, 2018 11:38 pm

By default, routers will route between all of its IP interfaces. If you want to prevent it, you have to use firewall filtering. Something like this:
/ip firewall filter
add chain=forward action=deny src-address=first.ip.sub.net/24 dst-address=second.ip.sub.net/24 comment="No routing between subnets XX and ZZ"
.
Remember that rule order (inside same chain) is important, first rule that matches, gets executed.
BR,
Metod
 
anav
Forum Guru
Forum Guru
Posts: 3616
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada

Re: Access Control between VLANs

Fri May 11, 2018 12:29 am

I have the exact same scenario. I place these rules after the accept Forwarding chain Rules and more specifically right after the default Forward chain Drop rules for INVALID and FROM WAN not DSTNATed.
Not sure if deny is better than drop, I tend to use drop.

Bridges are great in that they stop layer 2 traffic cold between them but the router can still route between them at layer 3 and thus one needs to put in Block IP Filter Rules.
You will see that I have two rules, one has to block in both directions!!
for the forward case. I use the in-interface: BridgeNAME for the origin of the traffic, so below I block DMZ to HOME and thus the in-interface is the DMZbridge etc......
homelan-bridge1
dmzlan-bridge2

/IP
Firewall Filter
add action=drop chain=forward comment="Block DMZ to LAN" dst-address=\
    192.168.0.0/24 in-interface=DMZ_Bridge src-address=192.168.2.0/24
add action=drop chain=forward comment="Block LAN to DMZ" dst-address=\
    192.168.2.0/24 in-interface=HomeBridge src-address=192.168.0.0/24

What I would like to know is if there is a better way to do this?
1. Is my in-interface identification OVERKILL and not needed since I also state source and destination subnets???
(I put in-interface because it helps me visualize where the traffic starts and thus which interface it touches first).
I'd rather manage rats than software. Follow my advice at your own risk! (Sob & mkx forced me to write that!)
 
RoadkillX
Frequent Visitor
Frequent Visitor
Posts: 87
Joined: Sun Apr 22, 2018 6:00 pm
Location: Spain

Re: Access Control between VLANs

Fri May 11, 2018 2:53 am

Is use-ip-firewall=yes for both bridges?

I don't know which device is being used but if it's not a CRS you'll only get hw-offloading on 1 of the bridges and you'll see high cpu usage, this is better done using vlans (Correct way to divide layer2 networks) since right now it's like 2 separate networks on individual switches joined by a router with all untagged traffic.

https://wiki.mikrotik.com/wiki/Manual:I ... _Bridge.29

After that you should be able to apply firewall rules as you've been doing it with the change that you'll be blocking traffic from dmz_vlan or lan_vlan.
 
squeeze
Member Candidate
Member Candidate
Posts: 146
Joined: Thu Mar 22, 2018 7:53 pm

Re: Access Control between VLANs

Fri May 11, 2018 5:10 am

/ip firewall address-list 
add list=VLAN address=192.168.10.0/24 comment="VLAN: 10"
add list=VLAN address=192.168.20.0/24 comment="VLAN: 20"
add list=VLAN address=192.168.30.0/24 comment="VLAN: 30"

/ip firewall filter
add chain=forward action="drop" comment="No inter-VLAN routing" \
    dst-address-list=VLAN src-address-list=VLAN log=yes log-prefix="InterVLAN"
Multi-directional, L3, inter-VLAN traffic block with one IP firewall filter rule using address list.
 
Sob
Forum Guru
Forum Guru
Posts: 5416
Joined: Mon Apr 20, 2009 9:11 pm

Re: Access Control between VLANs

Fri May 11, 2018 5:15 am

@anav: Any evil hacker can easily send packets with forged source, but they can't forge incoming interface.

If I connect to your DMZ_bridge, I can send anything to HomeBridge, as long as I use some other source than 192.168.0.0/24. Sure, it will be limited, I won't be able to establish tcp connections, but if you happen to have house's udp-controlled self-destruct button connected to HomeBridge, you might have a problem, if it wouldn't have own properly configured firewall.

This is the reason, why I prefer to block everything by default and add exception to allow stuff. I'd say it's harder to get it wrong. If I make a mistake and forget to allow something, I'll immediately see that it doesn't work. If you make a mistake and forget to block something, it's not that obvious. You may do the testing with something that the rule will block, but if it fails to block something else, you might never notice.
People who quote full posts should be spanked with ethernet cable. Some exceptions for multi-topic threads may apply. Not intended as incentive for masochists.
 
anav
Forum Guru
Forum Guru
Posts: 3616
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada

Re: Access Control between VLANs

Fri May 11, 2018 5:25 am

Hi Sob, you amaze me at your consistent and skilled ability to avoid my questions, make comments on my configuration that are puzzling and in the end leave me with a bitter taste and unfulfilled aspirations.......
But since I know the response is suck it up princess........... :-)
Lets get to it.
1. So are you saying my addition of in-interface is worthwhile and a good idea in addition to identifying the LANs
2. Do you like squeeze's idea of putting on all LANS and VLANS on one address list and then using that list as source and destination and putting block?

3. If you concur with 1 and like 2, but the problem here is one cannot do both at the same time sobchain=conundrom ;-)

4. Okay how do you propose BLOCK is default and allow is the exception in this case?? ko,
I'd rather manage rats than software. Follow my advice at your own risk! (Sob & mkx forced me to write that!)
 
Sob
Forum Guru
Forum Guru
Posts: 5416
Joined: Mon Apr 20, 2009 9:11 pm

Re: Access Control between VLANs

Fri May 11, 2018 5:59 am

Oh no, I'm trying to answer a lot of your questions. It's just that you often have very long posts, and I may sometimes fail to pick up what exactly you were asking about. I mean, I think that I usually know, and I try to tell you what you wanted to know (even though in some cases you didn't know that you wanted to know exactly that). Not necessarily each individual question, because if I did that, I'd be really writing a book. Trust me, I tried. English is not my native language and I did believe that I know it enough to express pretty much anything related to computers and networks. Trying to reply to some of your posts did shake this belief of mine. :)

About the current batch:

1) More like that when you really want to isolate two interfaces, use just in/out-interface and it will stop everything for sure. If you use src/dst-address (alone or together with interfaces), some unwanted traffic can still pass.
2) Not too much (sorry squeeze), because it has the same problem. If I connect something to physical vlan 10, I may be able to send some traffic to other vlans, if I use fake source address (e.g. 192.168.66.6).
4) Original post looks like it may be simple home setup with main LAN and guest LAN, so I'd do e.g.:
/ip firewall filter
add action=accept chain=forward connection-state=established,related
add action=drop chain=forward connection-state=invalid
add action=accept chain=forward in-interface=mainLAN out-interface=WAN
add action=accept chain=forward in-interface=guestLAN out-interface=WAN
add action=drop chain=forward
And there's no way how anything can sneak between main and guest LANs. If I later add VPN to some super-secret company network, nothing will be able to access it, until I add another accept rule. I will notice immediately on first attemp to access it that I need to add the rule. Compare it with:
/ip firewall filter
add action=accept chain=forward connection-state=established,related
add action=drop chain=forward connection-state=invalid
add action=drop chain=forward in-interface=WAN connection-nat-state=!dstnat
add action=drop chain=forward in-interface=mainLAN out-interface=guestLAN
add action=drop chain=forward in-interface=guestLAN out-interface=mainLAN
If I add VPN connection to super-secret company network with this config, all guests will be allowed to access it, until I add another rule to block them. And it's easy to miss, because they (guests) won't be complaning about having acccess where they shouldn't.
People who quote full posts should be spanked with ethernet cable. Some exceptions for multi-topic threads may apply. Not intended as incentive for masochists.
 
anav
Forum Guru
Forum Guru
Posts: 3616
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada

Re: Access Control between VLANs

Fri May 11, 2018 6:22 am

Very interesting!!
So the two difference I can see is that

1. you have two rules explicitly detailing where forward traffic from the LANs/VLANS can go
Instead of having two rules stating the router should block traffic from A to B and from B to A.

2. you remove the forward chain DROP rule for in-interface wan traffic not DSTNATed.
because you have a more powerful catch all rule Everything else forwarded - drop.

Okay, but why is this not the HEX default setup on the forward chain side then?
/ip firewall filter
add action=accept chain=forward connection-state=established,related
add action=drop chain=forward connection-state=invalid
add action=accept chain=forward in-interface=mainLAN out-interface=WAN  ( the default 192.168.88.0./24 LAN on etherport2)    and wan on etherport1)
add action=drop chain=forward
I'd rather manage rats than software. Follow my advice at your own risk! (Sob & mkx forced me to write that!)
 
Sob
Forum Guru
Forum Guru
Posts: 5416
Joined: Mon Apr 20, 2009 9:11 pm

Re: Access Control between VLANs

Fri May 11, 2018 6:53 am

It's hard to make everyone happy. I like block-by-default config better, but it's just one opinion. I think it's safer, but someone else might see it as annoying. Default config needs to find the right balance, be reasonably safe but not obtrusive. Current default config makes you safe from unwanted stuff from internet, that's the most important part. And when you add another LAN/VPN/etc, things "just work". With block-by-default config, they wouldn't. At least it would look that way to many people, some might even think that the router is broken, flood support with questions or complaints, ...
People who quote full posts should be spanked with ethernet cable. Some exceptions for multi-topic threads may apply. Not intended as incentive for masochists.
 
User avatar
mozerd
Member
Member
Posts: 312
Joined: Thu Oct 05, 2017 3:39 pm
Location: Canada
Contact:

Re: Access Control between VLANs

Fri May 11, 2018 3:00 pm

It's hard to make everyone happy. I like block-by-default config better, but it's just one opinion. I think it's safer, but someone else might see it as annoying. Default config needs to find the right balance, be reasonably safe but not obtrusive. Current default config makes you safe from unwanted stuff from internet, that's the most important part. And when you add another LAN/VPN/etc, things "just work". With block-by-default config, they wouldn't. At least it would look that way to many people, some might even think that the router is broken, flood support with questions or complaints, ...
I whole-heartily endorse @Sob's approach of BLOCK by default config --- it is MUCH safer!!!
 
squeeze
Member Candidate
Member Candidate
Posts: 146
Joined: Thu Mar 22, 2018 7:53 pm

Re: Access Control between VLANs

Fri May 11, 2018 4:39 pm

I liked your idea Sob, and since I already had implemented Drop By Default on the more security-sensitive Input chain (only allowing DNS and ICMP Echo Request from LAN), I decided to implement it for VLAN interfaces on the Forward chain.

Still, I was interested to see if another List method would work. :)
/interface list member 
add list=VLAN interface=vlan10
add list=VLAN interface=vlan20
add list=VLAN interface=vlan30

/ip firewall filter
add chain=forward action="drop" comment="No inter-VLAN routing" \
    in-interface-list=VLAN out-interface-list=VLAN log=yes log-prefix="InterVLAN"

Tested it and using interface lists also works. That way an explicit block cannot be IP spoofed!
 
anav
Forum Guru
Forum Guru
Posts: 3616
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada

Re: Access Control between VLANs

Fri May 11, 2018 5:42 pm

You deserve a squeeze for that gem of an idea!!
I'd rather manage rats than software. Follow my advice at your own risk! (Sob & mkx forced me to write that!)
 
anav
Forum Guru
Forum Guru
Posts: 3616
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada

Re: Access Control between VLANs

Fri May 11, 2018 6:16 pm

SOB Based approach, but for dummies guide..........
Getting close?
/ip firewall filter
{INPUT}
add action=add-src-to-address-list address-list=Port_Scans \
    address-list-timeout=days chain=input comment="Your typical port scanning input rule"\
    protocol=tcp (or udp) 
add action=drop chain=input comment=PREVENT WinBox Intrusion except for those on allow list" \
    dst-port=8291 protocol=tcp src-address-list= !allow
add action=accept chain=input comment="Accept established 
	and related connections" \ connection-state=established,related 
	protocol=tcp
add action=accept chain=input comment=\  ALLOW list admin access to Router (all ports)
    \ src-address-list=allow
add action=drop chain=input comment="Drop everything else for INPUT CHAIN"
{FORWARD}	
add action=accept chain=forward connection-state=established,related
add action=drop chain=forward connection-state=invalid
add action=accept chain=forward in-interface=mainLAN out-interface=WAN
add action=accept chain=forward in-interface=guestLAN out-interface=WAN
add action=drop chain=forward comment="Drop everyting else for FORWARD CHAIN
	
/ip firewall nat
add action=masquerade chain=srcnat comment="SCR_NAT for LAN Users" \
    ipsec-policy=out,none out-interface-list (assuming two WANs)
	
/ip firewall raw
add action=drop chain=prerouting comment=Drop your typical port scan list created" \
    src-address-list=Port_Scans
add action=drop chain=pretouting comment="Drop any other 'black lists'" \
    dst-address-list=blacklists or country lists etc..........
COMMENTS/Qs
WHY DO WE NOT HAVE UNTRACKED IN THE ACCEPT RULES For Input and Forward, as they are included in the Mikrotik Default Rules??
WHAT ABOUT DNS
WHAT ABOUT ICMP
I'd rather manage rats than software. Follow my advice at your own risk! (Sob & mkx forced me to write that!)
 
Sob
Forum Guru
Forum Guru
Posts: 5416
Joined: Mon Apr 20, 2009 9:11 pm

Re: Access Control between VLANs

Fri May 11, 2018 7:04 pm

@squeeze: In case the interface list is supposed to contain all vlans, it would be possible to skip it and use the magic "all-vlan" value (in-interface=all-vlan out-interface=all-vlan).

@anav: You don't need extra WinBox blocking rule, because you open its port only to admins and connection attempts from elsewhere will be dropped by last rule. Port scanning rule should go after accepting established connections, because what it looks for will have connection-state=new (or perhaps invalid). If it's first, you're wasting (a little bit of) resources on checking packets that will be allowed by established rule anyway, just a moment later. And you don't want to limit established to tcp only.

I keep forgetting about untracked, because it's relatively new in RouterOS and nothing becomes untracked unless you tell it to be (in raw), so if you don't do that, you don't need to allow it, because there will be none.

If you're not aiming for super-secure, I usually allow any input from LAN, because I trust it. If you don't, you can allow only tcp/udp 53 for dns (from LAN only, definitely not from WAN, it would make the router open resolver).

About icmp, I don't belive that being "invisible" by blocking icmp makes you any more secure, so I allow it. But opinions differ, some people think that it's good or even important. And in a way they are right. In theory it's possible that someone discovers a nasty bug that allows to bring the router down by sending a special icmp packet. It's highly unlikely, but not completely impossible. If that ever happens, icmp blockers will laugh at me and say "we told you!", but until then I'll enjoy the advantages, e.g. being able to quickly see if the router is alive, no matter where I'm currently connected.
People who quote full posts should be spanked with ethernet cable. Some exceptions for multi-topic threads may apply. Not intended as incentive for masochists.
 
anav
Forum Guru
Forum Guru
Posts: 3616
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada

Re: Access Control between VLANs

Fri May 11, 2018 7:46 pm

@squeeze: In case the interface list is supposed to contain all vlans, it would be possible to skip it and use the magic "all-vlan" value (in-interface=all-vlan out-interface=all-vlan).

Sob I think you are saying you like Squeezes rule but only if it includes all VLANs on his list. If this is not what you meant, what what rule would you use then?

@anav: You don't need extra WinBox blocking rule, because you open its port only to admins and connection attempts from elsewhere will be dropped by last rule. Port scanning rule should go after accepting established connections, because what it looks for will have connection-state=new (or perhaps invalid). If it's first, you're wasting (a little bit of) resources on checking packets that will be allowed by established rule anyway, just a moment later. And you don't want to limit established to tcp only.

OKAY SO, we can dispense with the WINBOX rule (overkill) and move the port scanning rule after established connections.

I keep forgetting about untracked, because it's relatively new in RouterOS and nothing becomes untracked unless you tell it to be (in raw), so if you don't do that, you don't need to allow it, because there will be none.

So to confirm you are saying we don't really need to state untracked (a very rare case only under our control - would require additional rules)

If you're not aiming for super-secure, I usually allow any input from LAN, because I trust it. If you don't, you can allow only tcp/udp 53 for dns (from LAN only, definitely not from WAN, it would make the router open resolver).

I am unsure on this one. Are you saying this for the INPUT CHAIN or for the FORWARD CHAIN?
If the former then you would want to see this rule vice the plain jane drop everything input chain rule??
add action=drop chain=input comment="defconf: drop all not coming from LAN" \
in-interface-list=!LAN


With regard to DNS, would you be happy with this then as the only required rules placed in the FORWARD CHAIN before the drop everything rule.
add action=drop chain=forward comment=" BLOCK DNS from wan side \
dst-port=53 in-interface=WAN protocol=udp and one for TCP as well


About icmp, I don't believe that being "invisible" by blocking icmp makes you any more secure, so I allow it. But opinions differ, some people think that it's good or even important. And in a way they are right. In theory it's possible that someone discovers a nasty bug that allows to bring the router down by sending a special icmp packet. It's highly unlikely, but not completely impossible. If that ever happens, icmp blockers will laugh at me and say "we told you!", but until then I'll enjoy the advantages, e.g. being able to quickly see if the router is alive, no matter where I'm currently connected.

So basically I only need the one rule at the end of my INPUT Chain accept rules, before the drop rules?
add action=accept chain=input comment="Allow PING" protocol=icmp

See bold comments above!
Last edited by anav on Fri May 11, 2018 8:19 pm, edited 1 time in total.
I'd rather manage rats than software. Follow my advice at your own risk! (Sob & mkx forced me to write that!)
 
squeeze
Member Candidate
Member Candidate
Posts: 146
Joined: Thu Mar 22, 2018 7:53 pm

Re: Access Control between VLANs

Fri May 11, 2018 8:06 pm

I cannot actually see any interface called "all-vlan" anywhere in Winbox nor in the online documentation. Would be very convenient if it did exist!
 
Sob
Forum Guru
Forum Guru
Posts: 5416
Joined: Mon Apr 20, 2009 9:11 pm

Re: Access Control between VLANs

Fri May 11, 2018 8:41 pm

@anav: From top:

1) No. Just that if the list is supposed to contain all vlans on router, there's simpler solution without list.

2) Yes.

3) Correct. If you don't use it, you don't need to allow it.

4) I meant when you use router as resolver, so chain=input. What I do when I trust whole LAN is simple:
/ip firewall filter
add action=accept chain=input in-interface=LAN
And it allows access from LAN to anything on router (DNS, WinBox, ...). If you don't want all that, but only DNS, then use:
/ip firewall filter
add action=accept chain=input in-interface=LAN protocol=udp dst-port=53
add action=accept chain=input in-interface=LAN protocol=tcp dst-port=53
You generally don't need drop rules when there's unconditional drop rule at the end of input chain (it drops everything not previously allowed). It goes for both input and forward.

But there's one thing I forgot, if you have drop rule at the end and you want forwarded ports to work, you need to allow them:
/ip firewall filter
add action=accept chain=forward connection-nat-state=dstnat
5) Yes.

@squeeze: I'm too lazy for screenshots, but this is what autocomplete suggests in CLI (WinBox has the same, only without hyphen):
[sob@CHR4] > ip firewall filter add in-interface=all-
all-ethernet  all-ppp  all-vlan  all-wireless
You're right, it doesn't seem to be documented, I only found it mentioned in RouterOS v6 news.
People who quote full posts should be spanked with ethernet cable. Some exceptions for multi-topic threads may apply. Not intended as incentive for masochists.
 
User avatar
MangleRule
Frequent Visitor
Frequent Visitor
Posts: 60
Joined: Mon May 07, 2018 1:05 am

Re: Access Control between VLANs

Fri May 11, 2018 9:00 pm

So to confirm you are saying we don't really need to state untracked (a very rare case only under our control - would require additional rules)

The untracked state is usually set in RAW or in...... MangleRules :lol:
Once a connection has been marked as untracked, all packets related and established in that connection will completely bypass connection tracking in the router. This means that any services on the router that rely on connection tracking (layer7 firewalls, fasttrack-connection, mark-connection, etc), any NAT rules, even packet de-fragmentation do not come in to play on those streams. So it doesn't even go through the router to where firewalls have any control.
MTCNAMTCREMTCINE | MTCTCE | MTCUME | UBWA
 
anav
Forum Guru
Forum Guru
Posts: 3616
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada

Re: Access Control between VLANs

Fri May 11, 2018 9:18 pm

Okay new and improved Version.............
/ip firewall filter
{INPUT}
add action=accept chain=input comment="Accept established 
	and related connections" \ connection-state=established,related 
	protocol=tcp
add action=accept chain=input comment=\  ALLOW list admin access to Router (all ports)
    \ src-address-list=allow
add action=add-src-to-address-list address-list=Port_Scans \
    address-list-timeout=days chain=input comment="Your typical port scanning input rule"\
    protocol=tcp (and one for udp)
add action=accept chain=input in-interface=LAN protocol=tcp dst-port=53
add action=accept chain=input in-interface=LAN protocol=udp dst-port=53
add action=accept chain=input comment="Allow PING" protocol=icmp
add action=drop chain=input comment="Drop everything else for INPUT CHAIN"

{FORWARD}	
add action=accept chain=forward connection-state=established,related
add action=drop chain=forward connection-state=invalid
add action=accept chain=forward in-interface=mainLAN out-interface=WAN
add action=accept chain=forward in-interface=guestLAN out-interface=WAN
add action=accept chain=forward connection-nat-state=dstnat**
add action=drop chain=forward comment="Drop everyting else for FORWARD CHAIN
	
/ip firewall nat
add action=masquerade chain=srcnat comment="SCR_NAT for LAN Users" \
    ipsec-policy=out,none out-interface-list (assuming two WANs)
add action=dstnat - port forwarding rules as required here**

/ip firewall raw
add action=drop chain=prerouting comment=Drop your typical port scan list created" \
    src-address-list=Port_Scans
add action=drop chain=pretouting comment="Drop any other 'black lists'" \
    dst-address-list=blacklists or country lists etc........
Questions??
1. What is the difference (which is better) between these two INPUT chain rules..?
a. add action=accept chain=input in-interface=LAN protocol=tcp dst-port=53
b. add action=accept chain=input connection-state=established port=53 protocol=tcp

2. Do I need any special rules for DNS in forwarding???
3. Do I need any output rules, never seen one but what can be done here???
I'd rather manage rats than software. Follow my advice at your own risk! (Sob & mkx forced me to write that!)
 
RoadkillX
Frequent Visitor
Frequent Visitor
Posts: 87
Joined: Sun Apr 22, 2018 6:00 pm
Location: Spain

Re: Access Control between VLANs

Fri May 11, 2018 9:42 pm

Okay new and improved Version.............
/ip firewall filter
{INPUT}
add action=accept chain=input comment="Accept established 
	and related connections" \ connection-state=established,related 
	protocol=tcp
add action=accept chain=input comment=\  ALLOW list admin access to Router (all ports)
    \ src-address-list=allow
add action=add-src-to-address-list address-list=Port_Scans \
    address-list-timeout=days chain=input comment="Your typical port scanning input rule"\
    protocol=tcp (and one for udp)
add action=accept chain=input in-interface=LAN protocol=tcp dst-port=53
add action=accept chain=input in-interface=LAN protocol=udp dst-port=53
add action=accept chain=input comment="Allow PING" protocol=icmp
add action=drop chain=input comment="Drop everything else for INPUT CHAIN"

{FORWARD}	
add action=accept chain=forward connection-state=established,related
add action=drop chain=forward connection-state=invalid
add action=accept chain=forward in-interface=mainLAN out-interface=WAN
add action=accept chain=forward in-interface=guestLAN out-interface=WAN
add action=accept chain=forward connection-nat-state=dstnat**
add action=drop chain=forward comment="Drop everyting else for FORWARD CHAIN
	
/ip firewall nat
add action=masquerade chain=srcnat comment="SCR_NAT for LAN Users" \
    ipsec-policy=out,none out-interface-list (assuming two WANs)
add action=dstnat - port forwarding rules as required here**

/ip firewall raw
add action=drop chain=prerouting comment=Drop your typical port scan list created" \
    src-address-list=Port_Scans
add action=drop chain=pretouting comment="Drop any other 'black lists'" \
    dst-address-list=blacklists or country lists etc........
Questions??
1. What is the difference (which is better) between these two INPUT chain rules..?
a. add action=accept chain=input in-interface=LAN protocol=tcp dst-port=53
b. add action=accept chain=input connection-state=established port=53 protocol=tcp

2. Do I need any special rules for DNS in forwarding???
3. Do I need any output rules, never seen one but what can be done here???
DNS queries work over 53/udp, tcp is only used for zone transfers, first rule is correct second is wrong if you only accept established connections all new will be dropped, you can do output same as input just make sure to create an outgoing accept rule in output chain for connections related, established or you wont be able to respond to incoming traffic. DNS forwarding is just allow outbound NAT or forward to remote 53/udp.
 
User avatar
MangleRule
Frequent Visitor
Frequent Visitor
Posts: 60
Joined: Mon May 07, 2018 1:05 am

Re: Access Control between VLANs

Fri May 11, 2018 9:43 pm

@anav:

1. What is the difference (which is better) between these two INPUT chain rules..?
a. add action=accept chain=input in-interface=LAN protocol=tcp dst-port=53
b. add action=accept chain=input connection-state=established port=53 protocol=tcp

Option A is correct. Option B: connection-state=established would only match something already accepted in the firewall, you already have an accept established and related rule at the top so Option B would never work or ever get any hits. (The rule should not be explicit to TCP though, the established and related rule should be for all protocols because established and related traffic would have to be approved lower on the firewall list.)

2. Do I need any special rules for DNS in forwarding???

Clients on your dhcp-server should use your router's DNS if you set the dns to your router in the /ip dhcp-server network menu. If you want to force the use of your server:

/ip firewall nat add chain=dstnat protocol=udp dst-port=53 action=dst-nat to-addresses="<routers.address>"
/ip firewall nat add chain=dstnat protocol=tcp dst-port=53 action=dst-nat to-addresses="<routers.address>"

3. Do I need any output rules, never seen one but what can be done here???

You will know when you need to do anything there. Output would control things sourced from the router itself out to another host/destination.
MTCNAMTCREMTCINE | MTCTCE | MTCUME | UBWA
 
User avatar
MangleRule
Frequent Visitor
Frequent Visitor
Posts: 60
Joined: Mon May 07, 2018 1:05 am

Re: Access Control between VLANs

Fri May 11, 2018 9:58 pm

DNS queries work over 53/udp, tcp is only used for zone transfers, first rule is correct second is wrong if you only accept established connections all new will be dropped, you can do output same as input just make sure to create an outgoing accept rule in output chain for connections related, established or you wont be able to respond to incoming traffic. DNS forwarding is just allow outbound NAT or forward to remote 53/udp.

If a host doesn't get a response from a UDP DNS query, it will retransmit the request over TCP.
MTCNAMTCREMTCINE | MTCTCE | MTCUME | UBWA
 
anav
Forum Guru
Forum Guru
Posts: 3616
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada

Re: Access Control between VLANs

Fri May 11, 2018 10:16 pm

when you state to addresses <routers address> did you mean the LANIP of the subnet?
For example if I have
home 192.168.0.1
DMZ 192.168.10.1

do you mean a to address list that includes 192.168.0.1 and 192.168.10.1 ?
or did you mean its wanIP address
or did you mean In-interface/interface-list
or did you mean out-interface/interface-list

This will force users to use Router selection?
Is this necessary?

What affect will this NAT rule have on any ROUTE rules where the router has to attempt to resolve a domain name for example........ no affect because the rules do not affect the router itself??
I'd rather manage rats than software. Follow my advice at your own risk! (Sob & mkx forced me to write that!)
 
RoadkillX
Frequent Visitor
Frequent Visitor
Posts: 87
Joined: Sun Apr 22, 2018 6:00 pm
Location: Spain

Re: Access Control between VLANs

Fri May 11, 2018 10:17 pm

DNS queries work over 53/udp, tcp is only used for zone transfers, first rule is correct second is wrong if you only accept established connections all new will be dropped, you can do output same as input just make sure to create an outgoing accept rule in output chain for connections related, established or you wont be able to respond to incoming traffic. DNS forwarding is just allow outbound NAT or forward to remote 53/udp.

If a host doesn't get a response from a UDP DNS query, it will retransmit the request over TCP.
Don't agree with that. But i'll believe you.
 
Sob
Forum Guru
Forum Guru
Posts: 5416
Joined: Mon Apr 20, 2009 9:11 pm

Re: Access Control between VLANs

Fri May 11, 2018 10:24 pm

@anav: Your input rule to accept established & related still has protocol=tcp. You want to accept all established and related traffic, not just tcp. The rest was answered by others.
/ip firewall nat add chain=dstnat protocol=udp dst-port=53 action=dst-nat to-addresses="<routers.address>"
...
This can be also done using:
/ip firewall nat add chain=dstnat protocol=udp dst-port=53 action=redirect
Special note to anav, this thing is entirely optional and I'd say only needed for special circumstances. Feel free to ignore it. And this note is not meant as anything against MangleRule. :)
People who quote full posts should be spanked with ethernet cable. Some exceptions for multi-topic threads may apply. Not intended as incentive for masochists.
 
User avatar
MangleRule
Frequent Visitor
Frequent Visitor
Posts: 60
Joined: Mon May 07, 2018 1:05 am

Re: Access Control between VLANs

Fri May 11, 2018 10:31 pm

Special note to anav, this thing is entirely optional and I'd say only needed for special circumstances. Feel free to ignore it. And this note is not meant as anything against MangleRule. :)

Even though redirect makes more semantic sense, unfortunately redirect can only redirect port numbers :(
MTCNAMTCREMTCINE | MTCTCE | MTCUME | UBWA
 
User avatar
MangleRule
Frequent Visitor
Frequent Visitor
Posts: 60
Joined: Mon May 07, 2018 1:05 am

Re: Access Control between VLANs

Fri May 11, 2018 10:34 pm

when you state to addresses <routers address>did you mean the LANIP of the subnet?

Exactly, so <routers.address> is just what I put in the code example to be replaced for whatever address is reachable on your router. By default, dhcp clients will use the gateway for any routes the host doesn't know of. You could use 192.168.0.1 or 192.168.10.1 it doesn't really matter.

This will force users to use Router selection?
Is this necessary?

This completely depends on your requirements. If someone were to override their DNS server on the host machine, they wouldn't be able to get to any private DNS records you statically enter into the router. The two firewall NAT rules are only necessary if you want to force clients on your network to use your MikroTik as it's DNS resolver.

What affect will this NAT rule have on any ROUTE rules where the router has to attempt to resolve a domain name for example........ no affect because the rules do not affect the router itself??

I usually always try to be explicit in the rules and would normally have inbound interfaces. I honestly would have to try the rule as I posted above and see what happens when the router makes a request lol.
MTCNAMTCREMTCINE | MTCTCE | MTCUME | UBWA
 
User avatar
MangleRule
Frequent Visitor
Frequent Visitor
Posts: 60
Joined: Mon May 07, 2018 1:05 am

Re: Access Control between VLANs

Fri May 11, 2018 10:38 pm

I just did a quick test. I ran a DNS query to google.com with the NAT rules in place and there were no hits on the rules. So the rules I listed above will have no effect on the router's self resolution for DNS.
MTCNAMTCREMTCINE | MTCTCE | MTCUME | UBWA
 
Sob
Forum Guru
Forum Guru
Posts: 5416
Joined: Mon Apr 20, 2009 9:11 pm

Re: Access Control between VLANs

Fri May 11, 2018 10:49 pm

redirect - replaces destination port of an IP packet to one specified by to-ports parameter and destination address to one of the router's local addresses
First part is optional, you can skip to-ports and port will stay the same. But second part is the main point of action=redirect, it always changes destination to router's own address without a need to give a specific one.
What affect will this NAT rule have on any ROUTE rules where the router has to attempt to resolve a domain name for example........ no affect because the rules do not affect the router itself??
None. The rule makes sure that dns queries sent by other devices can't bypass dns cache on router, so they are redirected to dns resolver running on router. And when it asks upstream resolver (from /ip dns), it's regular output from router.
So the rules I listed above will have no effect on the router's self resolution for DNS.
Correct, there's no dstnat for output in MikroTik world.
People who quote full posts should be spanked with ethernet cable. Some exceptions for multi-topic threads may apply. Not intended as incentive for masochists.
 
anav
Forum Guru
Forum Guru
Posts: 3616
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada

Re: Access Control between VLANs

Fri May 11, 2018 10:51 pm

Awesome,

So, on the input side I said allow DNS queries to the router on port 53 but only from in-interface LAN.

Then I reduce this ability to state when someone queries the DNS via port 53, direct them to the gateway (thus preventing an individual PC from using 8.8.8.8 for example). They will have to use the DNS options I have setup in the router?

If its the default for lan clients to go out their respective gateway why do I have to make this rule?

On another note:
I do have some scan rules for INPUT chain add to address list, and drop them in raw.
Is there ever a case for scan or spam rules for FORWARD chain add to address list? Could RAW be used to drop them as well?

Finally: Brain fart is there a reason why there is no DROP invalid rule on the INPUT Chain??
Last edited by anav on Fri May 11, 2018 10:56 pm, edited 1 time in total.
I'd rather manage rats than software. Follow my advice at your own risk! (Sob & mkx forced me to write that!)
 
User avatar
MangleRule
Frequent Visitor
Frequent Visitor
Posts: 60
Joined: Mon May 07, 2018 1:05 am

Re: Access Control between VLANs

Fri May 11, 2018 10:53 pm

First part is optional, you can skip to-ports and port will stay the same. But second part is the main point of action=redirect, it always changes destination to router's own address without a need to give a specific one.

Oh cool! That is very useful, I probably should have checked the documentation lol
MTCNAMTCREMTCINE | MTCTCE | MTCUME | UBWA
 
User avatar
MangleRule
Frequent Visitor
Frequent Visitor
Posts: 60
Joined: Mon May 07, 2018 1:05 am

Re: Access Control between VLANs

Fri May 11, 2018 11:02 pm

They will have to use the DNS options I have setup in the router?

With both rules, any traffic on TCP/UDP 53 will get the destination address in the packet replaced with the router's IP address so it doesn't matter what they set their machine to.

If its the default for lan clients to go out their respective gateway why do I have to make this rule?

That is the default but if they enter a static DNS server on the host machine, the static will take precedence on the operating system. By setting the firewall rules, all the packets are getting NAT'd by the router so the packet will go where the router says to go.

I do have some scan rules for INPUT chain add to address list, and drop them in raw.
Is there ever a case for scan or spam rules for FORWARD chain add to address list? Could RAW be used to drop them as well?

You can use RAW for whatever you want to. RAW tables have two chains, prerouting and output. With RAW filter rules, you can block traffic before it ever touches connection tracking which makes it really good for denial of service mitigation. The only time you can't use RAW for something is if you need to be able to check connection-state or inspect the packet stream using like layer 7 firewalls since the router wont have a chance to de-fragment the packets.
MTCNAMTCREMTCINE | MTCTCE | MTCUME | UBWA
 
User avatar
MangleRule
Frequent Visitor
Frequent Visitor
Posts: 60
Joined: Mon May 07, 2018 1:05 am

Re: Access Control between VLANs

Fri May 11, 2018 11:08 pm

Finally: Brain fart is there a reason why there is no DROP invalid rule on the INPUT Chain??

You should have a drop invalid for the input chain. Basically any packets coming in that do not have a connection tracking entry for it's source and destination and are not new connections, they are invalid packets. You do not want those packets traditionally because it can be malicious.
MTCNAMTCREMTCINE | MTCTCE | MTCUME | UBWA
 
anav
Forum Guru
Forum Guru
Posts: 3616
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada

Re: Access Control between VLANs

Fri May 11, 2018 11:33 pm

Interesting mangle.
What do you recommend for dos type scenario.
Option 1: tarpit input chain traffic - something about changing data package size being sent - not sure how it does this and to what traffic incoming or returning? Net effect I am told is slowing down the incoming?
Option 2: Drop input chain traffic with RAW hammer.

Practically speaking both options have to do the same initial step of identifying incoming traffic by some mechanism? Probably a combination of period of Time and number of connections?
I'm assuming the EXTRA page comes into play but what makes sense for setup? After detection then the offending IP is added to an address list for xx hours or days etc........
The first option upon detecting an IP on the list applies TARPIT action on it.
The second option upon detecting an IP on the list RAW drops it.

Thus, it boils down to how to effectively identify and capture such traffic and secondly what is more effective, tarpit or raw drop?
I'd rather manage rats than software. Follow my advice at your own risk! (Sob & mkx forced me to write that!)
 
User avatar
MangleRule
Frequent Visitor
Frequent Visitor
Posts: 60
Joined: Mon May 07, 2018 1:05 am

Re: Access Control between VLANs

Fri May 11, 2018 11:41 pm

Interesting mangle.
What do you recommend for dos type scenario.
Option 1: tarpit input chain traffic - something about changing data package size being sent - not sure how it does this and to what traffic incoming or returning? Net effect I am told is slowing down the incoming?
Option 2: Drop input chain traffic with RAW hammer.

Practically speaking both options have to do the same initial step of identifying incoming traffic by some mechanism? Probably a combination of period of Time and number of connections?
I'm assuming the EXTRA page comes into play but what makes sense for setup? After detection then the offending IP is added to an address list for xx hours or days etc........
The first option upon detecting an IP on the list applies TARPIT action on it.
The second option upon detecting an IP on the list RAW drops it.

Thus, it boils down to how to effectively identify and capture such traffic and secondly what is more effective, tarpit or raw drop?

Honestly, DOS situations are very difficult to deal with:

action=tarpit will basically capture and hold TCP connections open. Many attacks try to spam new connections in large numbers, tarpit will force the connections to stay open causing resource issues on the attacker's side.

Dropping the attack will work. but the main issue with DOS attacks is that the attacker will flood your internet "pipe" during the attack to deny you service. If you don't have enough bandwidth to contain the attack you just have to wait it out. Large scale ISPs can offer blackhole services to stop attacks before they hit your router but they blackhole the IP address getting attack so you are still out service without an IP address change.

TLDR: If you don't have enough bandwidth you are at the mercy of the attack until they get bored or move on.
MTCNAMTCREMTCINE | MTCTCE | MTCUME | UBWA
 
anav
Forum Guru
Forum Guru
Posts: 3616
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada

Re: Access Control between VLANs

Fri May 11, 2018 11:43 pm

So are you saying dont bother with such rules??
Regardless I am interested in how one would identify such trafffic using the mikrotik,,,,,,,, what combination of time and connections in the extra page would do the trick...........
I'd rather manage rats than software. Follow my advice at your own risk! (Sob & mkx forced me to write that!)
 
User avatar
MangleRule
Frequent Visitor
Frequent Visitor
Posts: 60
Joined: Mon May 07, 2018 1:05 am

Re: Access Control between VLANs

Fri May 11, 2018 11:50 pm

So are you saying dont bother with such rules??
Regardless I am interested in how one would identify such trafffic using the mikrotik,,,,,,,, what combination of time and connections in the extra page would do the trick...........

If you don't have multiple Gbps of bandwidth available, you can not do anything to use your service during the attack. For example, say you are getting attacked by some form of DOS attack and they are attempting to throw 500Mbps of data at your router. If you are on a residential line you are literally screwed. You would need to have enough bandwidth to sustain the attack and have extra to use yourself during the attack. If you had a 1Gbps internet connection for example, even during the attack you have another 500Mbps available on the pipe. At that point your firewall rules can be used to optimize the CPU load on the router during the attack. If you don't have the bandwidth, the firewall rules are pointless because you pipe from your ISP is already full of junk data.

There are some options called scrubbing services where you can have the traffic go through a third party and blocked before it is directed to you but you would need BGP and way more money than it would cost to get a large bandwidth pipe.
MTCNAMTCREMTCINE | MTCTCE | MTCUME | UBWA
 
anav
Forum Guru
Forum Guru
Posts: 3616
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada

Re: Access Control between VLANs

Fri May 11, 2018 11:57 pm

Okay last time I will list the list on this thread...........
One question though remains, when looking at the TO address for the NAT DSTNAT rule for DNS,
How would I best handle the fact that I would have multiple router LANIP gateway addresses.
Consider each LAN or VLAN will have its own gateway?
One cannot use a LIST for to addresses ?


/ip firewall filter
{INPUT}
add action=accept chain=input comment="Accept Good Traffic 
	\ connection-state=established,related
add action=drop chain=input connection-state=invalid  comment="No one noticed this was missing you cads!! ;-)"
add action=accept chain=input comment="ALLOW list access to Router (all ports)
    \ src-address-list=allow
add action=add-src-to-address-list address-list=Port_Scans \
    address-list-timeout=days chain=input comment="Your typical port scanning input rule"\
    protocol=tcp (and one for udp)
add action=accept chain=input in-interface=LAN protocol=tcp dst-port=53
add action=accept chain=input in-interface=LAN protocol=udp dst-port=53
add action=accept chain=input comment="Allow PING" protocol=icmp
add action=drop chain=input comment="Drop everything else for INPUT CHAIN"

{FORWARD}	
add action=accept chain=forward connection-state=established,related
add action=drop chain=forward connection-state=invalid
add action=accept chain=forward in-interface=mainLAN out-interface=WAN
add action=accept chain=forward in-interface=guestLAN out-interface=WAN
add action=accept chain=forward connection-nat-state=dstnat
add action=add-src-to-address-list  addresslist=scan-spam  chain=forward \
	comment="ports and protocol as necessary" 
add action=drop chain=forward comment="Drop everything else for FORWARD CHAIN
	
/ip firewall nat
add action=masquerade chain=srcnat comment="SCR_NAT for LAN Users" \
    ipsec-policy=out,none out-interface-list (assuming two WANs)
add action=dstnat - port forwarding rules as required here**
add chain=dstnat protocol=udp dst-port=53 action=dst-nat to-addresses="<gatewayLANIP of router> (like 192.168.0.1)
add chain=dstnat protocol=tcp dst-port=53 action=dst-nat to-addresses="<gatewayLANIP of router>

/ip firewall raw
add action=drop chain=prerouting comment=Drop your typical input port scan list created" \
    src-address-list=Port_Scans
add action=drop chain=pretouting comment="Drop any other input 'black lists'" \
    src-address-list=blacklists or country lists etc..........
add action=drop chain=pretouting comment="Drop any forward scan-spam traffic"\
    scr-address-list=scan-spam
Last edited by anav on Fri May 11, 2018 11:59 pm, edited 1 time in total.
I'd rather manage rats than software. Follow my advice at your own risk! (Sob & mkx forced me to write that!)
 
RoadkillX
Frequent Visitor
Frequent Visitor
Posts: 87
Joined: Sun Apr 22, 2018 6:00 pm
Location: Spain

Re: Access Control between VLANs

Fri May 11, 2018 11:58 pm

So are you saying dont bother with such rules??
Regardless I am interested in how one would identify such trafffic using the mikrotik,,,,,,,, what combination of time and connections in the extra page would do the trick...........
Mirror the wan port to an ethernet interface and check all traffic with wireshark, you can drop excesive syn, invalid pkts, icmp and so on but still consumes bandwidth for that traffic to get to you even though you are not replying (drop) and udp not much you can do, you'll recieve everything even if you end up dropping it. And attacks like slowloris on a web server you won't even notice it because it's not a flood won't trigger anything on the firewall either.
 
User avatar
MangleRule
Frequent Visitor
Frequent Visitor
Posts: 60
Joined: Mon May 07, 2018 1:05 am

Re: Access Control between VLANs

Sat May 12, 2018 12:08 am

Okay last time I will list the list on this thread...........
One question though remains, when looking at the TO address for the NAT DSTNAT rule for DNS,
How would I best handle the fact that I would have multiple router LANIP gateway addresses.
Consider each LAN or VLAN will have its own gateway?
One cannot use a LIST for to addresses ?

It really doesn't matter which gateway you use for the two firewall rules (192.168.0.1 or 192.168.10.1). Lets say you chose "192.168.0.1". All clients in the 192.168.0.0/24 subnet already know that IP is reachable since it is the gateway address. If a client from the 192.168.10.0/24 subnet tries to get to 192.168.0.1, it has no clue where that is so it will use the default gateway of 192.168.10.1 to see if the router knows where 192.168.0.1 is. The router will know that 192.168.0.1 is itself and since you have a firewall rule on the input chain accepting DNS it will still work. You do not have to specify every possible gateway.

Sob pointed out something very useful too, you can just use action=redirect and it will automatically redirect the traffic to itself. (There won't even be a to-addresses option)
MTCNAMTCREMTCINE | MTCTCE | MTCUME | UBWA
 
RoadkillX
Frequent Visitor
Frequent Visitor
Posts: 87
Joined: Sun Apr 22, 2018 6:00 pm
Location: Spain

Re: Access Control between VLANs

Sat May 12, 2018 12:13 am

Okay last time I will list the list on this thread...........
One question though remains, when looking at the TO address for the NAT DSTNAT rule for DNS,
How would I best handle the fact that I would have multiple router LANIP gateway addresses.
Consider each LAN or VLAN will have its own gateway?
One cannot use a LIST for to addresses ?


/ip firewall filter
{INPUT}
add action=accept chain=input comment="Accept Good Traffic 
	\ connection-state=established,related
add action=drop chain=input connection-state=invalid  comment="No one noticed this was missing you cads!! ;-)"
add action=accept chain=input comment="ALLOW list access to Router (all ports)
    \ src-address-list=allow
add action=add-src-to-address-list address-list=Port_Scans \
    address-list-timeout=days chain=input comment="Your typical port scanning input rule"\
    protocol=tcp (and one for udp)
add action=accept chain=input in-interface=LAN protocol=tcp dst-port=53
add action=accept chain=input in-interface=LAN protocol=udp dst-port=53
add action=accept chain=input comment="Allow PING" protocol=icmp
add action=drop chain=input comment="Drop everything else for INPUT CHAIN"

{FORWARD}	
add action=accept chain=forward connection-state=established,related
add action=drop chain=forward connection-state=invalid
add action=accept chain=forward in-interface=mainLAN out-interface=WAN
add action=accept chain=forward in-interface=guestLAN out-interface=WAN
add action=accept chain=forward connection-nat-state=dstnat
add action=add-src-to-address-list  addresslist=scan-spam  chain=forward \
	comment="ports and protocol as necessary" 
add action=drop chain=forward comment="Drop everything else for FORWARD CHAIN
	
/ip firewall nat
add action=masquerade chain=srcnat comment="SCR_NAT for LAN Users" \
    ipsec-policy=out,none out-interface-list (assuming two WANs)
add action=dstnat - port forwarding rules as required here**
add chain=dstnat protocol=udp dst-port=53 action=dst-nat to-addresses="<gatewayLANIP of router> (like 192.168.0.1)
add chain=dstnat protocol=tcp dst-port=53 action=dst-nat to-addresses="<gatewayLANIP of router>

/ip firewall raw
add action=drop chain=prerouting comment=Drop your typical input port scan list created" \
    src-address-list=Port_Scans
add action=drop chain=pretouting comment="Drop any other input 'black lists'" \
    src-address-list=blacklists or country lists etc..........
add action=drop chain=pretouting comment="Drop any forward scan-spam traffic"\
    scr-address-list=scan-spam
if each vlan has its own gateway which is the router why not use the router as your DNS server and allow incoming traffic on each vlan to destination port 53/udp (the router) otherwise just allow incoming on each vlan with destination any udp/53 and in nat create from source desired vlan for all traffic going to destination 53/udp masquerade or src-nat so they can query 4.2.2.2, 8.8.8.8 or whatever they wish . it's up to you, i preffer having dns on the router less queries going out and faster response from cache.
 
User avatar
MangleRule
Frequent Visitor
Frequent Visitor
Posts: 60
Joined: Mon May 07, 2018 1:05 am

Re: Access Control between VLANs

Sat May 12, 2018 12:13 am

So in conclusion thanks to Sob:

/ip firewall nat 
  add chain=dstnat protocol=udp dst-port=53 action=redirect
  add chain=dstnat protocol=tcp dst-port=53 action=redirect
MTCNAMTCREMTCINE | MTCTCE | MTCUME | UBWA
 
User avatar
MangleRule
Frequent Visitor
Frequent Visitor
Posts: 60
Joined: Mon May 07, 2018 1:05 am

Re: Access Control between VLANs

Sat May 12, 2018 12:16 am

if each vlan has its own gateway which is the router why not use the router as your DNS server and allow incoming traffic on each vlan to destination port 53/udp (the router) otherwise just allow incoming on each vlan with destination any udp/53 and in nat create from source desired vlan for all traffic going to destination 53/udp masquerade or src-nat so they can query 4.2.2.2, 8.8.8.8 or whatever they wish . it's up to you, i preffer having dns on the router less queries going out and faster response from cache.

The whole purpose of the dst-nat rules he is talking about IS to force the use of the MikroTik as the DNS server for the network. Masquerade has nothing to do with this because Masquerade is using src-nat. We need to use dst-nat to change the DNS server destination to the MikroTik, using redirect with do that nicely as listed above.
MTCNAMTCREMTCINE | MTCTCE | MTCUME | UBWA
 
RoadkillX
Frequent Visitor
Frequent Visitor
Posts: 87
Joined: Sun Apr 22, 2018 6:00 pm
Location: Spain

Re: Access Control between VLANs

Sat May 12, 2018 12:22 am

if each vlan has its own gateway which is the router why not use the router as your DNS server and allow incoming traffic on each vlan to destination port 53/udp (the router) otherwise just allow incoming on each vlan with destination any udp/53 and in nat create from source desired vlan for all traffic going to destination 53/udp masquerade or src-nat so they can query 4.2.2.2, 8.8.8.8 or whatever they wish . it's up to you, i preffer having dns on the router less queries going out and faster response from cache.

The whole purpose of the dst-nat rules he is talking about IS to force the use of the MikroTik as the DNS server for the network. Masquerade has nothing to do with this because Masquerade is using src-nat. We need to use dst-nat to change the DNS server destination to the MikroTik, using redirect with do that nicely as listed above.
Yes redirect will do the job, just didn't understand what he actually wanted to do. And i do know how snat and dnat work, thank for the explanation though. Mikrotik firewall is very basic when used to working with iptables.
 
User avatar
MangleRule
Frequent Visitor
Frequent Visitor
Posts: 60
Joined: Mon May 07, 2018 1:05 am

Re: Access Control between VLANs

Sat May 12, 2018 12:37 am

And i do know how snat and dnat work, thank for the explanation though.

I was just stating that your suggestions about Masquerade was coming from left field here and was the opposite of the requirement.

Mikrotik firewall is very basic when used to working with iptables.

I mean.... iptables are very simple as well. They are basically even in complexity.
MTCNAMTCREMTCINE | MTCTCE | MTCUME | UBWA
 
User avatar
CZFan
Forum Guru
Forum Guru
Posts: 1637
Joined: Sun Oct 09, 2016 8:25 pm
Location: South Africa, Randburg
Contact:

Re: Access Control between VLANs

Sat May 12, 2018 12:39 am

DNS queries work over 53/udp, tcp is only used for zone transfers, first rule is correct second is wrong if you only accept established connections all new will be dropped, you can do output same as input just make sure to create an outgoing accept rule in output chain for connections related, established or you wont be able to respond to incoming traffic. DNS forwarding is just allow outbound NAT or forward to remote 53/udp.

If a host doesn't get a response from a UDP DNS query, it will retransmit the request over TCP.

DNS zone transfers uses tcp, normal name queries uses udp, if there are extended info in the name query and packet bigger than 512 bytes, it will use tcp. Standard name queries can also use tcp, but only if the application is written as such.
MTCNA, MTCTCE, MTCRE & MTCINE
 
anav
Forum Guru
Forum Guru
Posts: 3616
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada

Re: Access Control between VLANs

Sun May 13, 2018 4:00 am

Great news SOB, i implemented a variation of your rules with some others and despite having my IP Routes reachable on both internet and email, I dont have internet or email connectivity LOL.
I am trying to figure out why but dont see anything obvious. If I get desperate I will ask for help............
I'd rather manage rats than software. Follow my advice at your own risk! (Sob & mkx forced me to write that!)
 
User avatar
MangleRule
Frequent Visitor
Frequent Visitor
Posts: 60
Joined: Mon May 07, 2018 1:05 am

Re: Access Control between VLANs

Sun May 13, 2018 4:09 am

Great news SOB, i implemented a variation of your rules with some others and despite having my IP Routes reachable on both internet and email, I dont have internet or email connectivity LOL.
I am trying to figure out why but dont see anything obvious. If I get desperate I will ask for help............
What is the application for? Your own personal router?
MTCNAMTCREMTCINE | MTCTCE | MTCUME | UBWA
 
anav
Forum Guru
Forum Guru
Posts: 3616
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada

Re: Access Control between VLANs

Sun May 13, 2018 4:24 am

Yes, home is running off a zyxel usg40W, and using the hex on a second IP from my WAN2 (cable).
I think the issue may be my lan to wan allow rules in forwarding as the last rule drop all for forward chain is hitting traffic that should have been passed through.
Will let you know.

EDIT - FIXED.

Lesson to self. After playing around 3000rule changes over a few weeks, REBOOT the router!! I took out the what I thought were the offending rules, no change, removed the drop all rule, no change. Then the light went on......... try the reboot. Then I got connectivity. I added back all the rules I disabled, and rebooted, VOILA success. So all my rules are good, my stable process needs work LOL.
Last edited by anav on Sun May 13, 2018 4:42 am, edited 1 time in total.
I'd rather manage rats than software. Follow my advice at your own risk! (Sob & mkx forced me to write that!)
 
Sob
Forum Guru
Forum Guru
Posts: 5416
Joined: Mon Apr 20, 2009 9:11 pm

Re: Access Control between VLANs

Sun May 13, 2018 4:40 am

Great news SOB, ...
Hey, my nice name isn't turning into significantly less nice acronym, is it? It would break my heart! ;)

But ok, I probably should have mentioned that it's good idea to first add a logging rule at the end, and only when it doesn't catch something that's not supposed to be there, change it to drop/reject rule.
People who quote full posts should be spanked with ethernet cable. Some exceptions for multi-topic threads may apply. Not intended as incentive for masochists.
 
anav
Forum Guru
Forum Guru
Posts: 3616
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada

Re: Access Control between VLANs

Sun May 13, 2018 3:01 pm

Great news SOB, ...
Hey, my nice name isn't turning into significantly less nice acronym, is it? It would break my heart! ;)
Yes it was a play on Words x3
But ok, I probably should have mentioned that it's good idea to first add a logging rule at the end, and only when it doesn't catch something that's not supposed to be there, change it to drop/reject rule.
Now what would that look like? I think you have a triple negative in one sentence LOL. I have not made a logging rule yet - is there even a chain=log?
I'd rather manage rats than software. Follow my advice at your own risk! (Sob & mkx forced me to write that!)
 
Sob
Forum Guru
Forum Guru
Posts: 5416
Joined: Mon Apr 20, 2009 9:11 pm

Re: Access Control between VLANs

Sun May 13, 2018 4:25 pm

Simple, first add this as last rule, instead of drop:
/ip firewall filter
add action=log chain=forward log-prefix="this would be dropped"
If you see log full of traffic you don't want to drop, fix previous rules. And when you're happy with the result, change this rule into drop rule. If you're too eager to drop stuff right away, you may end up locked out (more likely with input chain than forward).
People who quote full posts should be spanked with ethernet cable. Some exceptions for multi-topic threads may apply. Not intended as incentive for masochists.
 
anav
Forum Guru
Forum Guru
Posts: 3616
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada

Re: Access Control between VLANs

Sun May 13, 2018 4:39 pm

Sweet!
I'd rather manage rats than software. Follow my advice at your own risk! (Sob & mkx forced me to write that!)

Who is online

Users browsing this forum: carlosaat and 107 guests