I want all traffic from MAC1 to any host behind the MT to be redirected to MAC2. Instead it is dropped. No traffic arrives at MAC1. It’s not an ARP problem - ping is lost right after adding the rule.
That’s the simplest rule of dst-nat and I guess it’s just a bug. Correct me.
Bringing both interfaces in a bridge means all packets pass router transparent like both connected LAN’s are part of one big LAN. So packages travel from one mac to another like in one big network.
The setting for nat is only valid if you would have another interface that is outside the bridge, and thus routed, and a package with destination to that ´non-bridged´ interface has to get another mac. That how it works imho.
supermega, can you post your configuration rather than describe it, together with a network diagram that shows links and devices with their ports, IPs, and MACs labeled? The configuration should include, at minimum, the output of “/interface bridge export” and “/interface print detail”.
Maybe he forgot to enable the bridge firewall:
/interface bridge settings
set use-ip-firewall=yes use-ip-firewall-for-pppoe=no use-ip-firewall-for-vlan=
But what is the purpose of using a bridge if you actually are routing all traffic from certain mac/IP to one other mac/IP?
In bridge all traffic is still broadcast over the whole network? Even the answer from the recipient is broadcast LAN wide again.
Would it not more economic to use the router as router to do this? But maybe indeed it depends on how his network is setup and how much traffic he has to deviate.
Flags: D - dynamic, X - disabled, R - running, S - slave
0 R name="wlan1" type="wlan" mtu=1500 l2mtu=2290
1 R name="ether1" type="ether" mtu=1500 l2mtu=1600 max-l2mtu=4076
2 R name="bridge1" type="bridge" mtu=1500 l2mtu=1600
Is there anything in the IP firewall that could block traffic?
Also, this is a shot in the dark - I don’t have much experience with bridge NAT - but I vaguely remember seeing somewhere that the admin MAC should be set for bridge filters and NAT. Can you try setting a locally administered MAC address on that?
Otherwise that looks good to me. I wouldn’t scream bug - it’s unlikely you’ve hit a bug. Misconfiguration is more likely, though right now I’m unfortunately not seeing it.
Flags: X - disabled, I - invalid, D - dynamic
# CHAIN ACTION BYTES PACKETS
0 dstnat dst-nat 4554 99
I determinate by observing ping - it’s lost when I activate the rule. What you mean where?
LAN — MT — CPE — WLAN-HOST
I’ve done some more tests: when I ping WLAN-HOST and dnat to CPE MAC it’s redirected well - packets go to CPE and then are forwarded in layer 3 to WLAN-HOST. Main difference with this setup is that output interface for dst-nated packet isn’t changed, while in previous setup it was changed from wlan1 to ether1.
kirshteins, do you also use dst-nat to change destination interface?
Still get no results for dst-nat. Thing is, it’s very simple to reproduce by anyone who has any MT device. Commands below are for devices with at least 2 ethernet ports, otherwise you need to change ether2 for example to wlan1.
Comments:
dst-mac-address=!FF:FF:FF:FF:FF:FF/FF:FF:FF:FF:FF:FF - not to lose communication with MT (connecting to MAC address is via broadcast)
mac-protocol=!arp - to be sure that problem is not arp issue
DST_MAC - is MAC of a device able to monitor traffic: tcpdump, Wireshark, MT with Torch, etc.
Now we ping any host behind the MT:
When out-interface is different from in-interface - redirection works OK.
When out-interface is same as in-interface - packets are dropped.
Topology:
1a. Pinging host on ether1, monitoring host on ether2, pinged host on ether2
1b. Pinging host on ether1, monitoring host on ether3, pinged host on ether2
2. Pinging host and monitoring host on same interface. supout.rif.zip (193 KB)