Hello,


I have this old problem that I whill try to solve again, hope with more luck this time!

I whill try to explane if necessary I can draw simple diagram!


ISP-WAN ip x.x.x.1/29 --->My mikrotik WAN IP x.x.x.2/29
I have masquarade to WAN int. all my LAN networks and pppoe server!

I woud like to use one of my free public IP x.x.x.3 and give it to a user in my LAN network!

Can I do it with pppoe somehow ?
Can I create Vlan interface and bridge it thru my LAN net. with WAN ?
Or maybe use NAT ?


Any advice woud help!

Ty

Set arp=proxy-arp on the WAN interface.
If you're already using PPPoE, then just stick with that - on this particular user's secret, you can specify the remote IP as x.x.x.3.

Make sure that your NAT rules and filter rules do not apply to this user.

If all of this is done, it should easily work and everyone will be happy.


EDIT:

If the user connects to you over a dedicated ethernet interface, or over a dedicated VLAN, then what you do is set that interface arp=proxy-arp also, and add a static /32 route: dst-address=x.x.x.3/32 gateway=user-interface

(NAT and filter statement still applies here)

Hi,

first time I tryed this I did it like you seid with proxyarp and it worked but .. then some kind of arp poisoning hapend to my ISP and got disconeted !

Is there a way to use pppoe with out proxy-arp I woud like to avoid that ?

I did try it now with bridgeing vlan-s but then my masquarde rule gets cscrued ( I thinnk) and no internet !

You can say that users are on ethernet int. it is bridge wifi wds network!

Any other Ideas !

Ty

With the PPPoE configuration, you could create a backup route for the IP like this:
/ip route add dst=x.x.x.3 type=blackhole distance=254

This way, even if the user is disconnected, your Mikrotik will answer the ARP requests on the WAN side for the user. If the user is disconnected at the moment, then it will just throw any traffic into a black hole and be done.

You could also put a firewall filter rule on the output chain of the wan interface which blocks ARP replies whose source is not one of your public IP addresses - this way you're never answering for an arp to 192.168.x.x on your WAN interface.

proxy-arp to an ethernet segment on behalf of a ppp client is a very old and time-tested technique. (This is how the dialup terminal servers operated at an ISP where I worked back in 1996)

If you want to bridge the user onto your WAN segment, I would strongly urge that you not do this unless there is some VLAN or special SSID - something which doesn't make your WAN available to the general population of wireless clients.
Otherwise, they'll be able to notice this and just put a public IP on their equipment without asking you.

Thank you for your help!

One more q. with backup route I still need proxy-arp to work?
If I block all arp requests on WAN except my wan IP x.x.x.2 there is no problem resolving IP x.x.x.3?
What mac address is used in this situation for clients adress .3?


Edit: for arp firewall-ing I use brdige filter "firewall" , do I exclude all my public IP adresses? Hard to do any live testing on live network and I never used bridge filter !


I defenetly agree that vlan idea is not secure, I whill test with pppoe !

I whill try 1-1 nat to for backup solution, I bumb to some similar situations people use but pppoe seams more elegant !

Thx u allready helped alot!

I would filter outbound ARP and permit the entire range of x.x.x.2 through x.x.x.6 as the source. Drop any other source.
You still need proxy arp with the static route solution I mentioned.

The rule for proxy arp is this: For any arp request seen on an interface, if the destination IP address is in the routing table and the route points to any interface OTHER than the one where the ARP was received, then reply to the ARP with your own MAC address.

Example:
You have a router with LAN interface = 192.168.1.1/24 (proxy arp enabled), a static route to 192.168.2.0/24 through another router on the LAN 192.168.1.2, and default gateway on interface WAN -> 172.16.1.1

If host 192.168.1.15 on the LAN sends an ARP requesting 192.168.1.55, then the router will not reply, because the destination is reachable but via the LAN interface. The same happens if host 192.168.1.15 then sends an ARP request for 192.168.2.21 - Again the router will not reply because while it does know the route to reach .2.21, and it is not directly on the LAN interface, the next hop IS on the LAN interface, so router1 will not answer this ARP either.

If host 192.168.1.15 then sends an ARP request for 8.8.8.8 - the router WILL answer this ARP request because 8.8.8.8 matches the default route, which goes to another interface (wan) than the one the ARP was received on (lan). If you were to show the ARP table on host 192.168.1.15, it would have router1's MAC address for 192.168.1.1 and 8.8.8.8, it would have router2's MAC address for 192.168.1.2 and 192.168.2.21, and for 192.168.1.55, it would have that host's actual MAC address.

Cisco actually has proxy-arp enabled by default, so it's not an unusual thing.

The reason I gave this static route solution should now be more apparent. If the PPPoE connection is active, then your router will have an Active, Dynamic route x.x.x.3/32 gateway=pppoeX. Since the gateway is a different interface than WAN, if the ISP's router sends an arp for x.x.x.3, then your router will respond with its own MAC address so the ISP knows to send this packet to your Mikrotik.

If the user disconnects, the pppoe interface will deactivate, and the dynamic route will go away. Without the static "backup" route, your Mikrotik would consider x.x.x.3 to be part of x.x.x.0/29 dynamic, connected, gateway=wan-interface. So while the pppoe link is down, the Mikrotik will not answer proxy-arp requests from the ISP router for x.x.x.3
With the backup route configured, even when the user is down, the Mikrotik will have a static route to the host which does not "point to" the wan interface, so it should still answer the ARP requests from the ISP router for x.x.x.3.

