Community discussions

 
shin29
just joined
Topic Author
Posts: 15
Joined: Thu Feb 15, 2018 4:04 am

Routing Problem

Thu Feb 15, 2018 4:27 am

I have existing network 192.168.1.0/24 controlled by Cisco router.

Recently, I have added Mikrotik Router under this network as connecting LAN cable from Cisco Router into Mikrotik. Mikrotik Server address 192.168.1.2

In Mikrotik, I create another routing 10.0.0.0/20. I could access from 10.0.0.x network to 192.168.1.x but not opposite way.

Could anyone please give me instruction on how to connect 192.168.1.x to 10.0.0.x network.

Thanks,
 
sindy
Forum Guru
Forum Guru
Posts: 3994
Joined: Mon Dec 04, 2017 9:19 pm

Re: Routing Problem

Thu Feb 15, 2018 1:59 pm

I have existing network 192.168.1.0/24 controlled by Cisco router.

Recently, I have added Mikrotik Router under this network as connecting LAN cable from Cisco Router into Mikrotik. Mikrotik Server address 192.168.1.2

In Mikrotik, I create another routing 10.0.0.0/20. I could access from 10.0.0.x network to 192.168.1.x but not opposite way.

Could anyone please give me instruction on how to connect 192.168.1.x to 10.0.0.x network.

Thanks,
If your Mikrotik is in default configuration, you'll have to disable most of its "/ip firewall filter" rules and the masquerade rule in "/ip firewall nat" and tell the Cisco that the gateway to access 10.0.0.0/20 is 192.168.1.2.

What happens now is that the source address of any packet from 10.0.x.x/20 to anything outside 10.0.0.0/20 is rewritten to the IP address of Mikrotik's uplink interface, which is 192.168.1.2. So the responses come to that address and Mikrotik knows where to forward them thanks to connection tracking, but packets for 10.0.0.0/20 from outside the Mikrotik are likely sent to Cisco's default gateway.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
shin29
just joined
Topic Author
Posts: 15
Joined: Thu Feb 15, 2018 4:04 am

Re: Routing Problem

Fri Feb 16, 2018 2:26 am

I have existing network 192.168.1.0/24 controlled by Cisco router.

Recently, I have added Mikrotik Router under this network as connecting LAN cable from Cisco Router into Mikrotik. Mikrotik Server address 192.168.1.2

In Mikrotik, I create another routing 10.0.0.0/20. I could access from 10.0.0.x network to 192.168.1.x but not opposite way.

Could anyone please give me instruction on how to connect 192.168.1.x to 10.0.0.x network.

Thanks,
If your Mikrotik is in default configuration, you'll have to disable most of its "/ip firewall filter" rules and the masquerade rule in "/ip firewall nat" and tell the Cisco that the gateway to access 10.0.0.0/20 is 192.168.1.2.

What happens now is that the source address of any packet from 10.0.x.x/20 to anything outside 10.0.0.0/20 is rewritten to the IP address of Mikrotik's uplink interface, which is 192.168.1.2. So the responses come to that address and Mikrotik knows where to forward them thanks to connection tracking, but packets for 10.0.0.0/20 from outside the Mikrotik are likely sent to Cisco's default gateway.

Thank you very much for your explanation. I am very new to Mikrotik, so could you please let me know which I should disable and what I should add to tell Mikrotik to the gateway 192.168.1.2


/ip firewall filter print
Flags: X - disabled, I - invalid, D - dynamic
0 D chain=forward action=jump jump-target=hs-unauth hotspot=from-client,!auth
1 D chain=forward action=jump jump-target=hs-unauth-to hotspot=to-client,!auth
2 D chain=input action=jump jump-target=hs-input hotspot=from-client
3 D chain=input action=drop protocol=tcp hotspot=!from-client
dst-port=64872-64875
4 D chain=hs-input action=jump jump-target=pre-hs-input
5 D chain=hs-input action=accept protocol=udp dst-port=64872
6 D chain=hs-input action=accept protocol=tcp dst-port=64872-64875
7 D chain=hs-input action=jump jump-target=hs-unauth hotspot=!auth
8 D chain=hs-unauth action=reject reject-with=tcp-reset protocol=tcp
9 D chain=hs-unauth action=reject reject-with=icmp-net-prohibited
10 D chain=hs-unauth-to action=reject reject-with=icmp-host-prohibited
11 X ;;; place hotspot rules here
chain=unused-hs-chain action=passthrough
12 chain=input action=accept connection-state=established,related

/ip firewall nat print
Flags: X - disabled, I - invalid, D - dynamic
0 D chain=dstnat action=jump jump-target=hotspot hotspot=from-client
1 D chain=hotspot action=jump jump-target=pre-hotspot
2 D chain=hotspot action=redirect to-ports=64872 protocol=udp dst-port=53
3 D chain=hotspot action=redirect to-ports=64872 protocol=tcp dst-port=53
4 D chain=hotspot action=redirect to-ports=64873 protocol=tcp hotspot=local-dst dst-port=80
5 D chain=hotspot action=redirect to-ports=64875 protocol=tcp hotspot=local-dst dst-port=443
6 D chain=hotspot action=jump jump-target=hs-unauth protocol=tcp hotspot=!auth
7 D chain=hotspot action=jump jump-target=hs-auth protocol=tcp hotspot=auth
8 D chain=hs-unauth action=redirect to-ports=64874 protocol=tcp dst-port=80
9 D chain=hs-unauth action=redirect to-ports=64874 protocol=tcp dst-port=3128
10 D chain=hs-unauth action=redirect to-ports=64874 protocol=tcp dst-port=8080
11 D chain=hs-unauth action=redirect to-ports=64875 protocol=tcp dst-port=443
12 D chain=hs-unauth action=jump jump-target=hs-smtp protocol=tcp dst-port=25
13 D chain=hs-auth action=redirect to-ports=64874 protocol=tcp hotspot=http
14 D chain=hs-auth action=jump jump-target=hs-smtp protocol=tcp dst-port=25
15 X ;;; place hotspot rules here
chain=unused-hs-chain action=passthrough
16 ;;; masq. vpn traffic
chain=srcnat action=masquerade src-address=192.168.89.0/24
17 chain=srcnat action=masquerade out-interface-list=WAN
18 ;;; masquerade hotspot network
chain=srcnat action=masquerade src-address=10.0.0.0/20
19 ;;; masquerade hotspot network
chain=srcnat action=masquerade src-address=10.0.0.0/20
20 ;;; masquerade hotspot network
chain=srcnat action=masquerade src-address=10.0.0.0/20
21 ;;; masquerade hotspot network
chain=srcnat action=masquerade src-address=10.0.0.0/20
 
