Page 1 of 1
Mikrotik PPTP/Proxy-ARP & DHCP
Posted: Fri Feb 07, 2014 8:17 am
by qtm
Hi Guys,
We are having a really strange problem.
The setup is as follows:
1 x DHCP server (some windows box) (ranges 10.0.0.50-10.0.0.100)
1 x Mikrotik (DHCP disabled, default range 192.168.88.0/24) - This is the network the VOIP equipment run on
When we PPTP into the Mikrotik and try to access the VOIP equipment on the 192.168.88.0/24 range we can only do so when Proxy-ARP is on, which is all well etc.
However while Proxy-ARP is on the the DHCP server doesn't issue new IP's to the PC network of 10.0.0.0/24 and after a while the PC network becomes intermittent at best.
Any ideas from you guys?
Thanks
Will
Re: Mikrotik PPTP/Proxy-ARP & DHCP
Posted: Sun Jul 20, 2014 10:56 pm
by klaparp
I´ve got the same problem. Did you solve this?
/HW
Re: Mikrotik PPTP/Proxy-ARP & DHCP
Posted: Tue Jul 22, 2014 8:55 am
by CblP
capture the traffic and you will see that DHCP server is actually issuing addresses to clients just fine.
The problem is that mikrotik answers to an ARP request from client when it checks if the offered IP is taken.
Once you filter these answers, it will be fine.
I faced this trouble couple of days ago, and it was the bridge that was sending these ARP replies,
so, I had to use bridge filter.
Re: Mikrotik PPTP/Proxy-ARP & DHCP
Posted: Tue Jul 22, 2014 10:16 am
by bajodel
The problem is that mikrotik answers to an ARP request from client when it checks if the offered IP is taken.
sorry, I did not understand
Re: Mikrotik PPTP/Proxy-ARP & DHCP
Posted: Tue Jul 22, 2014 1:44 pm
by CblP
take a look at this capture, it explains it all:
https://yadi.sk/d/Va7dWJbmX6tzX
basically, DHCP works fine, because client gets an offer.
In order to make sure that the IP is not taken, the client sends an ARP request for this IP,
and expects no answer in normal situation.
Mikrotik answers this request with it's own MAC, so client "thinks" that the IP is actually not free, and asks the DHCP server for a new one, and it happens in a loop. As you may see it is breaking the DHCP functionality.
This is happening with any setting in bridge properties, proxy-arp, enabled, disabled, reply-only - anything.
Maybe a bug, or maybe this is the way it should be working - I didn't quite understand the logic behind this setting.
Anyway, I just filtered this answer in bridge filter, so it is still being generated, but does not go out to DHCP client port - and everything works fine for me
Re: Mikrotik PPTP/Proxy-ARP & DHCP
Posted: Tue Jul 22, 2014 6:16 pm
by bajodel
Looking at the capture I'm a little bit confused:
Packet-01) HostA [Source IP 0.0.0.0 MAC 20:e5:64:f1:89:0a (motorola?)] -> broadcast a dhcp discover
Packet-02) HostB [Source 10.107.4.1 MAC 00:21:91:a0:83:0d (dlink?)] -> unicast to HostA a dhcp offer
Packet-03) HostA [Source 0.0.0.0 MAC 20:e5:64:f1:89:0a (motorola?)] -> broadcast a dhcp request
Packet-04) HostB [Source 10.107.4.1 MAC 00:21:91:a0:83:0d (dlink?)] -> unicast to HostA a dhcp ack
Packet-05) HostA [Source MAC 20:e5:64:f1:89:0a (motorola?)] -> broadcast an arp request (gratuitous)
Packet-06) ..not_pertinent..
Packet-07) ..not_pertinent..
Packet-08) HostC [ Source MAC 02:5d:90:af:0d:9d(locally-adm) -> unicast reply gratuitous arp warning (duplicate address)
Packet-09) HostC [ Source MAC 02:5d:90:af:0d:9d(locally-adm) -> broadcast request gratuitous arp warning (duplicate address)
Packet-10) HostA [Source IP 0.0.0.0 MAC 20:e5:64:f1:89:0a (motorola?)] -> broadcast a dhcp Decline
Look like HostC (invalid mac?) is giving the warning (not the dhcp server itself).
MACs are edited, I presume, otherwise the dhcp server is not Mikrotik.
The only thing I clearly understand is that I've never understood
Re: Mikrotik PPTP/Proxy-ARP & DHCP
Posted: Tue Jul 22, 2014 7:00 pm
by CblP
problem is packet 8, which is sent by mikrotik bridge interface (host C) to everything connected to it, including the port where host A connected. DHCP service is running on host B indeed, and it is working fine.
Host C (tik) causes troubles to host A.
Re: Mikrotik PPTP/Proxy-ARP & DHCP
Posted: Tue Jul 22, 2014 10:47 pm
by rextended
Hi Guys,
We are having a really strange problem.
The setup is as follows:
1 x DHCP server (some windows box) (ranges 10.0.0.50-10.0.0.100)
1 x Mikrotik (DHCP disabled, default range 192.168.88.0/24) - This is the network the VOIP equipment run on
When we PPTP into the Mikrotik and try to access the VOIP equipment on the 192.168.88.0/24 range we can only do so when Proxy-ARP is on, which is all well etc.
However while Proxy-ARP is on the the DHCP server doesn't issue new IP's to the PC network of 10.0.0.0/24 and after a while the PC network becomes intermittent at best.
Any ideas from you guys?
Thanks
Will
I think the problem are not the proxy arp.
The problem are missing route/gateway/nat on one side, but without seeing effective configuration, I can not say any opinion.
For example, if MikroTik IP is 192.168.88.1, VoIP is 192.168.88.77, and PPTP REMOTE ip is 10.10.10.10 simply DISABLE PROXY-ARP and add one nat rule like:
/ip firewall nat
add action=src-nat chain=srcnat dst-address=192.168.88.77 src-address=10.10.10.10 to-addresses=192.168.88.1
But without precise detail on config, is only one hyphotesys.
Re: Mikrotik PPTP/Proxy-ARP & DHCP
Posted: Wed Jul 23, 2014 7:04 am
by CblP
The problem are missing route/gateway/nat on one side, but without seeing effective configuration, I can not say any opinion.
I'm pretty sure that OPs problem is what I described above, because he has DHCP trouble in 10.x.x.x, he didn't say that he wants 10.x.x.x network to talk to 192.x.x.x network, where NAT suggestion would apply.
Re: Mikrotik PPTP/Proxy-ARP & DHCP
Posted: Wed Jul 23, 2014 8:07 am
by bajodel
problem is packet 8, which is sent by mikrotik bridge interface (host C) to everything connected to it, including the port where host A connected. DHCP service is running on host B indeed, and it is working fine.
Host C (tik) causes troubles to host A.
do you know if this issue happens also when mikrotik is dhcp server (on a bridge int ..or.. always)?
is there an opened ticket to mikrotik support?
Re: Mikrotik PPTP/Proxy-ARP & DHCP
Posted: Wed Jul 23, 2014 8:28 am
by CblP
I don't have the will to test the same setup with tik as DHCP, but my guess is that it doesn't matter because the problem is how tik handles ARP requests.
I have 2 tiks, v.6.12 and v.6.15, and the problem only happens on v6.15,
so, my guess is that it is a bug introduced recently, which might be fixed in 6.17,
but I have no intention to update for now ("don't touch things that work fine" rule).
If anyone is interested in reproducing the problem, please let us know once you have some results.
Re: Mikrotik PPTP/Proxy-ARP & DHCP
Posted: Wed Jul 23, 2014 11:11 am
by bajodel
.. "don't touch things that work fine" rule ..
I agree!
You had helped a lot already, as soon as possible I'll try to test on a lab env. I'll report here any findings.
Re: Mikrotik PPTP/Proxy-ARP & DHCP
Posted: Mon Feb 13, 2017 12:08 pm
by DaveBrowning
capture the traffic and you will see that DHCP server is actually issuing addresses to clients just fine.
The problem is that mikrotik answers to an ARP request from client when it checks if the offered IP is taken.
Once you filter these answers, it will be fine.
I faced this trouble couple of days ago, and it was the bridge that was sending these ARP replies,
so, I had to use bridge filter.
Could you provide example of the bridge filter you setup?
Re: Mikrotik PPTP/Proxy-ARP & DHCP
Posted: Fri Mar 03, 2017 1:40 pm
by CblP
I've got rid of my tik router since then, and am using a CHR + switch, so, my "bridge" has moved to switch now from mikrotik.
Due to this I will not be able to reproduce the exact scenario without putting too much effort, so, my guess is that it was something along this line:
/interface bridge filter
add action=drop arp-gratuitous=yes arp-opcode=0x2 chain=output dst-mac-address=\
01:02:03:04:05:06/FF:FF:FF:FF:FF:FF mac-protocol=arp out-bridge=bridge-local src-mac-address=\
0A:0A:0A:0A:0A:0A/FF:FF:FF:FF:FF:FF
where 01:02:03:04:05:06 is affected DHCP client and 0A:0A:0A:0A:0A:0A is mikrotik bridge.
Not tested, but you get the idea