Hi all, following online documentation and videos i managed to forward mi LANs to WANs.
This is my config.
ISP Router with 3 LAN ports.
The 3 LAN ports are WAN ports on the Mikrotik.
They have address:
192.168.100.10
192.168.100.20
192.168.100.30
The 3 LANs on my Mikrotik are:
192.168.10.1
192.168.20.1
192.168.30.1
I can forward everything coming rom 192.168.10.0 to 192.168.100.10 and so on using mangles.
I cannot find a rule to allow the 3 LANs to see each other.
I would like to be able to pin 192.168.20.0 and 192.168.30.0 from 192.168.10.0… and so on.
I think I need some static routes, but I am doing some mistake I cannot find.
1:
2: The 3 PCs must reach each other. Nothe that ther are rules to make the 3 LANs use the 3 WANs.
3: As soon as I arrive home, I will post configuration. I am at office now… I could replicate it on my VM, but it would be a little different.
So you want each subnet to get a dedicated WAN, but each users on each subnet should also be able to reach each other?
Or is it more restrictive across subnets, some users from a to b, some a to c, and some b to c, but none c to a or b ???
Once we see the config, it should be quick to fix.
I think I have to change it according to the advice you are giving to me in the other thread.
Anyway your first idea was correct: each users on each subnet should also be able to reach each other.
No restrictions.
Ok, I really cannot understand.
I reduced to 2 my networks and I have:
192.168.100.81/24
192.168.100.82/24
that are the 2 WAN ports connected to my ISP router (192.168.100.1)
With this configuration:
1 - I am able to browse the Internet from both eth4 and eth5, but I exit using eth1 and not eth1 and eth2.
2 - I cannot ping 192.168.10.X from 192.168.20.x
3 - I CAN ping 192.168.20.X from 192.168.10.x
The routing rules need work.
The first two rules are good and ensure that LAN users can see each other, and then you apply the rules forcing certain subnets out certain wans.
The problem is your use of dst-addresses applies to allowing subnet to subnet access but not to forcing out to WANs. You need source address to identify the subnets going out the WANs.
THe first set of rules identifed subnets you want to visit (destination), the second set of rules identifies which source should go out which wan
SO.
Hi
I can tell you some common showstoppers that might prevent a migration to ROS7:
Compatibility: ROS7 is not backward compatible with previous versions of ROS. This means that any existing ROS nodes, packages, or software developed for previous versions of ROS will need to be modified or rewritten to work with ROS7.
System requirements: ROS7 requires a more powerful hardware system than previous versions of ROS. This may require an upgrade to existing hardware or the purchase of new hardware, which could be expensive and time-consuming.
Learning curve: ROS7 introduces new features and capabilities that may require a significant amount of time and effort to learn. This may be a showstopper for organizations or individuals who are comfortable with the current ROS version and don’t have the resources to invest in learning new technologies.
Third-party package availability: The availability of third-party packages and libraries for ROS7 may be limited in the early stages after its release. This may make it difficult for developers to find and use the tools they need to build their applications.
Stability and reliability: ROS7 is a new version of ROS, and it may have bugs or stability issues that could cause problems for developers and end-users. This is a significant showstopper for mission-critical applications where reliability is of utmost importance.
In summary, migrating to ROS7 can be a challenging process, and there are various factors to consider before making the switch. It is essential to evaluate the compatibility of existing software, hardware requirements, learning curves, availability of third-party packages, and stability and reliability of the new version before deciding whether or not to migrate.
Ok, now it should work… but it does not.
I cannot browse the Internet.
Here is the configuration (note that I had to change ports since port 1 seem,s burned… if I attach anything to it the router poweroff).
These 2 routes are RED:
Here is the new configuration.
If I use 192.168.100.1 as default gateway everything works fine, but I do not have the traffic split between the 2 ports.
It looks like I cannot use 192.168.100.81 and 192.168.100.82 which are the Mikrotik WAN IP interfaces.
Nothing
Tracreoute does not even arrive to the first hop.
I am wondering why I cannot choose the out interface.
This router is a rock star, it shouldn’t be so difficult: “What is coming from port 4 and has to go to 0.0.0.0/0 has to go to port 2”…
Do you think I can solve?
Assuming you are using three ports coming out of ISP router and plugging into 3 ports on the MT.
This should work…
/routing table add fib name=useWAN1
/routing table add fib name=useWAN2
/routing table add fib name=useWAN3
I cannot understand.
Everything is still going out thru the same interface.
Even if I disable the dedicated routes, everything works fine.
What am I mistaking?
Moreover, it looks like the only rule really followed is
add dst-address=0.0.0.0/0 gateway=192.168.100.1 routing-table=MAIN
since I do not have connection on my clients if I disable that route.
The problem was in the red part of anav configuration.
This is finally correct… Thanks everybody. @pcunite: are you sure the topic you posted covers my case?
I cannot find it.
Are you saying the red parts are still there???
Shouldnt be??
Also in these routing rules the bits in colour can be removed!
add action=lookup-only-in-table disabled=no dst-address=0.0.0.0/0 src-address=192.168.10.0/24 table=useWAN10
add action=lookup-only-in-table disabled=no dst-address=0.0.0.0/0 src-address=192.168.20.0/24 table=useWAN20
Have adjusted my previous post to show that the routing rules do not require destination address of WANIP, that was in error ( non-required matching condition, unless were trying to capture incoming WAN traffic as well in the mix )
So yes, you should be good to go!
You are using masquerade rules for sourcnat still, no harm its just more accurate to use src-nat action for fixed IPs.
