You’re adding a route mark to all traffic, including that from 192.168.1.0/24 <->192.168.3.0/24. By adding the route mark, you are causing the traffic to only use routing table entries with those route marks and if you look at your routing table, you have no route to 192.168.1.0/24 or 192.168.3.0/24 with route marks of RouteToPrimus to RouteToBell. Once the packets are “route-marked” you restrict the route table entries which can be used to route said packets.
You can simply duplicate the 192.168.1.0/24 and 192.168.3.0/24 routes as static routes with both those route marks or you can adjust your mangle rules to not touch intra-LAN traffic. You can also add some routing rules to handle those intra-lan cases.
To duplicate the local routes, double click on the route for 192.168.1.0/24 in Winbox, press Copy, pick the RouteToPrimus routing mark, adjust the distance to 1 and press OK. Repeat for the 192.168.3.0/24 and again on both for the RouteToBell routing table/marks.
I did what you said, Duplicating routes and marking them with routes mark
but it does not seam to work
Now instead of leaving for internet it just request time out
Capture.PNG
Just to be sure this is what I did
Capture.PNG
Also, I how could I make mangles rules not mark intranet trafic.
I though that
I haven’t use that selector in the mangle, but I think it only applied to traffic destined for a process on the router. Your intra-LAN traffic is not destined for a process on the router.
Instead of “dst-address-type=!local” you could try “dst-address=!192.168.0.0/16”.
To just in case remove any mark on internal traffic, but it doesn’t seam to pickup any
Capture.PNG
Do any one have an idea from were could that problem come from ?
I did a tracert from the 3.* network to 1.* network and I get unlimited request timed out. Maybe thats an indicator for something ?
Capture.PNG
again thanks a lot, for any help I can get.
Can you please check your firewall filter for an accept on the forward chain for packets from either of the networks?
In general, your rules are really hard to read. You are abusing the connection tracking engine, you don’t need it at all in your setup - since you don’t provide any failover, networks are statically linked to providers, so simple packet level marks should do
Mangle prerouting:
For packets from interface 5 where dest is not 192.168.0.0/16 set routing mark Primus
For packets from interface 4 where dest is not 192.168.0.0/16 set routing mark Bell
nat srcnat:
masquerade packets flowing out of Bell interface
masquerade packets flowing out of Primus interface
fliter forward:
allow connection state established
allow connection state related
allow source address 192.168.0.0/16
routes:
0.0.0.0/0 via Bell OR Primus - select your default route for packets from the router itself
0.0.0.0/0 via Bell routing mark Bell
0.0.0.0/0 via Primus routing mark Primus
other routes will be dynamic for the connected interfaces
I will try that configuration tonight actually.
I did all that configuration not very knowing what I was doing and only by looking at PCC example that people was referring to me
Could you explain what does the following rules though?
fliter forward:
allow connection state established
allow connection state related
allow source address 192.168.0.0/16
this is a method of allowing forwarding for packets that are part of session initiated from within your network.
If someone from WAN sends a packet with your local network as a destination, then the router with an ALLOW forward policy will simply forward it. This is bad because someone may attack devices in your home network.
On the other hand, such forwarding is needed for simple internet access.
So the solution is to only allow forwarding for packets that are already part of a communication session (established, related) or those that originate from your local network. This way your internal computer can always initiate a session and then response packets will flow through because they are part of an established connection.
For a simple test setup you may always allow forwarding, but in real life you should apply policies, and better to use in-interface as the method to detect locally originated packets rather than src-address field (because it can be easily spoofed)
Okay, now I updated my config like you said.
But I still have that ping issue
It is very very weird to me
For example I can’t ping 1.12,1.41 or 1.111 and when I am connected to the same interface as these I can ping all these.
Same thing for tracert If i tracert any of these address I have the same “Timeout” on hop 2
Capture.PNG
now the weird thing is ( as you can see in the last picture ) I can ping and tracert 1.20
Even wierd-er! ,If I ping 1.12 it doesn’t work, But I can access a security camera server on that 1.12:5150
And I can ping every devices on 3.* from the 1.* interface..
Any one again.. have an idea ?
Now the following is my literal configuration ( except I removed username and password )
Before i dive into config parsing, first thing I usually do in such cases:
/tool sniffer
set filter-interface=all filter-ip-address=192.168.0.0/16 filter-ip-protocol=icmp filter-direction=any filter-port=""
quick
Then i start ping and observe the flow or packets in real time. Please do that and post the two cases: working and not working. Don’t need to port hundreds of them, just one-two roundtrips of the ping
well for now the only problem I see with your config is
add action=drop chain=forward comment=\
"Block All Trafic for Computer in warehouse ( virus ) Except Remote Desktop" dst-port=\
!3389 protocol=tcp src-address=192.168.1.20
This rule doesn’t work as it should by the comment, as it will not match (i.e. will allow) any traffic that is not tcp. The task should be accomplished with two rules, in this order
one matching tcp port 3389 from192.168.1.20 and accepting it,
and the other blocking everything from 192.168.1.20
Interestingly enough, this is the same address that you can ping.
something that stroke me right now: the machine you are using for ping test, does it have a static ip address? Cause if so, it may be an address from 192.168.1.0/24, that’s why it would work when you ping 3* from 1*
First of all, you have to be careful with this setup to not plug yourself in the wrong interface, cause then you will observe problems.
Secondly, what I see from the sniffed packets looks like 1.14 and 1.21 don’t have proper routes set up. Are you sure they have their gateway set properly to 1.1? If you have access to those machines, check their network config and routes, and use sniffer like wireshark to see where the responses go.
Also I did go see every of these computer and they are correctly setted up as dhcp, and they all have ip of there own network and the gateway is setted up as 1.1
For routes I think they are okay since from all IPs that i can’t ping, They all seam to be able to ping any device on 3.*
Capture2.PNG
Capture3.PNG
From my understanding here, Route 0.0.0.0 to gateway 192.168.1.1 should make a packet with dst-adr go to 192.168.1.1 and from there the router should redirect it to interface 5 right ?
And Here this is the wire shark result from that computer (192.168.1.41) when im pinging on it
Capture.PNG
I don’t get what does no response mean
Please examine the firewall settings on the workstations, if they only allow for ICMP on the local network. Just turn the firewall off for the sake of testing