sindy
Forum Guru
Forum Guru
Posts: 3994
Joined: Mon Dec 04, 2017 9:19 pm

Re: Routing Problem

Fri Feb 16, 2018 1:04 pm

If the automatically generated firewall rules of the hotspot are involved, I'm not your man as I have no practical experience with the hotspot functionality. But normally it is not desired to have hotspot clients available from connection requests coming from outside, so maybe describe your use case, maybe you don't actually need to connect the clients using the hotspot functionality?

Second, the setting of Mikrotik as a gateway to 10.0.0.0/20 must be done at the Cisco, not at the Mikrotik itself.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
User avatar
acruhl
Member
Member
Posts: 359
Joined: Fri Jul 03, 2015 7:22 pm

Re: Routing Problem

Fri Feb 16, 2018 2:31 pm

Diagram it.

Specifically, show how the MikroTik is connected to the Cisco (what port, and is it the "WAN" port on the MikroTik).

We need to know if you're trying to do do NAT or not. If not, it's a simple matter of adding routes to both sides. If you are doing NAT, "it doesn't really work that way".

Also do /export hide-sensitive and post it here. Firewall rules alone don't tell the story.
Stuff.
 
shin29
just joined
Topic Author
Posts: 15
Joined: Thu Feb 15, 2018 4:04 am

Re: Routing Problem

Sat Feb 17, 2018 4:55 am

If the automatically generated firewall rules of the hotspot are involved, I'm not your man as I have no practical experience with the hotspot functionality. But normally it is not desired to have hotspot clients available from connection requests coming from outside, so maybe describe your use case, maybe you don't actually need to connect the clients using the hotspot functionality?

Second, the setting of Mikrotik as a gateway to 10.0.0.0/20 must be done at the Cisco, not at the Mikrotik itself.
I set hotspot functionality because I need all computer clients to connect to Mikrotik with pre-authorized MAC address. Without authorization, users wont be able to access to the network or internet. I know I have to do some configuration at the Cisco side too, but I do not have access to that as it is controlled by Provider. Is there anything I could do, as to change Mikrotik and all clients default gateway? The problem now is I could browse 192.168.x.x from my new segment 10.0.x.x however not in vice versa. I also want 192.168.x.x to browse my new segment 10.0.x.x
 
shin29
just joined
Topic Author
Posts: 15
Joined: Thu Feb 15, 2018 4:04 am

Re: Routing Problem

Sat Feb 17, 2018 5:00 am

Diagram it.

Specifically, show how the MikroTik is connected to the Cisco (what port, and is it the "WAN" port on the MikroTik).

We need to know if you're trying to do do NAT or not. If not, it's a simple matter of adding routes to both sides. If you are doing NAT, "it doesn't really work that way".

Also do /export hide-sensitive and post it here. Firewall rules alone don't tell the story.
Mikrotik is connected to WAN port from Cisco router on ether1. and I add new hub on ether2 to share the connection to the other clients. The main purpose is because Cisco does not have MAC Address control and I could use hotspot function from Mikrotik to pre-authorize specific clients only to use the network. I only do simple setup with DHCP Server and Hotspot Setup.
/interface list
add name=WAN
add name=LAN
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
/ip hotspot profile
set [ find default=yes ] hotspot-address=10.0.0.1 html-directory=cloudnet login-by=http-chap
/ip pool
add name=dhcp ranges=10.0.1.1-10.0.3.254
/ip dhcp-server
add address-pool=dhcp disabled=no interface=ether2 lease-time=1d name=tokyo-dhcp
/ip hotspot
add address-pool=dhcp disabled=no idle-timeout=30m interface=ether2 name=tokyo
/dude
set enabled=yes
/interface list member
add interface=ether1 list=WAN
add list=LAN
add interface=ether2 list=LAN
add interface=ether3 list=LAN
add interface=ether4 list=LAN
add interface=ether5 list=LAN
add interface=ether6 list=LAN
add interface=ether7 list=LAN
add interface=ether8 list=LAN
add interface=ether9 list=LAN
add interface=ether10 list=LAN
add interface=ether11 list=LAN
add interface=ether12 list=LAN
add interface=ether13 list=LAN
add list=LAN

/interface sstp-server server
set default-profile=default-encryption
/ip address
add address=10.0.0.1/20 comment=defconf interface=ether2 network=10.0.0.0
add address=192.168.1.2/24 interface=ether1 network=192.168.1.0
/ip cloud
set ddns-enabled=yes
/ip dhcp-client
add dhcp-options=hostname,clientid interface=ether1

/ip route
add distance=1 gateway=192.168.1.248

 
sindy
Forum Guru
Forum Guru
Posts: 3994
Joined: Mon Dec 04, 2017 9:19 pm

Re: Routing Problem

Sat Feb 17, 2018 11:37 am

I know I have to do some configuration at the Cisco side too, but I do not have access to that as it is controlled by Provider. Is there anything I could do, as to change Mikrotik and all clients default gateway? The problem now is I could browse 192.168.x.x from my new segment 10.0.x.x however not in vice versa. I also want 192.168.x.x to browse my new segment 10.0.x.x
When @acruhl wrote
Diagram it.
it was not just for fun.

So your description above partially substitutes the network diagram, but only partially.

I suppose that devices in 192.168.x.x get their addresses and network settings dynamically from the Cisco using DHCP, and that the Cisco indicates itself as the defult gateway and does not provide any routes to other networks in its DHCP responses. Consequently, the devices in 192.168.x.x send also packets for 10.0.0.0/20 to the Cisco (as it is their default gateway) and Cisco sends them further according to its own routing table and firewall settings, which most likely effectively means that it drops them as it belongs to the ISP so it should not forward any packets for private addresses through its WAN interface.

So to make packets from devices in 192.168.x.x reach devices in 10.0.0.0/20, you have to
  • either tell the Cisco to give these packets to Mikrotik (which brings another complication as it would be forwarding packets coming to its interface in 192.168.x.x to another device in 192.168.x.x which is a special case with a special treatment),
  • or provide all the devices in 192.168.x.x with a route to 10.0.0.0/20, indicating the Mikrotik's IP address as a gateway. You may be able to do that manually, or you may be able to do that using DHCP but it again requires access to settings of the Cisco, or you may be unable to do it at all if some of the devices in 192.168.x.x does not support any other route than the default one.
