Problem with user with improperly configured router...

I have an issue with an user with improperly configured router (most likely proxy-arp) that answers to whole load of IP addresses used elsewhere in the network.
It even hijacks IP of the mikrotik that is placed before the mentioned router.
The mikrotik is a simple bridge placed before router to have finer control over the user’s traffic. The bridge, wan and lan ports (to which the user is connected) have arp set to reply-only, and the public IP addresses have MAC assigned to the router.
This still doesn’t stop that router to hijack all the traffic meant for the mikrotik router, so the only way to communicate with it is through mac telnet.

Any tips welcome.
Thanks

Not much to go on. “Hijack” usually involves a SWAT team and the FBI. Do you mean something like “intercept”, where the router responds to a http or ssh request with the MT login page for the intermediate router?

Just to be clear:
Internet - MT router A - MT router B - client
Router B is the router that intercepts the traffic? And from where? The internet or the LAN side?

Ahh semantics :wink:

The setup is pretty much as you’ve described.
But it’s actually:
Internet - MT A - MT B - user’s router (cisco)

So when I’m trying to connect via telnet/ssh/winbox to the MT B(sitting next to the mentioned router) from internet or MT A, the router responds instead of the MT B.
This is clearly visible when I’m doing an ARP ping from MT A, the first response has MAC address from MT B, the rest is from the router.

Here’s the export from MT B;

/interface bridge
add admin-mac=00:00:00:00:00:00 ageing-time=5m arp=reply-only auto-mac=yes \
    comment="" disabled=no forward-delay=15s max-message-age=20s mtu=1500 \
    name=bridge1 priority=0x8000 protocol-mode=none transmit-hold-count=6
/interface ethernet
set 1 arp=reply-only auto-negotiation=yes bandwidth=4M/4M comment="" \
    disabled=no full-duplex=yes mac-address=00:0C:42:XX:XX:XX master-port=\
    none mtu=1500 name="ether2 - WAN" speed=100Mbps
set 2 arp=reply-only auto-negotiation=yes bandwidth=1M/2M comment="" \
    disabled=no full-duplex=yes mac-address=00:0C:42:XX:XX:XX master-port=\
    none mtu=1500 name="ether3 - LAN" speed=100Mbps


/interface bridge filter
add action=drop chain=forward comment=multicast disabled=no in-interface=\
    "ether3 - LAN" packet-type=multicast
add action=drop chain=forward comment="ARP broadcast" disabled=no \
    in-interface="ether3 - LAN" mac-protocol=!arp packet-type=broadcast

/interface bridge port
add bridge=bridge1 comment="" disabled=no edge=auto external-fdb=auto \
    horizon=none interface="ether2 - WAN" path-cost=10 point-to-point=auto \
    priority=0x80
add bridge=bridge1 comment="" disabled=no edge=auto external-fdb=auto \
    horizon=none interface="ether3 - LAN" path-cost=10 point-to-point=auto \
    priority=0x80

/interface bridge settings
set use-ip-firewall=yes use-ip-firewall-for-vlan=yes


/ip arp
add address=xxx.xxx.xxx.111 comment="" disabled=no interface="ether2 - WAN" \
    mac-address=00:00:D1:XX:XX:XX
add address=xxx.xxx.xxx.112 comment="" disabled=no interface="ether2 - WAN" \
    mac-address=00:00:D1:XX:XX:XX
add address=xxx.xxx.xxx.113 comment="" disabled=no interface="ether2 - WAN" \
    mac-address=00:00:D1:XX:XX:XX
add address=xxx.xxx.xxx.114 comment="" disabled=no interface="ether2 - WAN" \
    mac-address=00:00:D1:XX:XX:XX
add address=xxx.xxx.xxx.115 comment="" disabled=no interface="ether2 - WAN" \
    mac-address=00:00:D1:XX:XX:XX
add address=xxx.xxx.xxx.116 comment="" disabled=no interface="ether2 - WAN" \
    mac-address=00:00:D1:XX:XX:XX
add address=xxx.xxx.xxx.117 comment="" disabled=no interface="ether2 - WAN" \
    mac-address=00:00:D1:XX:XX:XX
add address=xxx.xxx.xxx.118 comment="" disabled=no interface="ether2 - WAN" \
    mac-address=00:00:D1:XX:XX:XX


/ip address
add address=172.16.114.60/24 broadcast=172.16.114.255 comment="" disabled=no \
    interface=bridge1 network=172.16.114.0



ARPing:

ARPING 172.16.114.60 from 172.16.114.1 eth1
Unicast reply from 172.16.114.60 [00:0C:42:XX:XX:XX]  9.213ms
Unicast reply from 172.16.114.60 [00:00:D1:XX:XX:XX]  193.720ms
Unicast reply from 172.16.114.60 [00:00:D1:XX:XX:XX]  7.467ms
Unicast reply from 172.16.114.60 [00:00:D1:XX:XX:XX]  12.363ms
Sent 3 probes (1 broadcast(s))
Received 4 response(s)

Seems to me that it may be Router A that is misconfigured for your needs then. I presume that Router A has a srcnat or masquerade from the local IPs to your public IP? If so, in order to talk to Router B, you would need to DSTNAT the public IP to the private IP of Router B, or you will get Router A’s login.

If I am off base here, let me know. I read your response as “I can’t connect to Router B from the internet. I get Router A’s login instead.”

The user can connect to internet, and I can connect to the routers inside the network (172.16 range).

