In this case you need to configure (DST) NAT ... and you'll probably have to enable use-ip-firewall on bridge settings. Beware that IP firewall rules behave slightly differently when acting on bridge traffic (compared to ordinary IP traffic).
bridge filters only block certain traffic, they don't redirect it to different target (which is what NAT does).
It would be much easier if you could move that ether port off bridge and into a different IP subnet. In that case, your Mikrotik would do routing between that port and the rest of LAN, making it possible to use normal IP firewall with all of it's strengths.
Thanks for the pointers, I’ll take a look in that direction. The Dude spat this out last night when I asked it a few questions. Which also points to the following in the Example after it.
/interface bridge settings set use-ip-firewall=yes
I am puzzled by this. The whole point of a Guest Network is that everything breezes through your LAN to the wider internet without touching the sides, ie without interacting with your LAN in any way. So it seems you want to break the essence of a Guest Network.
What I have not understood from this is why you want to use a DNS at 192.168.0.5 and a client at 192.168.0.35/24 on a guest network. Obviously, the actually numbers are not the issue. The missing information is what are the essential qualities of these addresses and their relationship to your house and guest networks. This is looking to me like you are in the classic territory of deciding ~How To~ do something without being fully clear on ~What~ you want to do and bumping up against problems in the implementation, when a better understanding of ~What~ you want to do could yield better solutions.
For example, it looks to me that your special client might be better served by having its own guest network crafted for different limitations than your main guest network.
It’s as simple as this, I want to point that devcie to a dns I have setup pointing to https quad9 via a dnscryt-proxy while blocking all other access to dns with a DoH filter because I wanted to monitor what it does and keep it seperate. Why. maybe because access to that server was blocked.
I get your point that in real terms it would make no sense, I just wanted to know how to do it. The problem is as you have speculated, networking isn’t my strong point. I fix cars for a living! does that mean i shouldn’t try?
As they say, if you want to go there, I wouldn't start from here.
That is your ~How To~
This is closer to your problem statement, your ~What~ :
I would be thinking of putting your dns onto a vLAN of its own [with a separate IP subnet], separate from the guest network and the house network and allowing both the House network and the Guest network access to this vLAN through the firewall. That way you are not compromising the House and Guest Networks separation. Others may have a different take, but it is a less granular approach to giving that access. If you have other services on 192.168.0.5, which you don't want your Guest Network to access, I would suggest that the place to do this would be the firewall on the device at 192.168.0.5 itself
As an other, my take is the same as it always is, an issue described in a solution based format is bound to fail the first test. As you have alluded to, the how is not even important at this stage, its the why!
a. Identify all the user(s)/device(s), external and internal, including the admin(s),
b. Identify all the traffic they need to accomplish
A network diagram showing what devices are involved, how they are connected and conceptually some subnet data flows is also very helpful
The config, actual evidence and a demonstration of intent, is essential.
Contorting the network into some form of lunacy is the outcome of not following a logical proven engineering approach to software/functionality. Surprisingly a number of the IT folks here, have not grasped that either. Its a matter of having a coherent plan, that accounts for all the requirements, and then and only then can a config be contemplated, that will be comprehensive, efficient and effective.
Setting up Networking, IT, computing stuff is a different mindset. Fixing cars is out with the tool box and wind nuts and bolts anticlockwise and put stuff in a heap until you find what's making the noise. But networking. For this, you need to stand back and visualise consequences before deciding on a course of action
I think that is pulling people opposite to the direction you want to push them. There is a class of problem, of which this one is typical, where it would be much easier if people came here before they got near doing a config for the solution. In that situation, we could discuss strategy eg do we break the Guest - House Network separation by brute force or do we turn the resource [OP's DNS] into a vLAN so that the House and Guest Networks access it on equal terms as just another resource like the WAN. And we could do all of that without ever thinking about the config.
My experience from my days of teaching C programming was that the last thing I ever needed to teach was the C Language itself. What was necessary was to teach the compilation process and to teach the process of analysing the problem. Once those things were in place, anyone who wanted to do the job would figure out the rest and do the code for themselves. Similarly, I think the OP here really needs a steer on sorting out his strategy and pushing for a config is actually making OP take some steps forward when he should be taking a step back.
Aye, don't tell me, everything has switched to left hand threads.
More seriously, I stand by the point fixing broken things requires diving in to the deep detail. Whereas implementing new facilities on Networks or anything requires standing back from the detail.
Exactly right, we are pulling people into communicating effectively. Extracting from them the relevant information with which to solve their issues. The wish to achieve some goal, often not articulated in a way that makes sense either IN RoS or networking but in some muddled way in their brain. Requirements analysis is a method to both understand the workflow desired and to articulate them in a factual way ( functional/technical). Until we have facts, the OP is merely expressing opinions. We are turning opinions into a validated set of information ( some semblance of truth ). From this we can then apply our knowledge of Ros and networking into a selection of approaches and then narrow them down to what makes sense, knowing the whole of the requirements.