In either case above, you need to tell the Mikrotik that packets for 10.0.0.0/20 received through WAN must not be dropped, and that packets from 10.0.0.0/20 towards 192.168.x.x must not be src-nat'ed, otherwise the devices in 192.168.x.x would see responses to their requests sent to 10.0.0.0/20 coming from 192.168.1.2 which would confuse them.

That can be avoided by modifying your hotspot masquerade rule "chain=srcnat action=masquerade src-address=10.0.0.0/20" by adding "dst-address=!192.168.0.0/16" and removing the three duplicates of that rule you have there.

But suppressing the masquerade alone, i.e. without providing the route as described above, would only mean that even devices in 10.0.0.0/20 would not be able to contact devices in 192.168.0.0/16 any more.

So as you cannot affect the configuration of the Cisco, and as adding the route to 10.0.0.0/2 to each device in 192.168.1.0 is annoying or impossible, I would recommend you to create another 192.168.x.y subnet at the Mikrotik and move all the devices currently connected to 192.168.1.0/24 to that subnet, where the Mikrotik would be the default gateway and DHCP server, and do everything you need using the Mikrotik. This way, you would simply make your masquerade rules work only for packets routed out via WAN, and you would be able to define firewall rules between your two LANs (the new one and the hotspot one) if necessary. Without firewall rules, the two networks would see each other without any limitation. And the 192.168.1.0/24 would be there only to connect the Mikrotik to the Cisco.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
shin29
just joined
Topic Author
Posts: 15
Joined: Thu Feb 15, 2018 4:04 am

Re: Routing Problem

Mon Feb 19, 2018 4:11 am

I know I have to do some configuration at the Cisco side too, but I do not have access to that as it is controlled by Provider. Is there anything I could do, as to change Mikrotik and all clients default gateway? The problem now is I could browse 192.168.x.x from my new segment 10.0.x.x however not in vice versa. I also want 192.168.x.x to browse my new segment 10.0.x.x
When @acruhl wrote
Diagram it.
it was not just for fun.

So your description above partially substitutes the network diagram, but only partially.

I suppose that devices in 192.168.x.x get their addresses and network settings dynamically from the Cisco using DHCP, and that the Cisco indicates itself as the defult gateway and does not provide any routes to other networks in its DHCP responses. Consequently, the devices in 192.168.x.x send also packets for 10.0.0.0/20 to the Cisco (as it is their default gateway) and Cisco sends them further according to its own routing table and firewall settings, which most likely effectively means that it drops them as it belongs to the ISP so it should not forward any packets for private addresses through its WAN interface.

So to make packets from devices in 192.168.x.x reach devices in 10.0.0.0/20, you have to
  • either tell the Cisco to give these packets to Mikrotik (which brings another complication as it would be forwarding packets coming to its interface in 192.168.x.x to another device in 192.168.x.x which is a special case with a special treatment),
  • or provide all the devices in 192.168.x.x with a route to 10.0.0.0/20, indicating the Mikrotik's IP address as a gateway. You may be able to do that manually, or you may be able to do that using DHCP but it again requires access to settings of the Cisco, or you may be unable to do it at all if some of the devices in 192.168.x.x does not support any other route than the default one.
In either case above, you need to tell the Mikrotik that packets for 10.0.0.0/20 received through WAN must not be dropped, and that packets from 10.0.0.0/20 towards 192.168.x.x must not be src-nat'ed, otherwise the devices in 192.168.x.x would see responses to their requests sent to 10.0.0.0/20 coming from 192.168.1.2 which would confuse them.

That can be avoided by modifying your hotspot masquerade rule "chain=srcnat action=masquerade src-address=10.0.0.0/20" by adding "dst-address=!192.168.0.0/16" and removing the three duplicates of that rule you have there.

But suppressing the masquerade alone, i.e. without providing the route as described above, would only mean that even devices in 10.0.0.0/20 would not be able to contact devices in 192.168.0.0/16 any more.

So as you cannot affect the configuration of the Cisco, and as adding the route to 10.0.0.0/2 to each device in 192.168.1.0 is annoying or impossible, I would recommend you to create another 192.168.x.y subnet at the Mikrotik and move all the devices currently connected to 192.168.1.0/24 to that subnet, where the Mikrotik would be the default gateway and DHCP server, and do everything you need using the Mikrotik. This way, you would simply make your masquerade rules work only for packets routed out via WAN, and you would be able to define firewall rules between your two LANs (the new one and the hotspot one) if necessary. Without firewall rules, the two networks would see each other without any limitation. And the 192.168.1.0/24 would be there only to connect the Mikrotik to the Cisco.
I attach the diagram of the whole network. Please kindly comment if I have done anything wrong. The best way is to replace Cisco with Mikrotik but this needs negotiation with the ISP to do so.
You do not have the required permissions to view the files attached to this post.
 
sindy
Forum Guru
Forum Guru
Posts: 3994
Joined: Mon Dec 04, 2017 9:19 pm

Re: Routing Problem

Mon Feb 19, 2018 9:46 am

I attach the diagram of the whole network. Please kindly comment if I have done anything wrong. The best way is to replace Cisco with Mikrotik but this needs negotiation with the ISP to do so.
It's not about right or wrong, it's about not making people guess :-) The topology diagram shows clearly that my suggestion to move all other devices in 192.168.0.0/16 below Mikrotik doesn't make sense in your case because these devices are not only in the same subnet/network segment like Mikrotik's WAN interface but also in other subnets within 192.168.0.0/16 and routing is necessary between them.

I don't know how flexible ISPs are in Japan but I would expect them to be more open to configuring a static route for you or to enabling OSPF (which in brief allows to modify other routers' routing tables without need to have administrator access to them) than to replacing their router by your own one. I'd even assume that they do use OSPF between their three routers already as it requires less manual configuration on each of them - if so, it might be enough for them to permit it on the interface towards your Mikrotik and eventually give you the authentication credentials for it if they use them. You would then just remove the masquerade rule, disable some filter rules, and activate OSPF on the interface towards Cisco.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
tangram
Member Candidate
Member Candidate
Posts: 133
Joined: Wed Nov 16, 2016 9:55 pm

Re: Routing Problem

