I have a MikroTik Router model RB951Ui-2HnD running version 7.23.2, and I have applied these settings to it:
On port Ether1, I have setup the internet via a PPPoE client.
On port Ether2, I have setup a network in the 192.168.1.x range with internet access.
On port Ether3, I have setup a network in the 192.168.10.x range that does not have internet access.
However, I need the two networks clients with the 192.168.1.x and 192.168.10.x ranges to communicate with each other.
The other ports are not being used.
The problem is that clients in these two network ranges cannot see each other.
I checked everything, but the only solution I found was to create three srcnat rules:
One for Ether2 traffic to the internet (from 192.168.1.0/24 to the public IP address).
One for Ether2 traffic to Ether3 (from 192.168.1.0/24 to the 192.168.10.1 address).
One for Ether3 traffic to Ether2 (from 192.168.10.0/24 to the 192.168.1.1 address).
This is the only way they can communicate with each other.
Are these three srcnat rules really necessary, or have I configured something incorrectly?
Mikrotik router has 2 sections - Input and Forward. Input section is for incoming traffic, and Forward - traffic that passes through the router. If you need to manage access strip networks, then this is usually done in the forward section.How to configure the firewall so that traffic works correctly - rules and security
Allow forwarding between the LANs. If you have firewall rules that drop forwarding, add rules like:
I have started with a similar requirement, pre my first Mikrotik router and carried over the setup to my first Mikrotik router. What I did was to give addresses in both ranges to machines which should see each other and the internet and addresses in the restricted range to those machines which should not see the internet.
No need to do anything special with the router, just be able set up multiple IP addresses on some machines.I did dhcp for internet access and fixed IP for everything else.
I placed the rules at the top of the firewall filter list, disabled the srcnat rules, and checked the logs.
I observed that the source client's requests were reaching the destination client using the source client's original IP address (e.g., 192.168.1.201 > 192.168.10.100); even though I set them to "accept," the connection still failed.
However, when I enable srcnat and disable the filter rules, the client requests are first translated to the gateway's IP and then proceed to the destination client using that gateway IP (e.g., 192.168.1.201 > 192.168.10.1 > 192.168.10.100). In this case, the connection is established without any issues.
Routing simply means passing along the packets, and this means that the src address is passed along as-is. This is not some sort of weirdness, but exactly how it should work.
In some scenarios it may be necessary to change (translate) the src address to one in the same subnet as the destination. This is what srcnat does.
So... what you have to clarify or find out is what "the connection succeeds" means: what are the devices and what requirements they have as to where they accept connections from.
Specifically, we are dealing with two Windows 10 computers across two subnets that are intended to communicate solely with each other (for instance, using ICMP for a ping). Without srcnat, the operation fails with a timeout error.
however, when srcnat is applied, and translating the src address to the destination gateway's address, the operation succeeds, and a reply is received.
in my windows days, i saw once that windows firewall blocking ICMP response for foreign source addresses ...
ex if win is 192.168.0.2/24 it wont respond for ping from 10.2.2.4/24, only for pings comming from own /24 network regardless of valid default gateway
from this point of view, masquerading (srcnat) which you observed is understandable
Here are some screenshots of the Windows Defender Firewall inbound rules that by default only let ICMP echo requests from the same subnet through. You need to edit the rules, changing the remote address to Any IP Address if you want your ping tests to succeed.
But this only affects ping. The services / apps that you really need to use (for example RDP) might or might not have that restriction enabled.
Yes, the problem was exactly what you pointed out. Disabling the Windows firewall resolved the issue.
however, since creating firewall rules across all the Windows machines would have been too time consuming, I opted to meet the organization's requirements using `srcnat` rules instead.
Thank you for your input and guidance, as well as that of the others.
The important thing is to understand the root cause. Sometimes, for practical reasons, it's not the purest solution that ends up being the best overall.
There is just one point that was a bit unclear to me.
In the 192.168.1.0/24 network, I have a system where the windows firewall allows Remote Desktop access only from a specific IP on another network (e.g., 192.168.10.101).
Even though srcnat translates requests from the 192.168.10.0/24 range to 192.168.1.1, Windows still sees the 192.168.10.101 IP and grants access.
How is it possible for the source IP to be translated yet still be recognized by Windows as the original source IP?
The principled answer is that there is really no way to do that. Once the src addr is altered, the information is lost from the perspective of the recepient.
The obvious solution is to NAT only when you have to. Either selectively where you need it, or excluding specifically where you don't want it.
Very often I find it useful to replace the action (in your case srcnat) with a jump to a custom chain that looks like this:
No need to use mangle for that. Assuming RDP clients are in LAN1 and RDP server are in LAN2, just normal plain chain=forward filter rules in this order:
