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.
C:\Windows\system32>arp -a
Interface: 192.168.2.14 --- 0xe
Internet Address Physical Address Type
192.168.2.10 d4-ca-6d-6e-88-bc dynamic
192.168.2.255 ff-ff-ff-ff-ff-ff static
192.168.45.1 d4-ca-6d-6e-88-bc dynamic
C:\Windows\system32>arp -d *
C:\Windows\system32>arp -a
Interface: 192.168.2.14 --- 0xe
Internet Address Physical Address Type
192.168.2.10 ec-9a-74-ba-d1-60 dynamic
C:\Windows\system32>arp -a
Interface: 192.168.2.14 --- 0xe
Internet Address Physical Address Type
192.168.2.10 d4-ca-6d-6e-88-bc dynamic
192.168.2.255 ff-ff-ff-ff-ff-ff static
192.168.45.1 d4-ca-6d-6e-88-bc dynamic
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.
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.
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.
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.
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.
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.