The problem I have is user’s router. Which responds not only on the public IP addresses that are assigned to it but also to internal IP addresses used in our network(the MT and some equipment located closest to that router are most affected). Because of that I can’t connect to the MT router (MT B on previous post) via it’s internal IP address, as the user’s router responds instead (as shown on the ARP ping above).

So to illustrate this:

Internet → gateway (ie. MT A – I’m testing from here) → MT B(172.16.114.60(00:0C:42:XX:XX:XX) → user’s router 84.xxx.xxx.xxx (00:00:D1:XX:XX:XX)
Now when I’m doing an ARP ping to 172.16.114.60 I would expect to get all responses from 00:0C:42:XX:XX:XX bu in fact I’m getting them from 00:00:D1:XX:XX:XX.

Then that sounds like a challenge with the cisco router’s setup. It shouldn’t be responding to those IPs if it is set correctly. Then your analogy of hijack was correct, but by the “Cisco Pirates”! :wink:

That is the cisco device that is 00:00:D1:XX:XX, right?

ADD: I just noticed the cisco router is on a different subnet than the bridge. How is that set up in Router B? Is there a intermediate masquerade or srcnat in Router B?
/ip firewall nat print

And the 84.xx.xx.xx subnet is a valid public network subnet, isn’t it? Not a good choice for a private address, even that deep in your LAN.

84.xxx.xxx.xxx is public IP address bridged over MT B, the routing is done on the gateway so there’s no need for NAT and any configuration on MT B - for the user it’s a transparent switch.

You’ve got the rest correctly. Now, is there a way to block such behavior on MT B? I don’t have access to that user’s cisco router, so I would rather to deal with the issue on my equipment.

So you actually have 2 public IPs? One for the ethernet port connected to the internet, and one routed into your private net?

It’s actually a dozen of C class of IP ranges. The user has 8 public IP addresses.

OK, now I am confused. You have 12 public IP addresses, of which 8 are assigned internally? Same subnet?

What is the default route on Router B? How does it think it gets to the internet? It wouldn’t be in the subnet assigned to the Cisco Router, would it?

Ok, I’ve solved the problem quite awhile ago so I would like to share on how I did it for anyone that may encounter the same problem.

@SurferTim there is no routing, it’s a switched network, the user has 12 public IPs which are proxy arped on the gateway for them. The gateway handles multiple class C IP ranges, therefor the user has broadcast of 255.255.255.0.

Anyway thanks for your feedback, here’s the solution:

/interface bridge filter
add action=accept arp-src-address=84.XX.XX.XXA/32 arp-src-mac-address=\
    00:00:D1:XX:XX:XX/FF:FF:FF:FF:FF:FF chain=forward comment="" disabled=no mac-protocol=arp
add action=accept arp-src-address=84.XX.XX.XXB/32 arp-src-mac-address=\
    00:00:D1:XX:XX:XX/FF:FF:FF:FF:FF:FF chain=forward comment="" disabled=no mac-protocol=arp
add action=accept arp-src-address=84.XX.XX.XXC/32 arp-src-mac-address=\
    00:00:D1:XX:XX:XX/FF:FF:FF:FF:FF:FF chain=forward comment="" disabled=no mac-protocol=arp
add action=accept arp-src-address=84.XX.XX.XXD/32 arp-src-mac-address=\
    00:00:D1:XX:XX:XX/FF:FF:FF:FF:FF:FF chain=forward comment="" disabled=no mac-protocol=arp
add action=accept arp-src-address=84.XX.XX.XXE/32 arp-src-mac-address=\
    00:00:D1:XX:XX:XX/FF:FF:FF:FF:FF:FF chain=forward comment="" disabled=no mac-protocol=arp
add action=accept arp-src-address=84.XX.XX.XXF/32 arp-src-mac-address=\
    00:00:D1:XX:XX:XX/FF:FF:FF:FF:FF:FF chain=forward comment="" disabled=no mac-protocol=arp
add action=accept arp-src-address=84.XX.XX.XXG/32 arp-src-mac-address=\
    00:00:D1:XX:XX:XX/FF:FF:FF:FF:FF:FF chain=forward comment="" disabled=no mac-protocol=arp
add action=accept arp-src-address=84.XX.XX.XXH/32 arp-src-mac-address=\
    00:00:D1:XX:XX:XX/FF:FF:FF:FF:FF:FF chain=forward comment="" disabled=no mac-protocol=arp

add action=drop arp-src-mac-address=00:00:D1:XX:XX:XX/FF:FF:FF:FF:FF:FF chain=forward comment="" \
    disabled=no mac-protocol=arp

The only small bit left is that now the only way I can access that MT box is through MAC telnet, but most importantly the core problem is solved.

Have you considered doing ingress filtering on your customers to see if you can block out this nasty traffic?

Isn’t above example exactly it? :slight_smile:

Seems to be a non optimal solution if it breaks certain IP connectivity on your network, do you have any kind of managed network device that is closer to the customer and capable of doing filtering?

At my work our primary platform is Motorola Canopy which works great for us as you can configure each CPE to only let through PPPoE frames and block all the other junk from getting on the network.

This mikrotik is last device before the customer. Unfortunately I don’t have the luxury of having PPPoE (as it should be done). Our company is tied with a service provider which has very simplistic approach to network managing.

I think I have an idea how to solve the last issue I have with above setup, I’ll post an update when I’ll solve it.