Good Evening. I had a problem with the configuration Mikrotik CCR1009.
I Have 2 wan (WAN1-1.1.1.1) and (WAN2-2.2.2.2)
2 Lan (LAN1-192.168.101.0/24) and (LAN2-192.168.102.0/24)
192.168.100.0/22 = ALL my LAN 192.168.101.0/24+192.168.102.0/24
Some people are coming out through a WAN1
Another part through the WAN2
Wan1 constantly on
Wan 2 off, when the Wan 1 drop Wan 2 on. (use Netwatch ping 8.8.8.
In parallel, some users constantly using the WAN2 (Route List-Rules)
My route list:
/ip route
add distance=4 gateway=2.2.2.2 routing-mark=to_wan2
add comment=WAN1 distance=2 gateway=1.1.1.1
add comment=WAN2 disabled=yes distance=3 gateway=2.2.2.2
add comment=ping_yandex distance=1 dst-address=77.88.8.8/32 gateway=1.1.1.1
/ip route rule
add src-address=192.168.101.60/32 table=to_wan2
add src-address=192.168.101.40/32 table=to_wan2
add src-address=192.168.101.34/32 table=to_wan2
add src-address=192.168.101.14/32 table=to_wan2
add src-address=192.168.101.15/32 table=to_wan2
add src-address=192.168.101.100/32 table=to_wan2
add src-address=192.168.101.101/32 table=to_wan2
I have a lot of resources within the network which is to be accessed through the domain name.
Access from the world I’m forwarding through the NAT.Access to local resources on the domain name made by a Hairpin Nat:
add action=netmap chain=dstnat comment=Redmine dst-port=12000 in-interface=WAN1 protocol=tcp to-addresses=192.168.101.113 to-ports=80
add action=netmap chain=dstnat dst-port=12000 in-interface=WAN2 protocol=tcp to-addresses=192.168.101.113 to-ports=80
add action=netmap chain=dstnat dst-address=WAN1 dst-port=12000 protocol=tcp src-address=192.168.100.0/22 to-addresses=192.168.101.113 to-ports=80
add action=netmap chain=dstnat dst-address=WAN dst-port=12000 protocol=tcp src-address=192.168.100.0/22 to-addresses=192.168.101.113 to-ports=80
add action=masquerade chain=srcnat dst-address=192.168.101.113 dst-port=80 protocol=tcp src-address=192.168.100.0/22
I have a problem, users on the WAN1 can access internal resources and users WAN2 no.
How to configure access users WAN2?
I would recommend that you use dst-nat as the action instead of netmap, as netmap is stateless, and dst-nat is stateful, so you don’t need to properly catch all of the source nat cases in the outbound reply packets.
This rule should be able to replace your dstnat chain that you posted earlier:
add chain=dstnat dst-address-type=local dst-address=!192.168.100.0/22 protocol=tcp dst-port=12000 action=dst-nat to-addresses=192.168.101.113 to-ports=80
This will work regardless of in-interface or wan IP address. The only “limitation” of this is that the pinholes you open on WAN1 will be identical on WAN2, or coming from the LAN as a hairpin pinhole, but I think consistency is a good thing, which is why I put “limitiation” in quotes.
Of course, any other pinhole rules would look the same, just use different ports/protocols/etc…
Or if you want to be slick, add a custom chain: pinholes, and do it like this:
chain=dstnat dst-address-type=local dst-address=!192.168.100.0/22 action=jump jump-target=pinholes
chain=pinholes protocol=tcp dst-port=12000 action=dst-nat to-addresses=192.168.101.113 to-ports=80
chain=pinholes protocol=tcp dst-port=25 action=dst-nat to-addresses=192.168.100.25 to-ports=25 comment=“smtp server”
…
chain=pinholes action=return comment=“no matches - return to dstnat chain”
This way, the pinhole rules are obvious, and you don’t have to add so many criteria to each and every one of them.
Oh - one more thing is to make sure that your mangle rules are flagging connections as they arrive on the WAN interfaces so the replies will be forced out the proper WAN interface by your policy routing.
Thank you very much. I replaced one of your rule 4 of its own.
but if the user leaves Ceres gateway 2.2.2.2 he still can not get to a local resource on the domain name
even when I connect to the VPN network, all available in addition to PCs which are set in Route List that go through Wan2(2.2.2.2)
And the problem is, all users wan1 do not see those who walk through wan2 gateway.
Most likely, the problem is that these destinations are not in your policy routing properly. Make sure that lan1 users have lan2 in their routing policy, and that the other users of 2.2.2.2 have the public IP of wan1 in their routing table.
