Hello!
I have a problem here because I need to make an device -who is 192.168.0.51 on my network- only drive out to web via my second link at ether2 who is linked to PPPoE dialer.
What do I do to make sure that this local address always work through this specific link?
Tnkx.
Re: FROM/TO
I tried to digest that link and got a rash.
Isn't this the simplest logical approach (see below )??
Obviously not otherwise it would have been suggested but where do I go wrong????
/ip firewall nat
add chain=srcnat out-interface=ether2 action=masquerade (to ensure private IP traffic going out ether2 gets sent back to the proper private IP)
/ip firewall mangle
add chain=prerouting in-interface=LAN {or specific ether interface} src-address=192.168.0.51 mark=no-mark {extra tab} dst-address-type= ! local {to ensure one does not mark lan to lan traffic)
mark-connection new-connection-mark=singleUser passthrough=yes
add chain=prerouting in-interface=LAN src-address=192.168.0.51 connection-mark=singleUser routing-mark new-routing-mark=ControlUser passthrough=no
/ip route
add dst-address=0.0.0.0/0 gatewayIP of ISP2 routing-mark=ControlUser
Isn't this the simplest logical approach (see below )??
Obviously not otherwise it would have been suggested but where do I go wrong????
/ip firewall nat
add chain=srcnat out-interface=ether2 action=masquerade (to ensure private IP traffic going out ether2 gets sent back to the proper private IP)
/ip firewall mangle
add chain=prerouting in-interface=LAN {or specific ether interface} src-address=192.168.0.51 mark=no-mark {extra tab} dst-address-type= ! local {to ensure one does not mark lan to lan traffic)
mark-connection new-connection-mark=singleUser passthrough=yes
add chain=prerouting in-interface=LAN src-address=192.168.0.51 connection-mark=singleUser routing-mark new-routing-mark=ControlUser passthrough=no
/ip route
add dst-address=0.0.0.0/0 gatewayIP of ISP2 routing-mark=ControlUser
Re: FROM/TO
What you've suggested is basically the same what I wrote at that link, simplfied for a specific case, with a minor issue that mark=no-mark should have read connection-mark=no-mark and a major issue that dst-address-type=local actually does not match on all addresses from subnets of which the Mikrotik is a member but solely on Mikrotik's own addresses in these subnets. So dst-address-type=local will never match in forward chain. But that seems to be yet another common misunderstanding, you're not alone to get trapped.
Another part of that post deals with the fact that fasttracking breaks routing-marking, so if you need to use policy routing on weak hardware which doesn't deal with the summary load without fasttracking, you need to take the more complex measures explained there.
And it's true that if only a single IP address needs to be handled specially, it is simpler to create the default route via the required gateway with a routing-mark and use an /ip route rule to tell the routing to use that routing-mark (routing table) for packets with src-address matching the one which needs the special treatment:
But the OP has stated that use of a particular WAN for a particular LAN IP is an exception, so I assume he's got some failover setup in place, so the ip route rule approach may not fit well to that setup.
Another part of that post deals with the fact that fasttracking breaks routing-marking, so if you need to use policy routing on weak hardware which doesn't deal with the summary load without fasttracking, you need to take the more complex measures explained there.
And it's true that if only a single IP address needs to be handled specially, it is simpler to create the default route via the required gateway with a routing-mark and use an /ip route rule to tell the routing to use that routing-mark (routing table) for packets with src-address matching the one which needs the special treatment:
Code: Select all
/ip route
add dst-address=0.0.0.0/0 gateway=the-desired-gateway routing-mark=VIP
/ip route rule
add src-address=the.VIP.ip.address action=lookup-only-in-table table=VIPRe: FROM/TO
Ahh Sindy, the master of obfuscation strikes again..............
Where is master Yoda (sob) when you need the creature!!
My bad about exacto lingo on the no marko of the connectiono, but it was very very minor, hardly worth mentioning and not a problem if using winbox and only a problem if trying to copy verbatim in terminal........................ I figure if someone is using terminal they have a drop of acumen................
But where we shall enter combat is my use of the EXTRA tab.
I did not select destination-address-list = local
I selected destination-address-list= NOT local or in the vernacular !local
So in other words what I was trying to state in plain english............. mark connections coming from the incoming interface (lan or etherport) with IP address of so and so, not previously marked and going everywhere except LOCAL. In other words a cute way of saying dont mark lan to lan traffic mark lan to wan traffic).
I wouldnt make too many assumptions only that he probably has other route rules in place (without the marking) for all other users.
dst=0.0.0.0/0 gatewayIP of ISP2 distance=X
dst=0.0.0.0/0 gatewayIP of ISP1 distance=Y ping gateway
Where is master Yoda (sob) when you need the creature!!
My bad about exacto lingo on the no marko of the connectiono, but it was very very minor, hardly worth mentioning and not a problem if using winbox and only a problem if trying to copy verbatim in terminal........................ I figure if someone is using terminal they have a drop of acumen................
But where we shall enter combat is my use of the EXTRA tab.
I did not select destination-address-list = local
I selected destination-address-list= NOT local or in the vernacular !local
So in other words what I was trying to state in plain english............. mark connections coming from the incoming interface (lan or etherport) with IP address of so and so, not previously marked and going everywhere except LOCAL. In other words a cute way of saying dont mark lan to lan traffic mark lan to wan traffic).
I wouldnt make too many assumptions only that he probably has other route rules in place (without the marking) for all other users.
dst=0.0.0.0/0 gatewayIP of ISP2 distance=X
dst=0.0.0.0/0 gatewayIP of ISP1 distance=Y ping gateway
Re: FROM/TO
Are you telling me my posts are not clear? If so, can you explain why? Others may feel the same but hesitate to raise a claimAhh Sindy, the master of obfuscation strikes again..............
I dare to disagree as it could have been connection-mark, routing-mark, or packet-mark, so if the reader doesn't know about the existence of all three, it is easy to choose the wrong one.not a problem if using winbox and only a problem if trying to copy verbatim in terminal
I did understand the intention, but I maintain my position - local only represents Mikrotik's own addresses. So matching the marking rule on dst-address=!local actually does not prevent LAN to LAN packets from getting marked. (NB - if there is only one LAN subnet on the Mikrotik, the firewall normally doesn't see any packets from one LAN device to another as they are delivered at L2, not routed by the Mikrotik).I did not select destination-address-list = local
I selected destination-address-list= NOT local or in the vernacular !local
So in other words what I was trying to state in plain english............. mark connections coming from the incoming interface (lan or etherport) with IP address of so and so, not previously marked and going everywhere except LOCAL. In other words a cute way of saying dont mark lan to lan traffic mark lan to wan traffic).
Re: FROM/TO
I take your point on the connection mark accuracy,
however on the latter point, as far as I can tell there is only one device the mikrotik to worry about.
Lets look at a scenario.......
User ZZ
Lans A,B on Bridge (eth3,4
Lans C, D on Brigde TWO (eth5,6)
Lan E on eth7
Lan F on eth8
WANS on eth1 and eth2
So when I put !local in my rule what does it mean.........................
Case 1: User ZZ is on Brigde1 (LAN A)
Case 2: User ZZ is on LANF
If I mark packets coming from the appropriate interface with source IP address of user ZZ and EXTRA TAB dest-address-list=!local
please tell me which lan to lan traffic from user ZZ will get marked in
Case 1??
Case 2??
I have assumed that local means all subnets and vlans on the mikrotik???
however on the latter point, as far as I can tell there is only one device the mikrotik to worry about.
Lets look at a scenario.......
User ZZ
Lans A,B on Bridge (eth3,4
Lans C, D on Brigde TWO (eth5,6)
Lan E on eth7
Lan F on eth8
WANS on eth1 and eth2
So when I put !local in my rule what does it mean.........................
Case 1: User ZZ is on Brigde1 (LAN A)
Case 2: User ZZ is on LANF
If I mark packets coming from the appropriate interface with source IP address of user ZZ and EXTRA TAB dest-address-list=!local
please tell me which lan to lan traffic from user ZZ will get marked in
Case 1??
Case 2??
I have assumed that local means all subnets and vlans on the mikrotik???
Re: FROM/TO
Traffic from ZZ to any LAN subnet other than the one where ZZ is a member will be marked. The traffic from ZZ to his own LAN will not get marked only because it will not go through the firewall at all.as far as I can tell there is only one device the mikrotik to worry about.
Lets look at a scenario.......
User ZZ
Lans A,B on Bridge (eth3,4
Lans C, D on Brigde TWO (eth5,6)
Lan E on eth7
Lan F on eth8
WANS on eth1 and eth2
So when I put !local in my rule what does it mean.........................
Case 1: User ZZ is on Brigde1 (LAN A)
Case 2: User ZZ is on LANF
If I mark packets coming from the appropriate interface with source IP address of user ZZ and EXTRA TAB dest-address-list=!local
please tell me which lan to lan traffic from user ZZ will get marked in
Case 1??
Case 2??
As an ability to refer to all local subnets automatically looks very useful, before posting the above, I've tested how the local value actually behaves although the statement regarding its meaning in the documentation is clear. And it really only matches on Mikrotik's own addresses. So to match on all local subnets, you have to use an address-list.I have assumed that local means all subnets and vlans on the mikrotik???
Re: FROM/TO
Wow Sindy, this is huge!!
You are blowing my mind
Lets recap with my !local rule in place and assuming LAN to LAN traffic origination from the user
User ZZ
Lans A,B on Bridge (eth3,4
Lans C, D on Brigde TWO (eth5,6)
Lan E on eth7
Lan F on eth8
WANS on eth1 and eth2
Discussion: User ZZ is on LAN A
a. traffic to other in LANA will not be marked due to being in same subnet layer 2 no firewall)
b. traffic to LANB will not be marked due to being on same bridge (in effect also layer 2, FW rules will not apply)
c. traffic to LANS C and D will be marked (which negates my rule
)
d. traffic to LAN E or LAN F will be marked (which negates my rule )
Discussion: User ZZ is on LANF
a. traffic to others in LAN F will not be marked (layer2)
b. traffic to all other LANS will be marked (which negates my rule )
So if the above is true, the rule is useless and you are greatly amused at my expense LOL.
Not only is !local useless because it has no effect within the same LAN but even worse it fails to have the intended effect for any other
LANS on different interfaces or on different bridges. It doesnt really apply to LANS within the same bridge due to the layer 2 nature of bridging.
Argggggggg.
Where is my drawing board..........
You are blowing my mind
Lets recap with my !local rule in place and assuming LAN to LAN traffic origination from the user
User ZZ
Lans A,B on Bridge (eth3,4
Lans C, D on Brigde TWO (eth5,6)
Lan E on eth7
Lan F on eth8
WANS on eth1 and eth2
Discussion: User ZZ is on LAN A
a. traffic to other in LANA will not be marked due to being in same subnet layer 2 no firewall)
b. traffic to LANB will not be marked due to being on same bridge (in effect also layer 2, FW rules will not apply)
c. traffic to LANS C and D will be marked (which negates my rule
)d. traffic to LAN E or LAN F will be marked (which negates my rule
)Discussion: User ZZ is on LANF
a. traffic to others in LAN F will not be marked (layer2)
b. traffic to all other LANS will be marked (which negates my rule
)So if the above is true, the rule is useless and you are greatly amused at my expense LOL.
Not only is !local useless because it has no effect within the same LAN but even worse it fails to have the intended effect for any other
LANS on different interfaces or on different bridges. It doesnt really apply to LANS within the same bridge due to the layer 2 nature of bridging.
Argggggggg.
Where is my drawing board..........
Re: FROM/TO
Just a small correction, if you have two distinct subnets, then even if they eventually share a common bridge (or a common VLAN), the traffic between them is normally routed anyway. So if LAN A and LAN B in your example were subnets, not just physical ports, a packet from LAN A subnet to LAN B subnet goes via the router and thus via the firewall.
Re: FROM/TO
So drawing board says..............
For discussion purposes only..
If you have another Subnet or many subnets AND not on the same bridge but on different interfaces, one should consider cutting down on marking by excluding these subnets by FW rules
{in this case the rule would look like
add chain=prerouting in-interface={appropriate interface - could be etherX, Bridge, LAN etc} connection-mark=no-mark \
source-address-list=use WAN2_Only \ dst-address-list=!exclude_other_subnets \
action=mark-connection new-connection-mark=CM-users passthrough=yes
where for example........ (if subnet being used is 192.168.5.1/24)
/ip firewall address lists
add name=exclude_other_subnets address=192.168.0.1/24
add name=exclude_other_subnets address=192.168.2.1/24
add name=exclude_other_subnets address=192.168.3.1./24
For discussion purposes only..
If you have another Subnet or many subnets AND not on the same bridge but on different interfaces, one should consider cutting down on marking by excluding these subnets by FW rules
{in this case the rule would look like
add chain=prerouting in-interface={appropriate interface - could be etherX, Bridge, LAN etc} connection-mark=no-mark \
source-address-list=use WAN2_Only \ dst-address-list=!exclude_other_subnets \
action=mark-connection new-connection-mark=CM-users passthrough=yes
where for example........ (if subnet being used is 192.168.5.1/24)
/ip firewall address lists
add name=exclude_other_subnets address=192.168.0.1/24
add name=exclude_other_subnets address=192.168.2.1/24
add name=exclude_other_subnets address=192.168.3.1./24
Re: FROM/TO
Hmmmmm..............Just a small correction, if you have two distinct subnets, then even if they eventually share a common bridge (or a common VLAN), the traffic between them is normally routed anyway. So if LAN A and LAN B in your example were subnets, not just physical ports, a packet from LAN A subnet to LAN B subnet goes via the router and thus via the firewall.
The traffic between them is NOT ROUTED if two subnets on the same bridge.
Device A in 192.168.1.1/24 on bridgeCommon, can ping and access Device B in 192.168.2.1/24 WITHOUT a FW rule - they are connected at layer2.
The traffic cannot be blocked if on the same bridge.
If not on the bridge, then I would agree with you.
VLANs are a different case from what I understand.
The very fact they are in a VLAN means they are separated at Layer2.
Therefore to ensure VLANs are separated at layer3, when on different interfaces one has to have FW rules.
Dont go changing basic HEX behaviour that is now ingrained in my brain!!!!
Re: FROM/TO
I would have to see the firewall rules. If you disable Mikrotik's own IP address in 192.168.1.0/24 or in 192.168.2.0/24 and you will still be able to ping 192.168.2.1 from 192.168.1.1, I'll have to think again. Otherwise I stay where I am. And bear in mind that Mikrotik itself will respond to ping to any of its own addresses coming from any LAN.The traffic between them is NOT ROUTED if two subnets on the same bridge.
Device A in 192.168.1.1/24 on bridgeCommon, can ping and access Device B in 192.168.2.1/24 WITHOUT a FW rule - they are connected at layer2.
So:
device1 (192.168.1.1/24) ----- (192.168.1.2/24) Mikrotik (192.168.2.2/24) ----- (192.168.2.1/24) device2
You can ping from device1 to 192.168.1.2, 192.168.2.2, and 192.168.2.1.
If you disable the address (not the interface) 192.168.2.2/24 on Mikrotik, you'll be unable to ping 192.168.2.1/24 from 192.168.1.1/24 (device2 from device1) even if 192.168.1.0/24 and 192.168.2.0/24 are on the same bridge.
Re: FROM/TO
Not sure what you are saying,,,,,,,
But my understanding
Interface = one LAN subnet
Bridge = multiple LAN subnets
Devices on same subnet are connected at layer2
Devices on same Bridge are connected at layer 2 (including different subnets) its as if the subnets were on the same switch and dont go through router routing (layer3).
Thus if I want to block traffic between devices, ensure they are not communicating at layer two because FW rules will not apply.
The only exception to the above I THINK, is for VLANs, by their very nature they block layer 2 and thus FW rules always apply for them.
Please clarify where I am wrong here..........
But my understanding
Interface = one LAN subnet
Bridge = multiple LAN subnets
Devices on same subnet are connected at layer2
Devices on same Bridge are connected at layer 2 (including different subnets) its as if the subnets were on the same switch and dont go through router routing (layer3).
Thus if I want to block traffic between devices, ensure they are not communicating at layer two because FW rules will not apply.
The only exception to the above I THINK, is for VLANs, by their very nature they block layer 2 and thus FW rules always apply for them.
Please clarify where I am wrong here..........
Re: FROM/TO
There are too few words available to describe too many object types.Not sure what you are saying,,,,,,,
But my understanding
Interface = one LAN subnet
Bridge = multiple LAN subnets
Devices on same subnet are connected at layer2
Devices on same Bridge are connected at layer 2 (including different subnets) its as if the subnets were on the same switch and dont go through router routing (layer3).
Thus if I want to block traffic between devices, ensure they are not communicating at layer two because FW rules will not apply.
Please clarify where I am wrong here..........
In L3 vernacular, an "interface" is something that has an IP address attached to it. So it can be
- an Ethernet interface (also called Ethernet port in other vernacular)
- a wireless interface
- a bridge
- the tagless side of a vlan interface
- a virtual interface like an end of a tunnel, bond, ...
The IP address configuration is accompanied by a mask which determines the size of the subnet to which that address belongs. And you can attach several IP addresses from same or different subnets to a single L3 interface of any of the types listed above.
So you can use either:
Code: Select all
/ip address
add address=192.168.1.2/24 interface=ether1
add address=192.168.2.2/24 interface=ether1
or
Code: Select all
/interface bridge add name=my-bridge
/interface bridge port
add bridge=my-bridge interface=ether1
/ip address
add address=192.168.1.2/24 interface=my-bridge
add address=192.168.2.2/24 interface=my-bridgeDevices in the same subnet must see each other on L2, otherwise they would be unable to send packets to each other, because if a device wants to send a packet, it first looks whether the destination is in its own subnet or elsewhere:
- If the destination is on sender's own subnet, the sender sends an ARP request for the destination's IP address, gets back the MAC address of the destination, and sends the packet to that MAC
- If the destination is outside sender's own subnet, the sender consults its routing table and finds a gateway
- if the gateway is an interface name, the sender sends the packet out via that interface
- if the gateway is an IP address which must be in sender's own subnet, the sender sends an ARP request for the gateway's IP address, gets back the MAC address of the gateway, and sends the packet to that MAC with the destination IP address of the original destination
Re: FROM/TO
Wow, I never realized one could create two subnets like that on one interface.
What would be the advantage to use the bridge and not simply one interface (for two subnets).????
Okay so I have been thinking the wrong thing this entire time. Sigh.....................
Im gonna go get coffee and a dessert and come back to this post soon
Okay so FW rules apply in most cases then. So far the only place they dont is devices on the SAME SUBNET.
Even if two devices are on the same interface but in different subnets they cannot communicate directly without some FW enabling etc...
Even if two devices are on the same bridge but in different subnets they cannot communciate directly without some FW enabling.
The part that is confusing me is I though two subnets on the same bridge were connected via switch chip (wired speed).
What would be the advantage of this if the two subnets cannot talk to each other directly over the switch.............. but instead have to go through the router..........
What would be the advantage to use the bridge and not simply one interface (for two subnets).????
Okay so I have been thinking the wrong thing this entire time. Sigh.....................
Im gonna go get coffee and a dessert and come back to this post soon
Okay so FW rules apply in most cases then. So far the only place they dont is devices on the SAME SUBNET.
Even if two devices are on the same interface but in different subnets they cannot communicate directly without some FW enabling etc...
Even if two devices are on the same bridge but in different subnets they cannot communciate directly without some FW enabling.
The part that is confusing me is I though two subnets on the same bridge were connected via switch chip (wired speed).
What would be the advantage of this if the two subnets cannot talk to each other directly over the switch.............. but instead have to go through the router..........
Re: FROM/TO
That's how IP subnets work, anything in given subnet is local and everything else is remote and needs to go via gateway. And the fact that this "remote" subnet might be on same wire doesn't matter at all.
Btw, I'm a little late to the party, but regarding misunderstandings, I suggest we blame anav, it often seems to be safe choice.
Btw, I'm a little late to the party, but regarding misunderstandings, I suggest we blame anav, it often seems to be safe choice.
Re: FROM/TO
In some cases, you want to connect several external devices to the Mikrotik directly, so you create a bridge over several physical interfaces. In this case, the IP configuration(s) must be attached to the bridge, not to any of its member interfaces (ports).What would be the advantage to use the bridge and not simply one interface (for two subnets).????
There is no advantage. The wirespeed connection using switch chip is an advantage as compared to bridging several ports in software - when e. g. your home video server and your PC are connected each to another physical interface of your Mikrotik, by giving them an IP address from the same subnet you make them see each other at L2, without routing, and by enabling hw-offload you make the switch chip forward packets between them without bothering the CPU. No more and no less than this.The part that is confusing me is I though two subnets on the same bridge were connected via switch chip (wired speed).
What would be the advantage of this if the two subnets cannot talk to each other directly over the switch.............. but instead have to go through the router..........
Re: FROM/TO
Thanks Sindy for explaining the last bit. The switch chip is effective when devices are in the same subnet!
All I know has been gleaned from Sob, so I am bound to have a few misconceptions.
On a serious note, this will help me help others better!
All I know has been gleaned from Sob, so I am bound to have a few misconceptions.
On a serious note, this will help me help others better!
Re: FROM/TO
You still owe me the explanation on the "master of obfuscation" topic.
My theory is that different people think in a different way, and people whose ways of thinking are close to each other can understand each other much faster than people whose ways of thinking are very different. And the key to success in communicating a message is to understand the way the other person thinks and use the same way to explain things.
So I'd like to hear what is obfuscative for you in the way I write my posts.
My theory is that different people think in a different way, and people whose ways of thinking are close to each other can understand each other much faster than people whose ways of thinking are very different. And the key to success in communicating a message is to understand the way the other person thinks and use the same way to explain things.
So I'd like to hear what is obfuscative for you in the way I write my posts.
Re: FROM/TO
Hi Sindy,
I think that we must be opposite thinkers.
A. you assume I am a networking IT wizard
B. I assume you know I am an idiot
Hence we dont see eye to eye all the time.
Basically the problem is you fail to understand how weak my knowledge is and throw in many boundary situations without explaining the meat, the essence of what I am not grasping.
Thus, we spend much time narrowing down the focus of my ineptitude!
I think that we must be opposite thinkers.
A. you assume I am a networking IT wizard
B. I assume you know I am an idiot
Hence we dont see eye to eye all the time.
Basically the problem is you fail to understand how weak my knowledge is and throw in many boundary situations without explaining the meat, the essence of what I am not grasping.
Thus, we spend much time narrowing down the focus of my ineptitude!