Double NAT is going to be an easily-accomplished backup strategy, but I would feel sorry for the user if they are forced into this situation. If you have a dedicated IP address, then it should be on your devcie, you know?

Thank you for taking the time and explaneing .
Basically with this rule I cant poison my ISP arp table , he whill have same MAC for IP-s .2,.3,4,5 and that is it.
Can you help me setup this rule if it is not to much to ask pl!
I came to up to interface bridge filter so many options! I whill test it with my ISP just to be sure!

TECHNICALLY - the ISP shouldn't be ARP-ing for anything other than your public range on the interface towards you, but who knows what they're doing.... You shouldn't have to filter yourself. If you had a Cisco router, it would already be doing proxy arp....

Anywaqy, if you DO still want / need to filter arp - continue reading.

First - I've gone through the IP filters fairly carefully, and if ARP is possible to match on, I can't see it there. This makes sense because ARP is sort of "outside" of IP - In fact, IP is protocol 800 on an ethernet frame, and ARP is 806. It's a parallel universe to IP, so it kind of makes sense that an IP FILTER won't work on something that's not strictly an IP packet....

This means that if your WAN interface isn't already a bridge, then you're going to have to convert it if you want to filter arp. If you do this - you're going to be moving your WAN configuration from one interface to another (e.g.: ether1 -> bridge2)

THIS WILL TEMPORARILY BREAK EVERYTHING THAT USES THE INTERFACE NAME
- firewall rules
- router interface specs
- dhcp client configs
- pppoe client
- anything whatsoever which references the interface will just break until you update it to reference the bridge interface in stead.

I recommend that you print out the config, copy-and-paste it into an editor and do a string search for the current interface's name. Note anything that will need to be changed to the bridge interface - this will be your "to-do" list. It's not nearly as dangerous as I just made it sound - it doesn't lock up the router or anything - you just need to be aware that moving the IP address isn't the only action item in the procedure.

Once it's been converted to a bridge, then you can do the filter.

On the bridge - the filter is insanely simple: (bridge1 is the WAN in this example - be sure that's the WAN bridge whenver you add the rule)

This means "drop arp replies not about my wan IP range, that I am sending out on bridge1"
(this wouldn't filter arp replies going THROUGH the bridge, or being received ON the bridge)
This is just a way to keep proxy-arp from replying for any of your internal networks.
The mikrotik will HEAR arps for other stuff.
It will attempt to reply to requests for other things behind it (like your private IPs on the other customers, for instance, EVEN if they're subject to NAT) but this filter rule will drop them before they can make it onto the bridge and out ether1.

Thx again for detailed help!

Proxy-arp seams tricky but the options are to use this or try 1-1 nat, but like you sead , pppoe woud look more profesional!
I need to use these few public that I have smoehow!

Whay this arp poisoning hapend the first time I do not know, it sounds logical that my ISP not supposed arp anything but my public range.

So the key is to create bridge int. and put my wan port on it so I can use bridge filters !

I whill have to do this on site it is a remote location and things could go wrong!

Nothing else to do then but try it next week and I report back !

Ty again!!!

I just had an idea though in the mean time- you can set up a packet sniffer on your router and have it filter for ARP requests - capture to disk. Leave that running for several hours. Download it to your PC and open it with Wireshark.
See what IP addresses the ISP's router sends ARPs for. (or any other unknown devices on the WAN network)

Any for a destination behind your Mikrotik will be the ones you could poison with proxy-arp.

I whill try that , I did try quick mode and seen some other macs but I think they are from wifi radio devices fallback networks trying to setup long scan now!

Hi,

I analyze 1Mb file ( few min sinfing) see arp req form public IPs range /23 or even /22 and some private to!
That is not good is it

So long as your Mikrotik would use the WAN interface to reach those networks, it will not answer proxy-arp for those destinations.

But I thought i would see only arp for my /29 network, that woud be normal right, I woud definitely need to use bridge filter to be shure ?

@ZeroByte
Can you give me starting point to figuring ARP Proxy? I found it too useful...

I am no expert as you can see , but in short you have on/off option and is not that coplicated:D

http://en.wikipedia.org/wiki/Proxy_ARP
http://wiki.mikrotik.com/wiki/Manual:IP/ARP

It is all good until something bad hapens like in my situation!

It is all good until something bad hapens like in my situation!

I'm not in mood of translation....

Pretty much everything about proxy arp there is, I said it above.
(as far as technical explanations)

In a nutshell: proxy arp makes a remote IP address appear to be on a local network, but without bridging.

The typical use for proxy arp is for PPP concentrators or VPN concentrators. These devices usually have a pool of IP addresses which they assign to clients when they are connected. If you want to make these address pools use the same addresses as the LAN, then you use proxy arp so that hosts on the LAN will send traffic to the concentrator when they want to talk to PPP/VPN clients connected to it. To the rest of the LAN, the remote client just looks like any other local device on the network. Only if you look in the ARP table will you discover that these hosts all have the same MAC address, and that it's the same MAC address as the PPP server.

Of course, you could route a different set of IP addresses directly to the PPP server. In this case it will just route the IP to the customers - but the clients will have different IP Addresses than the LAN.

Heh - I've never read the Wikipedia article on proxy arp before. It sounds like I just wrote it myself.