Mon Feb 19, 2018 9:58 am

If I understand correctly, cisco belongs to the ISP and you have no control over it. If so, why does it matter if you can't access 10.0.x.x or whatever you have behind mikrotik from cisco?
You just nat traffic over the link between mikrotik and cisco.
 
sindy
Forum Guru
Forum Guru
Posts: 3994
Joined: Mon Dec 04, 2017 9:19 pm

Re: Routing Problem

Mon Feb 19, 2018 10:06 am

You just nat traffic over the link between mikrotik and cisco.
That's what he currently does and obviously isn't happy about it. He's stated that he needs transparent routing between "legacy" and "new" parts of the network, and that doesn't work with the NAT in between the two.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
erlinden
Member Candidate
Member Candidate
Posts: 174
Joined: Wed Jun 12, 2013 1:59 pm

Re: Routing Problem

Mon Feb 19, 2018 10:49 am

What is de purpose of using a router in this case? If you want to create just one big network, configure one bridge on the MikroTik (reset without default) and you are done.
 
tangram
Member Candidate
Member Candidate
Posts: 133
Joined: Wed Nov 16, 2016 9:55 pm

Re: Routing Problem

Mon Feb 19, 2018 5:25 pm

You just nat traffic over the link between mikrotik and cisco.
That's what he currently does and obviously isn't happy about it. He's stated that he needs transparent routing between "legacy" and "new" parts of the network, and that doesn't work with the NAT in between the two.
A why this is an issue would be useful.
 
User avatar
CZFan
Forum Guru
Forum Guru
Posts: 1435
Joined: Sun Oct 09, 2016 8:25 pm
Location: South Africa, Randburg
Contact:

Re: Routing Problem

Mon Feb 19, 2018 6:22 pm

You just nat traffic over the link between mikrotik and cisco.
That's what he currently does and obviously isn't happy about it. He's stated that he needs transparent routing between "legacy" and "new" parts of the network, and that doesn't work with the NAT in between the two.
A why this is an issue would be useful.
Double NAT
MTCNA, MTCTCE, MTCRE & MTCINE
 
sindy
Forum Guru
Forum Guru
Posts: 3994
Joined: Mon Dec 04, 2017 9:19 pm

Re: Routing Problem

Mon Feb 19, 2018 6:28 pm

Double NAT
Nope, that's not the reason - the topic starts from a requirement to have a NAT-less access between old and new network. I haven't commented on @erlinden's and second @tangram's remark because only the OP can accept these sugestions or explain why they are not acceptable.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
User avatar
acruhl
Member
Member
Posts: 359
Joined: Fri Jul 03, 2015 7:22 pm

Re: Routing Problem

Mon Feb 19, 2018 6:48 pm

To the original post author:

I don't have much to add except the things labeled "WiFi router" are a problem. If they really are "routers", then they have networks other than 10.0.0.0/20 under them and you would need to route to clients under those as well, which you haven't mentioned yet.

If those are really access points, and I'm guessing they are, then label them correctly.

I know this could be a minor semantics issue, but that NEEDS to be right. If you don't understand the difference between a WiFi router and access point, then this routing issue isn't your only problem.
Stuff.
 
shin29
just joined
Topic Author
Posts: 15
Joined: Thu Feb 15, 2018 4:04 am

Re: Routing Problem

Tue Feb 20, 2018 2:56 am

To the original post author:

I don't have much to add except the things labeled "WiFi router" are a problem. If they really are "routers", then they have networks other than 10.0.0.0/20 under them and you would need to route to clients under those as well, which you haven't mentioned yet.

If those are really access points, and I'm guessing they are, then label them correctly.

I know this could be a minor semantics issue, but that NEEDS to be right. If you don't understand the difference between a WiFi router and access point, then this routing issue isn't your only problem.
"WiFi Router" does not run router functionality. Sorry for confusing you on this point. I use WiFi as a switch just to provide network to local computers. All traffic goes under WiFi will be controlled by Mikrotik with network 10.0.0.0/20. As have been discussing above, the problem is my computer is under 10.0.0.0/20 network and I could access to 192.168.0.0/16 without any problems. However, the computer (at different site) connecting using SmartVPN services, those are under 192.168.0.0/16. And the problem we have addressed above is the pc under 192.168.0.0/16 could not access to 10.0.0.0/20 networks. Do you have any suggestions?
 
shin29
just joined
Topic Author
Posts: 15
Joined: Thu Feb 15, 2018 4:04 am

Re: Routing Problem

Tue Feb 20, 2018 2:58 am

Double NAT
Nope, that's not the reason - the topic starts from a requirement to have a NAT-less access between old and new network. I haven't commented on @erlinden's and second @tangram's remark because only the OP can accept these sugestions or explain why they are not acceptable.
To make it clear on the problem I have addressed earlier is that I need both network 192.168.0.0 and 10.0.0.0 accessible to each other. With my current configuration, I could only access to 192.168.0.0 if I am under 10.0.0.0 network; however, I could not do a reverse in this case. My other clients pc are under 192.168.0.0 (majority pcs) and they could not connect to my 10.0.0.0 network.
 
shin29
just joined
Topic Author
Posts: 15
Joined: Thu Feb 15, 2018 4:04 am

Re: Routing Problem

Tue Feb 20, 2018 3:02 am

What is de purpose of using a router in this case? If you want to create just one big network, configure one bridge on the MikroTik (reset without default) and you are done.
Network from cisco router 192.168.0.0 does not provide authentication system. I need to pre-authenticate my client pcs when they are connected to the network. That is why I use Mikrotik as hotspot server to register MAC Address of all clients when they connect to network. Apparently, I could not build the same 192.168.0.0 under Mikrotik that is why I have different network.
 
shin29
just joined
Topic Author
Posts: 15
Joined: Thu Feb 15, 2018 4:04 am

Re: Routing Problem

Tue Feb 20, 2018 3:07 am

I post an update of the diagram.
You do not have the required permissions to view the files attached to this post.
 
User avatar
acruhl
Member
Member
Posts: 359
Joined: Fri Jul 03, 2015 7:22 pm

Re: Routing Problem

Tue Feb 20, 2018 7:11 am

So the question remains, have you put in a static route to the 10.x.x.x network on all of the Ciscos? I think you'll get ICMP redirects on all packets destined for the non gateway addresses in the 192.168 network (the ISP cloud you have drawn) if you use a default route in the 192.168 network. I don't remember off hand what to do in that case.

