Everything I read says that in firewall filter rules, use the actual vlan interface for interface matching instead of the vrrp-interface.
However, for in-interface, it only matches if I use the vrrp interface.
I have a bridge with a few vlans. Each of those vlans contains 1 vrrp interface (vrrp is inside the vlan). Bridge -> vlan -> vrrp
vlan address = 192.168.1.2/24
vrrp address = 192.168.1.1/32
My laptop is on one of those vlan networks.
In the filter rules:
in-interface=vlan100 never matches.
in-interface=vrrp-vlan100 matches correctly.
Is this the expected behavior? I'm not targeting the vrrp address. I'm browsing general Internet.
So, it works, but it doesn't match what I'm reading (although I can't find too much).
Why is it matching the vrrp interface instead of the actual vlan interface?
Re: vrrp in firewall filter rules
Well, what you read may not be fully correct.
VRRP is very special in its IP address setup. This has consequences for the traffic (did not read it but found out the hard way).
Requests that come in via the VRRP IP address are quite often answerred via it's master interface (IP address)
What I think happens ...
That has to do with the /32 and /24 subnet used.
The VRRP is a very small network, the VLAN is the larger, but overlapping network.
For routing the connect initiation via the router goes via the VRRP, the respons comes via the VLAN (because the requestor is part of the VLAN subnet, not part of the VRRP subnet)
With loose tracking in the FW that is no FW problem.
But my User Manager RADIUS service did not work this way. The request via VRRP address , answered via the VLAN address was apparently not accepted by the RADIUS client AP (wrong src IP for answer? I assume)
I had to change the RADIUS connect setting in the AP to the VLAN address, not the VRRP for RADIUS to work.
Look at your interface counters, and try to understand what happens ...
VRRP is very special in its IP address setup. This has consequences for the traffic (did not read it but found out the hard way).
Requests that come in via the VRRP IP address are quite often answerred via it's master interface (IP address)
What I think happens ...
That has to do with the /32 and /24 subnet used.
The VRRP is a very small network, the VLAN is the larger, but overlapping network.
For routing the connect initiation via the router goes via the VRRP, the respons comes via the VLAN (because the requestor is part of the VLAN subnet, not part of the VRRP subnet)
With loose tracking in the FW that is no FW problem.
But my User Manager RADIUS service did not work this way. The request via VRRP address , answered via the VLAN address was apparently not accepted by the RADIUS client AP (wrong src IP for answer? I assume)
I had to change the RADIUS connect setting in the AP to the VLAN address, not the VRRP for RADIUS to work.
Look at your interface counters, and try to understand what happens ...
You do not have the required permissions to view the files attached to this post.
Re: vrrp in firewall filter rules
It's a /32 on the router. BUT...to the PC/laptop client on the VLAN, the VRRP address is the default gateway (and appears part of the /24). VRRP responds to the ARP from PC/laptop, based on master/slave with VLAN's MAC of active. So when the "internet traffic" would go via the default gateway, which presumably the VRRP... & thus hit the VRRP interface in firewall is to be expected. Maybe this has changed at some point, but to me it make sense you see this traffic hit the interface=*-vrrp rule.
@bpwl case is different. Traffic is coming from a "router process", so it's using the routing table send packets to/from RADIUS. So... unless @bpwl mangled the output traffic to use the VRRP as the src-address, RouterOS/UM use the interface's IP address it went out on (which wouldn't be the VRRP one since it just a /32). And RADIUS no doubt check the src-address it got, not the VRRP one you'd thought
.
But the firewall and VRRP get confusing quickly. So could be wrong here.
@bpwl case is different. Traffic is coming from a "router process", so it's using the routing table send packets to/from RADIUS. So... unless @bpwl mangled the output traffic to use the VRRP as the src-address, RouterOS/UM use the interface's IP address it went out on (which wouldn't be the VRRP one since it just a /32). And RADIUS no doubt check the src-address it got, not the VRRP one you'd thought
. But the firewall and VRRP get confusing quickly. So could be wrong here.
Re: vrrp in firewall filter rules
Thx @Amm0
Doing SRC-NAT on traffic from local processes seems rather (very) difficult with RouterOS. There are quite some posts in this forum with tricky setups to change "output" traffic into "forwarding" traffic, so that the SRC address could be set as desired. So far I have given up to have redundant User Manager RADIUS via VRRP. (The AP's, radius clients, connect to both RADIUS servers in the sequence as listed with their VLAN address, if the first does not respond. The RADIUS servers are not synced anyway. The first thing they do is drop all the sessions allowed by the other)
Doing SRC-NAT on traffic from local processes seems rather (very) difficult with RouterOS. There are quite some posts in this forum with tricky setups to change "output" traffic into "forwarding" traffic, so that the SRC address could be set as desired. So far I have given up to have redundant User Manager RADIUS via VRRP. (The AP's, radius clients, connect to both RADIUS servers in the sequence as listed with their VLAN address, if the first does not respond. The RADIUS servers are not synced anyway. The first thing they do is drop all the sessions allowed by the other)
Re: vrrp in firewall filter rules
@bpwl, I wasn't suggesting to change what you're doing — using real/non-VRRP IPs in RADIUS seems like a safer plan. More noting the difference in the cases.
In V6, I want to say you can use pref-src on a /ip route to solve as an alternative to mangle'ing UM... but I do know pref-src with VRRP address trick does NOT work in V7. So your left with mangle for router processes.
In V6, I want to say you can use pref-src on a /ip route to solve as an alternative to mangle'ing UM... but I do know pref-src with VRRP address trick does NOT work in V7. So your left with mangle for router processes.
Re: vrrp in firewall filter rules
Is this the expected behavior? I'm not targeting the vrrp address. I'm browsing general Internet.
So, it works, but it doesn't match what I'm reading (although I can't find too much).
Why is it matching the vrrp interface instead of the actual vlan interface?
Yes, it is an expected behavior from a MIKROTIK point of view.
From a Linux perspective, VRRP is a sub-interface with his own mac-address (VMAC).
Packets that need to be forwarded would be delivered to the VMAC - and VIP.
Example with iproute2:
Code: Select all
modprobe macvlan
[ $? -eq 0 ] && ip link add link eth0 name eth0.10 type vlan id 10
[ $? -eq 0 ] && ip link add link eth0.10 name vrrp4.1 type macvlan mode bridge
[ $? -eq 0 ] && ip a add 10.0.0.1/32 dev vrrp4.1
[ $? -eq 0 ] && ip link set dev vrrp4.1 up
[ $? -eq 0 ] && tcpdump -i vrrp4.1 -vn
As per MIKROTIK configuration, If you want to manage a VIP from the VLAN interface, you should attach it manually; which is obviously not VRRP.
Some open source VRRP implementations, like keepalived, offer the possibility to avoid VMAC and just install VIP into the base interface - but also in this case this would not respect the standard.
Hope that helps
Last edited by nstp on Sat Feb 03, 2024 7:44 am, edited 1 time in total.
Re: vrrp in firewall filter rules
But now (ROS 7.12) we have MACVLAN in Mikrotik.
What is the possible interface stack to be used?
I use VRRP on VLAN on ethernet ( actually bridge) .
But I have seen posts here with VLAN on VRRP on ethernet/bridge. (To make all VLAN flap router at the same time ??? But isn't there "Group Authority" for this?))
Stack becomes bigger ....
"Real interface - VLAN - MACVLAN - VRRP ", " ether - VLAN - VRRP - MACVLAN" , " ether - MACVLAN - VLAN - VRRP", ... etc etc , what makes sense?
But RADIUS communication is normally UDP (stateless) , so the return path does not depend on the connection session?
Only the IP address route then defines the responding IP interface/address ???
Is "radsec" also stateless?
What is the possible interface stack to be used?
I use VRRP on VLAN on ethernet ( actually bridge) .
But I have seen posts here with VLAN on VRRP on ethernet/bridge. (To make all VLAN flap router at the same time ??? But isn't there "Group Authority" for this?))
Stack becomes bigger ....
"Real interface - VLAN - MACVLAN - VRRP ", " ether - VLAN - VRRP - MACVLAN" , " ether - MACVLAN - VLAN - VRRP", ... etc etc , what makes sense?
But RADIUS communication is normally UDP (stateless) , so the return path does not depend on the connection session?
Only the IP address route then defines the responding IP interface/address ???
Is "radsec" also stateless?
Re: vrrp in firewall filter rules
I'm a simple man: one VRRP per VLAN. With VRRP as .1, and router as .254 counting down, even if there is just one router I just enable it from start.
I've test Group Authority.. but VRRP master are often split between routers so not too useful. Similar with connection tracking*, a few seconds for reconnect/etc is fine in my world, compared with the add complexity. *On WAN... under some specific condition... I can see how connection tracking be useful.
@bpwl, have you tried adding a /32 route to your RADIUS and setting the pref-src= as the VRRP address? I think /ip/route pref-src= does work from local processes, just not for forwarded/NAT traffic.
I've test Group Authority.. but VRRP master are often split between routers so not too useful. Similar with connection tracking*, a few seconds for reconnect/etc is fine in my world, compared with the add complexity. *On WAN... under some specific condition... I can see how connection tracking be useful.
@bpwl, have you tried adding a /32 route to your RADIUS and setting the pref-src= as the VRRP address? I think /ip/route pref-src= does work from local processes, just not for forwarded/NAT traffic.