Howdy,

I think the title is accurate...

If I plug a new device into my LAN that is not on the same /24 that I need to configure, I will assign a static IP to my workstation to match the device's default IP. In this case I am using a HPE 1810G-8 switch. My LAN uses 192.168.45.0/24, my RB2011 is assigned 192.168.45.1/24 with the MAC address of d4-ca-6d-6e-88-bc.

Default IP of the switch is 192.168.2.10. I set my workstation to 192.168.2.14.

I can ping 192.168.2.10 once, then it starts to time out.

If I set this switch and my workstation to an unused VLAN everything works as expected. When just connecting to my LAN and setting the static IP, it fails.
After arp -d * I ping 192.168.2.10 once, then goes back to request timed out, until I do arp -d * again.

This is just the device beside me right now. It doesn't matter what device I connect or what network it uses, except for 192.168.45.0/24.

I'm sure it is something simple, but this is really starting to irritate me.

Maybe the router has the arp reply only setting on lan interface and makes answers only to those mac addresses that were given an ip by its dhcp server...
But maybe not, if it responds to one network range only. Firewall rule, probably.

Maybe the router has the arp reply only setting on lan interface and makes answers only to those mac addresses that were given an ip by its dhcp server...
But maybe not, if it responds to one network range only. Firewall rule, probably.

Huh?

A firewall rule might be causing it? Or a firewall rule might fix it?

There are ARP settings in the interface, there are also ARP settings in the bridge... Thank you for pointing me in that direction, time to RTFM on these settings? Could one of them be causing this?

The bridge is setup for a couple OpenVPN clients.. One would be much better not to be, but I don't see a way to run the OpenVPN server on two ports for Ethernet and IP.

Alright, may have this solved..

The physical interface ARP setting was not changed, still set as Enabled.

I changed the bridge from proxy-arp to local-proxy-arp. As far as I could tell, there isn't a RouterOS manual page for the local-proxy-arp setting..

If I was to guess, RouterOS is not answering ARP queries unless it is for an IP address on the subnets assigned to one of it's interfaces?

You should not use proxy-arp unless you exactly know what it does and why you would need it for your situation.
Set ARP to "enabled". When this causes connectivity problems, look at the configuration of your DHCP service.
It should provide the default gateway to your DHCP clients.

You should not use proxy-arp unless you exactly know what it does and why you would need it for your situation.
Set ARP to "enabled". When this causes connectivity problems, look at the configuration of your DHCP service.
It should provide the default gateway to your DHCP clients.

It is hard to know exactly how everything works..

My understanding is it is used for dial-in connections, OpenVPN, IPSEC, PPTP, to pass arp-data if the connection is filtering broadcast information.. Likely why it was enabled..

As well, there is no RouterOS documentation on local-proxy-arp.

local-proxy-arp was not the correct answer either, now I am seeing the router's MAC on many IPs in the arp-list.

I will change it to Enabled and watch the network for a the next week to see how it responds.

I really wasn't expecting proxy-arp to put itself in random IPs.

Oh well.. Learnt something new..

[
I really wasn't expecting proxy-arp to put itself in random IPs.

Just to clarify: that was NOT a random IP. The bridge in proxy-arp did exactly what it was supposed to do.
It heard an arp-request and answered on behalf of the requested node.

That's what pe1chl meant with "unless you exactly know what it does and why you would need it for your situation"

Having VPN users in the same IP pool as your local network seems convenient but can cause a lot of unexpected behavior on the local side as you experienced.
I keep advising to use a separate IP pool for VPN access.

Cheers,
-Chris

Argh!!

Since making this change, every time an IP changes on the router, drops, reconnects, whatever, the router stops responding for ~10 seconds.

ARP -a now shows the bridge MAC rather than the interface MAC..

I see this at my uncle's place too, but I just ignore it because it is pretty much set and forget.

If I bounce my PPPoE connection, I get disconnected on the LAN side a few seconds later, for about 10 seconds.

Changing back to proxy-arp does not resolve.

Having VPN users in the same IP pool as your local network seems convenient but can cause a lot of unexpected behavior on the local side as you experienced.

True. I would have liked to see an option to do proxy-arp only for a specific (list of) subnet(s), so one can decide to do proxy-arp for something like a VPN user in the LAN range without doing proxy-arp for the whole world at that time, but it does not appear to be available. Not in RouterOS, but not in the underlying Linux kernel either. You would want to do proxy-arp via some rule in the raw chain of iptables, for example.

True. I would have liked to see an option to do proxy-arp only for a specific (list of) subnet(s), so one can decide to do proxy-arp for something like a VPN user in the LAN range without doing proxy-arp for the whole world at that time, but it does not appear to be available. Not in RouterOS, but not in the underlying Linux kernel either. You would want to do proxy-arp via some rule in the raw chain of iptables, for example.

That would be awesome.
Just an idea - couldn't this be (partially) accomplished w/ bridge filters?
Like setting the bridge to proxy-arp, then adding a bridge filter on arp-replies in output chain, and drop everything but the specified subnet and the router itself.in src-address.
"normal" arp-replies from the other ports shoulld still be able to pass the bridge because its forward...
Could this make sense?
-Chris

Well, ARP traffic is not seen in any of the "iptables" filters.
There exists a little-known Linux package "arptables" which can inspect ARP traffic, but it does not appear to have target rules to craft some ARP reply, so it would still have to take the form of enabling proxy-arp (for the replies) and then dropping requests that are not for the local network.