Also, why do you have masquerade rules going in both directions? I'm not sure what that is doing. You can't do NAT and expect routing in both directions to work.
Stuff.
 
sindy
Forum Guru
Forum Guru
Posts: 3994
Joined: Mon Dec 04, 2017 9:19 pm

Re: Routing Problem

Tue Feb 20, 2018 8:59 am

I need to pre-authenticate my client pcs when they are connected to the network. That is why I use Mikrotik as hotspot server to register MAC Address of all clients when they connect to network.
@shin29, given these reasons, maybe you could adopt @erlinden's suggestion to use Mikrotik only as a clever switch?

To do so, some prerequisites would have to be fulfilled:
  • there would have to be a sufficient capacity in the subnet 192.168.1.0/24 and in the DHCP pool inside that subnet, provided by the Cisco nearest to the Mikrotik, as the wireless clients would receive IP addresses from the Cisco's DHCP server.
  • instead of using the hotspot functionality, you would have to do the "authentication by MAC address" merely by permitting access to the Cisco only to whitelisted MAC addresses. You could use bridge filtering for that, or you could use wireless access list if your wireless APs are Mikrotik ones and thus you can control them by a cAPsMAN running at this Mikrotik. In this second case, you could even link an individual WPA passphrase to each client (based on client's MAC address) without need to use an external EAP authentication service.
Hotspot is normally used to control unknown-in-advance devices (in hotels and other public access areas), but in such cases there is normally no need to access these devices' IP addresses from outside so it doesn't matter that there is a NAT between these addresses and the rest of the network. So if you can bear the discomfort of maintaining a list of permitted MAC addresses on the Mikrotik manually, this could be an option.

You could even address the issue that IP adresses of the wireless clients would not be known in advance because you cannot affect the rules used by the Cisco's DHCP server. With a slightly wilder configuration of the Mikrotik, and if there is enough space in the subnet between the Cisco and the Mikrotik which is not part of the DHCP pool provided by the Cisco, you could even set up your own DHCP server on the Mikrotik, with its own non-overlapping pool within the same subnet, so you could assign static IP addresses to your wireless clients, based on their MAC addresses. To do so, you would have to prevent DHCP requests from passing between the Cisco and the Mikrotik, again by means of a bridge filter, so that the two DHCP servers would each only receive requests from clients at its respective end of the Cisco-Mikrotik connection.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
tangram
Member Candidate
Member Candidate
Posts: 133
Joined: Wed Nov 16, 2016 9:55 pm

Re: Routing Problem

Tue Feb 20, 2018 1:16 pm

However, the computer (at different site) connecting using SmartVPN services, those are under 192.168.0.0/16.
Replace smartvpn with l2tp or something else and connect them to mikrotik ? or move smartvpn behind mikrotik ?
 
shin29
just joined
Topic Author
Posts: 15
Joined: Thu Feb 15, 2018 4:04 am

Re: Routing Problem

Wed Feb 21, 2018 3:27 am

So the question remains, have you put in a static route to the 10.x.x.x network on all of the Ciscos? I think you'll get ICMP redirects on all packets destined for the non gateway addresses in the 192.168 network (the ISP cloud you have drawn) if you use a default route in the 192.168 network. I don't remember off hand what to do in that case.

Also, why do you have masquerade rules going in both directions? I'm not sure what that is doing. You can't do NAT and expect routing in both directions to work.
because I do not have access to the Cisco router. ISP do everything and they wont let us touch it. We could only request them to add this or that (rules/routing) to the Cisco once we are sure that its the right thing to do. And that we will have to pay each time we request them to do so. Or unless I pull out the Cisco router and connect Mikrotik as the main router.
 
shin29
just joined
Topic Author
Posts: 15
Joined: Thu Feb 15, 2018 4:04 am

Re: Routing Problem

Wed Feb 21, 2018 3:29 am

What is de purpose of using a router in this case? If you want to create just one big network, configure one bridge on the MikroTik (reset without default) and you are done.
@erlinden
What do you mean by configure one bridge on the Mikrotik (reset without default)??? Could you elaborate more on this.
 
shin29
just joined
Topic Author
Posts: 15
Joined: Thu Feb 15, 2018 4:04 am

Re: Routing Problem

Wed Feb 21, 2018 3:38 am

I need to pre-authenticate my client pcs when they are connected to the network. That is why I use Mikrotik as hotspot server to register MAC Address of all clients when they connect to network.
@shin29, given these reasons, maybe you could adopt @erlinden's suggestion to use Mikrotik only as a clever switch?

To do so, some prerequisites would have to be fulfilled:
  • there would have to be a sufficient capacity in the subnet 192.168.1.0/24 and in the DHCP pool inside that subnet, provided by the Cisco nearest to the Mikrotik, as the wireless clients would receive IP addresses from the Cisco's DHCP server.
  • instead of using the hotspot functionality, you would have to do the "authentication by MAC address" merely by permitting access to the Cisco only to whitelisted MAC addresses. You could use bridge filtering for that, or you could use wireless access list if your wireless APs are Mikrotik ones and thus you can control them by a cAPsMAN running at this Mikrotik. In this second case, you could even link an individual WPA passphrase to each client (based on client's MAC address) without need to use an external EAP authentication service.
Hotspot is normally used to control unknown-in-advance devices (in hotels and other public access areas), but in such cases there is normally no need to access these devices' IP addresses from outside so it doesn't matter that there is a NAT between these addresses and the rest of the network. So if you can bear the discomfort of maintaining a list of permitted MAC addresses on the Mikrotik manually, this could be an option.

You could even address the issue that IP adresses of the wireless clients would not be known in advance because you cannot affect the rules used by the Cisco's DHCP server. With a slightly wilder configuration of the Mikrotik, and if there is enough space in the subnet between the Cisco and the Mikrotik which is not part of the DHCP pool provided by the Cisco, you could even set up your own DHCP server on the Mikrotik, with its own non-overlapping pool within the same subnet, so you could assign static IP addresses to your wireless clients, based on their MAC addresses. To do so, you would have to prevent DHCP requests from passing between the Cisco and the Mikrotik, again by means of a bridge filter, so that the two DHCP servers would each only receive requests from clients at its respective end of the Cisco-Mikrotik connection.


[*]there would have to be a sufficient capacity in the subnet 192.168.1.0/24 and in the DHCP pool inside that subnet, provided by the Cisco nearest to the Mikrotik, as the wireless clients would receive IP addresses from the Cisco's DHCP server.
→192.168.1.0/24 in Cisco is initially DHCP Server. My main purpose of this is just to pre-authenticate my clients with MAC address when they connect to the network. Since I do not have access to the Cisco (Controlled by ISP), that is why I chose Mikrotik to authenticate my client PCs. I would want to preserve the existing 192.168.1.0/24 in this case (under Mikrotik authentication); however I do not find any solution to do that. I think it is not possible to do that isnt it? I gave Mikrotik 192.168.1.2 because Mikrotik connects to Cisco.

[*]instead of using the hotspot functionality, you would have to do the "authentication by MAC address" merely by permitting access to the Cisco only to whitelisted MAC addresses. You could use bridge filtering for that, or you could use wireless access list if your wireless APs are Mikrotik ones and thus you can control them by a cAPsMAN running at this Mikrotik. In this second case, you could even link an individual WPA passphrase to each client (based on client's MAC address) without need to use an external EAP authentication service.
→I only know how to authenticate MAC Address using hotspot functionality. Could you guide me on how to do "authentication by MAC address"? I want to do that on Mikrotik because I do not have access to the Cisco router. I cannot change any configuration inside Cisco. My wireless APs are connected through Mikrotik, how could I use wireless access list in this case?
 
sindy
Forum Guru
Forum Guru
Posts: 3994
Joined: Mon Dec 04, 2017 9:19 pm

Re: Routing Problem

Wed Feb 21, 2018 3:14 pm

→ 192.168.1.0/24 in Cisco is initially DHCP Server. My main purpose of this is just to pre-authenticate my clients with MAC address when they connect to the network. Since I do not have access to the Cisco (Controlled by ISP), that is why I chose Mikrotik to authenticate my client PCs. I would want to preserve the existing 192.168.1.0/24 in this case (under Mikrotik authentication); however I do not find any solution to do that. I think it is not possible to do that isnt it? I gave Mikrotik 192.168.1.2 because Mikrotik connects to Cisco.
As I wrote - if you use Mikrotik as a bridge only, you can configure a MAC address filter inside it, which will not let through to the Cisco any packets from other than white-listed MAC addresses. It is not an authentication as such but it prevents anyone just walking by from connecting - even if he would know the wireless passphrase. With Mikrotik as a MAC-filtering bridge, all the rest (DHCP, routing) is done by the Cisco, and wireless authentication is done by the APs using a common passphrase for all clients unless the APs are Mikrotik ones as well. If they are, you have more options, see below.

To set up the bridge as MAC address filter, you would have to go to Bridge->Filters menu and set "accept" rules there for permitted MAC addresses and after all of them a single unconditional "drop" rule, all of that in "forward" chain.

If that is more acceptable for you than talking to the ISP and asking them to activate OSPF, say so, I won't spend time describing details unless you confirm you want to go that way.

→I only know how to authenticate MAC Address using hotspot functionality. Could you guide me on how to do "authentication by MAC address"? I want to do that on Mikrotik because I do not have access to the Cisco router. I cannot change any configuration inside Cisco. My wireless APs are connected through Mikrotik, how could I use wireless access list in this case?
Wireless access list only works if the APs are Mikrotik ones. In such case, you can centralize configuration of wireless interfaces of several Mikrotiks on one of them using cAPsMAN, and you can use a set of rules to manage client's behaviour - permit only chosen MAC addresses, define individual passphrases for WPA for them, define signal level thresholds for force-disconnecting clients so that they could connect to an AP with better signal etc.

It should also be possible to use 1:1 NAT rules, where your wireless clients would get addresses like e.g. 10.0.1.x and they would be seen from outside as 192.168.1.x. But if there are any other devices in the subnet to which the uplink interface of your Mikrotik is connected, you would still have to make the ISP dedicate part of that subnet to this task and limit the DHCP pool of the Cisco so that it would not assign some addresses and thus make them available for your use. So e.g. the range 192.168.1.150 to 192.168.1.250 would be dedicated for this purpose, and the wireless clients would get addresses 10.0.1.150 to 10.0.1.250 and be routable from outside as 192.168.1.150 to 192.168.1.250.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
shin29
just joined
Topic Author
Posts: 15
Joined: Thu Feb 15, 2018 4:04 am

Re: Routing Problem

Tue Feb 27, 2018 1:59 am

→ 192.168.1.0/24 in Cisco is initially DHCP Server. My main purpose of this is just to pre-authenticate my clients with MAC address when they connect to the network. Since I do not have access to the Cisco (Controlled by ISP), that is why I chose Mikrotik to authenticate my client PCs. I would want to preserve the existing 192.168.1.0/24 in this case (under Mikrotik authentication); however I do not find any solution to do that. I think it is not possible to do that isnt it? I gave Mikrotik 192.168.1.2 because Mikrotik connects to Cisco.
As I wrote - if you use Mikrotik as a bridge only, you can configure a MAC address filter inside it, which will not let through to the Cisco any packets from other than white-listed MAC addresses. It is not an authentication as such but it prevents anyone just walking by from connecting - even if he would know the wireless passphrase. With Mikrotik as a MAC-filtering bridge, all the rest (DHCP, routing) is done by the Cisco, and wireless authentication is done by the APs using a common passphrase for all clients unless the APs are Mikrotik ones as well. If they are, you have more options, see below.

To set up the bridge as MAC address filter, you would have to go to Bridge->Filters menu and set "accept" rules there for permitted MAC addresses and after all of them a single unconditional "drop" rule, all of that in "forward" chain.

If that is more acceptable for you than talking to the ISP and asking them to activate OSPF, say so, I won't spend time describing details unless you confirm you want to go that way.

→I only know how to authenticate MAC Address using hotspot functionality. Could you guide me on how to do "authentication by MAC address"? I want to do that on Mikrotik because I do not have access to the Cisco router. I cannot change any configuration inside Cisco. My wireless APs are connected through Mikrotik, how could I use wireless access list in this case?
Wireless access list only works if the APs are Mikrotik ones. In such case, you can centralize configuration of wireless interfaces of several Mikrotiks on one of them using cAPsMAN, and you can use a set of rules to manage client's behaviour - permit only chosen MAC addresses, define individual passphrases for WPA for them, define signal level thresholds for force-disconnecting clients so that they could connect to an AP with better signal etc.

It should also be possible to use 1:1 NAT rules, where your wireless clients would get addresses like e.g. 10.0.1.x and they would be seen from outside as 192.168.1.x. But if there are any other devices in the subnet to which the uplink interface of your Mikrotik is connected, you would still have to make the ISP dedicate part of that subnet to this task and limit the DHCP pool of the Cisco so that it would not assign some addresses and thus make them available for your use. So e.g. the range 192.168.1.150 to 192.168.1.250 would be dedicated for this purpose, and the wireless clients would get addresses 10.0.1.150 to 10.0.1.250 and be routable from outside as 192.168.1.150 to 192.168.1.250.
Thank you for your detailed explanation. I think I will eliminate 10.0.X.X and use Mikrotik as a bridge. Maybe that would be the best solution for this as cisco will still be DHCP giving 192.168.1.X and Mikrotik controls all the APs with MAC Filtering.
 
Mantic0re
just joined
Posts: 3
Joined: Tue Oct 25, 2016 7:27 pm

Re: Routing Problem

Thu Mar 01, 2018 12:20 pm

Problems with accessing IP-address 192.168.1.1 can vary, and sometimes are caused by the modem itself, and/or by browser settings. I used one guide with helpful instructions. It quickly resolved the problem with access. It should help you too.
 
shin29
just joined
Topic Author
Posts: 15
Joined: Thu Feb 15, 2018 4:04 am

Re: Routing Problem

Thu Mar 01, 2018 4:09 pm

→ 192.168.1.0/24 in Cisco is initially DHCP Server. My main purpose of this is just to pre-authenticate my clients with MAC address when they connect to the network. Since I do not have access to the Cisco (Controlled by ISP), that is why I chose Mikrotik to authenticate my client PCs. I would want to preserve the existing 192.168.1.0/24 in this case (under Mikrotik authentication); however I do not find any solution to do that. I think it is not possible to do that isnt it? I gave Mikrotik 192.168.1.2 because Mikrotik connects to Cisco.
As I wrote - if you use Mikrotik as a bridge only, you can configure a MAC address filter inside it, which will not let through to the Cisco any packets from other than white-listed MAC addresses. It is not an authentication as such but it prevents anyone just walking by from connecting - even if he would know the wireless passphrase. With Mikrotik as a MAC-filtering bridge, all the rest (DHCP, routing) is done by the Cisco, and wireless authentication is done by the APs using a common passphrase for all clients unless the APs are Mikrotik ones as well. If they are, you have more options, see below.

To set up the bridge as MAC address filter, you would have to go to Bridge->Filters menu and set "accept" rules there for permitted MAC addresses and after all of them a single unconditional "drop" rule, all of that in "forward" chain.

If that is more acceptable for you than talking to the ISP and asking them to activate OSPF, say so, I won't spend time describing details unless you confirm you want to go that way.

→I only know how to authenticate MAC Address using hotspot functionality. Could you guide me on how to do "authentication by MAC address"? I want to do that on Mikrotik because I do not have access to the Cisco router. I cannot change any configuration inside Cisco. My wireless APs are connected through Mikrotik, how could I use wireless access list in this case?
Wireless access list only works if the APs are Mikrotik ones. In such case, you can centralize configuration of wireless interfaces of several Mikrotiks on one of them using cAPsMAN, and you can use a set of rules to manage client's behaviour - permit only chosen MAC addresses, define individual passphrases for WPA for them, define signal level thresholds for force-disconnecting clients so that they could connect to an AP with better signal etc.

It should also be possible to use 1:1 NAT rules, where your wireless clients would get addresses like e.g. 10.0.1.x and they would be seen from outside as 192.168.1.x. But if there are any other devices in the subnet to which the uplink interface of your Mikrotik is connected, you would still have to make the ISP dedicate part of that subnet to this task and limit the DHCP pool of the Cisco so that it would not assign some addresses and thus make them available for your use. So e.g. the range 192.168.1.150 to 192.168.1.250 would be dedicated for this purpose, and the wireless clients would get addresses 10.0.1.150 to 10.0.1.250 and be routable from outside as 192.168.1.150 to 192.168.1.250.

/interface bridge
add name=bridge
/interface list
add name=WAN
add name=LAN
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
/ip hotspot profile
set [ find default=yes ] hotspot-address=10.0.0.1 html-directory=cloudnet login-by=http-chap
/ip pool
add name=dhcp ranges=10.0.1.1-10.0.3.254
/ip dhcp-server
add address-pool=dhcp interface=ether2 lease-time=1d name=tokyo-dhcp
/ip hotspot
add address-pool=dhcp idle-timeout=30m interface=ether2 name=tokyo
/dude
set enabled=yes
/interface bridge filter
add action=accept chain=forward dst-mac-address=70:EF:00:89:17:AB/FF:FF:FF:FF:FF:FF mac-protocol=ip out-interface=ether2 \
    src-mac-address=70:EF:00:89:17:AB/FF:FF:FF:FF:FF:FF
add action=accept chain=forward dst-mac-address=34:08:BC:B7:25:A7/FF:FF:FF:FF:FF:FF mac-protocol=ip out-interface=ether2 \
    src-mac-address=34:08:BC:B7:25:A7/FF:FF:FF:FF:FF:FF
add action=accept chain=forward comment="Allow All ARP" mac-protocol=arp
add action=drop chain=forward comment="Drop All Other Addresses" mac-protocol=ip out-interface=ether2
/interface bridge port
add bridge=bridge interface=ether2
add bridge=bridge disabled=yes interface=ether3
add bridge=bridge disabled=yes interface=ether4
add bridge=bridge disabled=yes interface=ether5
add bridge=bridge disabled=yes interface=ether6
add bridge=bridge disabled=yes interface=ether7
add bridge=bridge disabled=yes interface=ether8
add bridge=bridge disabled=yes interface=ether9
add bridge=bridge disabled=yes interface=ether10
add bridge=bridge disabled=yes interface=ether11
add bridge=bridge disabled=yes interface=ether12
add bridge=bridge disabled=yes interface=ether13
add bridge=bridge interface=ether1
Can you advise if I am doing something wrong? I do bridge for all ethernet connection. My access points are connecting through port ether2 and I want to do mac address filtering for this port. How could I do that? I am writing filter accepts only listed mac address and the rest drop all connections. But to no avail, it doesnt work. Do I need to set arp to read-only? I tried that too but it does not work.
 
sindy
Forum Guru
Forum Guru
Posts: 3994
Joined: Mon Dec 04, 2017 9:19 pm

Re: Routing Problem

Thu Mar 01, 2018 10:42 pm

/interface bridge filter
add action=accept chain=forward dst-mac-address=70:EF:00:89:17:AB/FF:FF:FF:FF:FF:FF mac-protocol=ip out-interface=ether2 \
    src-mac-address=70:EF:00:89:17:AB/FF:FF:FF:FF:FF:FF
add action=accept chain=forward dst-mac-address=34:08:BC:B7:25:A7/FF:FF:FF:FF:FF:FF mac-protocol=ip out-interface=ether2 \
    src-mac-address=34:08:BC:B7:25:A7/FF:FF:FF:FF:FF:FF
add action=accept chain=forward comment="Allow All ARP" mac-protocol=arp
add action=drop chain=forward comment="Drop All Other Addresses" mac-protocol=ip out-interface=ether2
Can you advise if I am doing something wrong?
Unfortunately, yes. All firewall rules, including the bridge ones, consist of several types of configuration items:
  • a single item configuring the name of the chain to which the rule belongs
  • a single item configuring the action to be taken
  • a variable number of match conditions for various packet or frame properties and their values
  • for some actions, a variable number of new values of packet/frame properties to be set
All the match conditions must be met simultaneously (i.e. there is a logical AND between all of them) in order to make the whole rule match and the action be taken; only where a list of values is given for a condition, the packet property to which the condition refers may match any of the values on the list (you can expand such conditions, like "property_x=a,b" into a logical OR separated list of comparisons to individual vaues, i.e. "property_x=a OR property_x=b"). But only a few packet properties can be matched against a list or range.

So your rules above would only match on frames sent from an inicated MAC address to the very same MAC address which does not happen. Instead, you need the following rules:
/interface bridge filter
add action=accept chain=forward in-interface=ether2 src-mac-address=70:EF:00:89:17:AB/FF:FF:FF:FF:FF:FF
add action=accept chain=forward in-interface=ether2 src-mac-address=34:08:BC:B7:25:A7/FF:FF:FF:FF:FF:FF
add action=drop chain=forward comment="Drop All Other Addresses" in-interface=ether2
These only take care about one direction (from the clients, i.e. from the APs connected to ether2) and do not discriminate between protocols, but that's sufficient because only the two listed clients will get IP address etc., the rest will be cut completely, so there is no need to create mirror rules for the opposite direction.

If you eventually decide to set MAC filtering rules for the opposite direction, it is important to permit also broadcast and multicast addresses, i.e. "dst-mac-address=01:00:00:00:00:00/01:00:00:00:00:00". These will never occur as source addresses so there is no need to add the exception for them to the rules above.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
shin29
just joined
Topic Author
Posts: 15
Joined: Thu Feb 15, 2018 4:04 am

Re: Routing Problem

Fri Mar 02, 2018 2:11 am

/interface bridge filter
add action=accept chain=forward in-interface=ether2 src-mac-address=70:EF:00:89:17:AB/FF:FF:FF:FF:FF:FF
add action=accept chain=forward in-interface=ether2 src-mac-address=34:08:BC:B7:25:A7/FF:FF:FF:FF:FF:FF
add action=drop chain=forward comment="Drop All Other Addresses" in-interface=ether2
By following the above filter rules, do you mean that I will be able to filters only two clients to be connected to my AP through ether2 (ether2 is the port in Mikrotik). I connect ether1 to my cisco router and run Mikrotik as a bridge so Cisco router will be DHCP server and thus provide my clients PC dynamic IP address. However, I do not want other unknown clients to connect to my network, that is why I make filter rules to accept only the clients with src-mac-address mentioned in the filter. I have tried this, but it was not successful.

Does it mean that the filter has to be in order too? Because when I "add action=drop chain=forward comment="Drop All Other Addresses" in-interface=ether2", the rest of filter seems not work and none of my clients including those two clients could not be connected to the network. I understand that I may have to put the rules in the order so I put action=drop at the very end, but it still doesnt work as I expected.
 
sindy
Forum Guru
Forum Guru
Posts: 3994
Joined: Mon Dec 04, 2017 9:19 pm

Re: Routing Problem

Fri Mar 02, 2018 10:20 am

By following the above filter rules, do you mean that I will be able to filters only two clients to be connected to my AP through ether2 (ether2 is the port in Mikrotik). I connect ether1 to my cisco router and run Mikrotik as a bridge so Cisco router will be DHCP server and thus provide my clients PC dynamic IP address. However, I do not want other unknown clients to connect to my network, that is why I make filter rules to accept only the clients with src-mac-address mentioned in the filter. I have tried this, but it was not successful.
Yes, this is what my rules should do. Only the MAC addresses which have their "own" rules should be able to access the network. Others will authorize to the access points but will not get IP address from the Cisco.

Does it mean that the filter has to be in order too? Because when I "add action=drop chain=forward comment="Drop All Other Addresses" in-interface=ether2", the rest of filter seems not work and none of my clients including those two clients could not be connected to the network. I understand that I may have to put the rules in the order so I put action=drop at the very end, but it still doesnt work as I expected.
Yes, each packet is matched against the rules from top to bottom until one of them matches the packet and provides a final verdict - in your case, accept or drop. So if you've put the drop rule to the end of the list and no device connected to the APs can connect to the network, it means that none of the previous rules has matched the packets from it.

The most likely explanation is that the MAC addresses are wrong. How have you identified those two addresses to put into the rules?

I would recommend you to temporarily put a rule before the first one:
/interface bridge filter add action=log chain=forward in-interface=ether2 log-prefix=b-filter
Then, activate your wireless device and then see the log, it should be full of messages which tell you the actual MAC from which the various devices try to get in, so make sure that no other wireless devices than those you test hang around when you do the test.

You may place here the output of
/log print where message~"b-filter"
if there is still an issue.

Just don't forget to disable the logging rule as soon as you have collected enough information, as it fills the log with information which is not necessary for normal operation so other messages get overwritten quickly.

And one very important point - the "hw" parameter must be set to "no" for ether2 when making it a member of the bridge, otherwise the switch chip forwards the frames between ether2 and ether1 directly and the firewall rules are not inspected. I assume that this is the case as your drop rule does have effect, but I mention it just for the case.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.

Who is online

Users browsing this forum: MSN [Bot] and 128 guests