Allow Winbox for some PPPoE users

I’m testing a combination of hotspot and PPPoE setup (with User Manager as the common username storage), and while it works fine in terms of giving everyone internet access, there’s an annoying issue I can’t solve…

Some users are supposed to have access to the router from the local network (I’m marking their IPs in an address list called “power”). After some tinkering, I have rules to let only hotspot users in that address list have Winbox access, but with PPPoE… nobody has any access to the router, ever.

How to enable Winbox access over PPPoE for some users? I’m very new to PPPoE, so I have no idea… my additional hotspot rules certainly are not the cause, as there was no access before that either.

Here’s the entire router’s export (ready to replace any existing configuration; “admin” is the username I’m trying to give access to):

# RouterOS 6.27
# RB951Ui-2HnD
/interface bridge
remove [find]
add admin-mac=D4:CA:6D:F5:C3:9B auto-mac=no name=bridge-local
/interface ethernet
set [ find default-name=ether1 ] name=ether1-gateway
set [ find default-name=ether2 ] arp=reply-only name=ether2-master-local
set [ find default-name=ether3 ] arp=reply-only master-port=\
    ether2-master-local name=ether3-slave-local
set [ find default-name=ether4 ] arp=reply-only master-port=\
    ether2-master-local name=ether4-slave-local
set [ find default-name=ether5 ] arp=reply-only master-port=\
    ether2-master-local name=ether5-slave-local
/interface wireless
set [ find default-name=wlan1 ] arp=reply-only band=2ghz-b/g/n channel-width=\
    20/40mhz-Ce country=bulgaria default-forwarding=no distance=indoors \
    frequency=auto l2mtu=1600 mode=ap-bridge ssid=FFFF wireless-protocol=\
    802.11
/ip neighbor discovery
set ether1-gateway discover=no
/interface wireless security-profiles
set [ find default=yes ] authentication-types=wpa2-eap mode=dynamic-keys \
    radius-eap-accounting=yes
/queue simple
remove [find]
add max-limit=100M/100M name=total queue=default/default target=bridge-local
add name=total-rogue parent=total queue=default/default target=bridge-local
/radius incoming
set accept=yes
/radius
remove [find]
add address=127.0.0.1 secret=1234 service=ppp,hotspot
/tool user-manager customer
set admin access=\
    own-routers,own-users,own-profiles,own-limits,config-payment-gw city=\
    Plovdiv country=Bulgaria currency=BGN time-zone=+02:00
/tool user-manager profile
remove [find]
add name=Unlimited name-for-users=Unlimited override-shared-users=unlimited \
    owner=admin price=0 starts-at=logon validity=0s
add name=cheap name-for-users="Low offer" override-shared-users=unlimited \
    owner=admin price=10 starts-at=logon validity=4w2d
/tool user-manager profile limitation
remove [find]
add address-list="" download-limit=0B group-name="" ip-pool="" name=\
    low-limits owner=admin rate-limit-min-rx=10485760B rate-limit-min-tx=\
    10485760B rate-limit-rx=10485760B rate-limit-tx=10485760B transfer-limit=\
    0B upload-limit=0B uptime-limit=0s
add address-list=power download-limit=0B group-name="" ip-pool="" name=\
    no-limits owner=admin transfer-limit=0B upload-limit=0B uptime-limit=0s
/tool user-manager profile profile-limitation
remove [find]
add from-time=0s limitation=low-limits profile=cheap till-time=23h59m59s \
    weekdays=sunday,monday,tuesday,wednesday,thursday,friday,saturday
add from-time=0s limitation=no-limits profile=Unlimited till-time=23h59m59s \
    weekdays=sunday,monday,tuesday,wednesday,thursday,friday,saturday
/tool user-manager router
remove [find]
add coa-port=1700 customer=admin disabled=no ip-address=127.0.0.1 log="" \
    name=localhost shared-secret=1234 use-coa=no
/tool user-manager user
remove [find]
add customer=admin disabled=no name=emily password=emily1234 shared-users=\
    unlimited wireless-enc-algo=aes-ccm wireless-enc-key=emily1234 \
    wireless-psk=emily1234
add customer=admin disabled=no name=admin password="" shared-users=unlimited \
    wireless-enc-algo=aes-ccm wireless-enc-key="" wireless-psk=""
create-and-activate-profile admin customer=admin profile=Unlimited
create-and-activate-profile emily customer=admin profile=cheap
:delay 2s
/ip hotspot profile
set [ find default=yes ] dns-name=router.local hotspot-address=192.168.88.1 \
    nas-port-type=ethernet use-radius=yes
/ip pool
remove [find]
add name=dhcp ranges=192.168.88.10-192.168.88.254
/ip dhcp-server
remove [find]
add add-arp=yes address-pool=dhcp bootp-lease-time=lease-time bootp-support=\
    dynamic disabled=no interface=bridge-local name=default
/ip hotspot
remove [find]
add address-pool=dhcp addresses-per-mac=1 disabled=no idle-timeout=10m \
    interface=bridge-local keepalive-timeout=1m name=hotspot1
/ip hotspot user profile
set [ find default=yes ] address-list=authenticated,hotspot \
    insert-queue-before=total-rogue on-logout=":if (\"user request\"=\$cause) \
    do={\r\
    \n    /ip hotspot cookie remove [find user=\$user]\r\
    \n}" parent-queue=total queue-type=default
/ppp profile
set "default" address-list=authenticated,pppoe insert-queue-before=total-rogue \
    local-address=dhcp parent-queue=total queue-type=default remote-address=\
    dhcp use-ipv6=default
/ppp aaa
set use-radius=yes
/interface bridge port
remove [find]
add bridge=bridge-local interface=ether2-master-local
add bridge=bridge-local interface=wlan1
/interface pppoe-server server
remove [find]
add authentication=chap,mschap1,mschap2 disabled=no interface=bridge-local \
    one-session-per-host=yes service-name=pppoe1
/ip address
remove [find]
add address=192.168.88.1/24 comment="default configuration" interface=\
    ether2-master-local network=192.168.88.0
/ip dhcp-client
remove [find]
add comment="default configuration" dhcp-options=hostname,clientid disabled=\
    no interface=ether1-gateway
/ip dhcp-server network
remove [find]
add address=192.168.88.0/24 comment="default configuration" gateway=\
    192.168.88.1 netmask=24
/ip dns
set allow-remote-requests=yes
/ip dns static
remove [find]
add address=192.168.88.1 name=router
/ip cloud
set ddns-enabled=yes update-time=yes
/ip firewall filter
remove [find dynamic=no]
:delay 2s
add action=jump chain=pre-hs-input jump-target=alt-input src-address-list=\
    authenticated
add action=return chain=pre-hs-input
add action=return chain=alt-input src-address-list=!power
add chain=alt-input
add action=drop chain=hs-input
add action=passthrough chain=unused-hs-chain comment=\
    "place hotspot rules here" disabled=yes
add chain=input comment="default configuration" protocol=icmp
add chain=input comment="default configuration" connection-state=\
    established,related
add action=drop chain=input comment="default configuration" in-interface=\
    ether1-gateway
add chain=forward comment="default configuration" connection-state=\
    established,related
add action=drop chain=forward comment="default configuration" \
    connection-state=invalid
add action=drop chain=forward comment="default configuration" \
    connection-nat-state=!dstnat connection-state=new in-interface=\
    ether1-gateway
/ip firewall nat
remove [find dynamic=no]
:delay 2s
add action=passthrough chain=unused-hs-chain comment=\
    "place hotspot rules here" disabled=yes
add action=masquerade chain=srcnat comment="default configuration" \
    out-interface=ether1-gateway
/ip upnp interfaces
remove [find]
add interface=bridge-local type=internal
add interface=ether1-gateway type=external
/ip upnp
set enabled=yes
/system clock
set time-zone-name=Europe/Sofia
/system lcd
set contrast=0 enabled=no port=parallel type=24x4
/system lcd page
set time disabled=yes display-time=5s
set resources disabled=yes display-time=5s
set uptime disabled=yes display-time=5s
set packets disabled=yes display-time=5s
set bits disabled=yes display-time=5s
set version disabled=yes display-time=5s
set identity disabled=yes display-time=5s
set bridge-local disabled=yes display-time=5s
set wlan1 disabled=yes display-time=5s
set ether1-gateway disabled=yes display-time=5s
set ether2-master-local disabled=yes display-time=5s
set ether3-slave-local disabled=yes display-time=5s
set ether4-slave-local disabled=yes display-time=5s
set ether5-slave-local disabled=yes display-time=5s
/tool mac-server
remove [find default=no]
set [ find default=yes ] disabled=yes
add interface=ether2-master-local
add interface=wlan1
/tool mac-server mac-winbox
remove [find default=no]
set [ find default=yes ] disabled=yes
add interface=ether2-master-local
add interface=wlan1

After some debugging in the firewall, I’m seeing that what’s going on is that even if I’m authenticated via PPPoE, the DHCP server has still given me another IP prior to login. Winbox uses that IP as its source IP, instead of the PPPoE IP. And because the PPPoE and unauthenticated IPs are different, the rules that would otherwise let power PPPoE users in are not matched.

So I guess the real question now becomes… Is there a way to somehow either force a removal on the DHCP lease on login (so that the PC is forced to use the PPPoE IP)? Or perhaps add the DHCP lease to a whitelist, but only AFTER successful PPPoE login? Or perhaps how to check unauthenticated DHCP entries’ MACs against MAC addresses of power PPPoE, and let them in on a match?

I would just use PPPoE to assign the IP addresses and forget about DHCP entirely.
PPP is designed to negotiate local and remote IP addresses as part of the establishment of a session.
The neat thing is that local and remote IP don’t even have to be in the same subnet as each other.
(the first time I saw that, it blew my mind)

So then you can assign a “power user” IP to each “power user” profile, and you’re done.

If you need both (say some hosts don’t use PPPoE but you want them on the same LAN), perhaps both PPPoE users and DHCP server could be set to use the same IP pool.
(that would be a neat way to use the whole network, but not double-assign any addresses)

That is exactly what I’m doing, exactly for that reason.

The primary set of devices that would be connecting and don’t support PPPoE (as far as I know) are phones and tablets. Some users have their own CPE routers (with PPPoE support), but others don’t, and I want to cover them too.*

The PPPoE server and hotspot do use the same pool… But the DHCP IP is not reused by PPPoE, despite being in the same pool, and given to the same MAC address. Ultimately, the host has two IPs - one from DHCP, and one from PPPoE… And apparently, when connecting to the 192.168.88.0/24 subnet, Windows prefers to use the DHCP IP.

\

  • In my production network currently, I simply use static IPs, fixed to MAC addresses… While this makes it possible for everybody to connect, it’s very inconvenient, both for users when/if they change devices or add one to their roster, and for me, in that getting the MAC address of phones and tablets in particular, can sometimes be tricky, not to mention entering static IP info… Plus the fact that “I” have to do it, since many end users can’t… And some users roam between my network (at home) and another one (at their workplace), and connect on the same adapter, requiring them to consciously “switch” between networks with a program.

I would have guessed that Windows would prefer straight IP to pppoe (for one thing, the MTU is the full 1500).
A user could modify the “priority” on the network connection profile to change this behavior if they wanted. (the default is ‘auto’). It’s surprising that the pool won’t recycle addresses between the two - and they’re using the same pool, not two pools with the same range configured? This makes me want to lab this up (it’s so intriguing)

As for the various access issues - I used to work for a company that had an extensive deployment of hotspots in beach resort hotels/condos. That is one part of that job that I am thankful every morning not to have responsibility for. Captive portals have their place, but they tend to cause troubles.

If I still worked at my last job, I would be trying to migrate the properties to a dual-ssid system where the open wifi was a hotspot that leads to a registration / instructions screen, but once registered, it would instruct users to use the wpa2-protected SSID, with enterprise authentication to protect that network at the AP, and no hotspot.

Please do :smiley: .

That’s why I don’t intend to use “just” hotspot. I actually tried it once, and found most such troubles in just a few days.

I plan to also do just that, as soon as User Manager support WPA2-EAP authentication… I know I could do it today with a separate RADIUS server, but I have just one central router (every other router is just an AP), so it doesn’t seem right to add a separate device in. Not to mention that a separate device would likely cause various new sorts of issues (e.g. when the RADIUS server goes down, but not the router or vice versa).

Under normal circumstances, RADIUS isn’t a huge CPU drain - ever thought of running freeradius on a metarouter WRT image? Then its fate and the router’s would be the same. (evil laugh)

We used freeradius with a free frontend called daloradius for our EAP clients. You could even use a realm configuration to proxy these requests back to Userman… tempted yet? :slight_smile:

My bigger worry is with memory on the routerboard, with its total being 128MB.

Also, my production router is an x86 PC with 512MB RAM and a single core CPU. Since it’s x86, it means I have to run a “full” Linux with FreeRADIUS on it, meaning more memory and CPU… And a different configuration to be learned (though I can remedy that last one with a GNS3 lab setup…).

I’m not much into Linux overall… Could you recommend any lightweight distribution that is still capable enough to run FreeRADIUS and a management frontend? I know of Ubuntu server (I mean, I’ve worked with the desktop version a little… emphasis on “little”), but that seems a little too much on the heavy side.

Wait, what? You mean, like authenticate against User Manager normally… But authenticate against FreeRADIUS on EAP requests only, all while sharing the same set of usernames and passwords inside User Manager?

Hmm… Sounds like a fun experiment, but “for real”… Nah. If FreeRADIUS enters the mix, also using User Manager sounds pointless. I mean, FreeRADIUS doesn’t have the active session limitation of User Manager, so if it’s there anyway, it’s better for it to be used to its full potential.

Daloradius was the front-end that was installed on the RADIUS box we used.
We had this 4G wireless sector gear, and the endpoints were admitted to the sector via eap-tls.
The vendor gave us a pre-configured linux vmware image with freeradius configured to support eap-tls, and this patch they had to do for endpoint ids (irrelevant to this situation).

The front-end was kind of nice, but had its quirks.
Freeradius is second only to Sendmail for “evil configuration files” - once it IS set up with MySQL (or whatever back-end) then managing users in Daloradius was a breeze.

All in all, if you’re not familiar with Linux, then this could be a lot to swallow all at once, although I would imagine that going into the ubuntu “app store” and telling it to install the package daloradius will almost certainly launch all of the dependencies to install freeradius, apache, mysql, and have a working-out-of-the-box default installation.
(Cacti did that for me as well - it felt like cheating)

Here’s my report so far:
dhcp-pppoe-lab.png
It behaved about as I expected, and seems to easily handle both dhcp and pppoe servers pulling from the same pool.

In my first configuration where I bridged PPPoE onto the same LAN, My cisco router went insane when it saw the same subnet on DHCP as it had already gotten from pppoe. :laughing:

I didn’t bother setting up hotspot though - no easy way to test it (no virtual PCs in my GNS3 environment - just vpcs)

In general, I would suggest that at the very least, PPPoE clients come in on a different VLAN. (shown in this example)
This way, users who have dynamic IP set to their LAN profile, and then run PPPoE don’t get double IP confusion.
(I.e. if they set up pppoe client on their windows PC, they can connect to PPPoE ssid and then run pppoe client)
DHCP will just fail for them when they connect to the PPPoE ssid, and they won’t have to disable DHCP to use PPPoE.

Here’s my setup for this - and everybody can still ping everybody else as normal.

[admin@Mikrotik-1] > export compact
# mar/30/2015 14:47:59 by RouterOS 6.27
#
/interface ethernet
set [ find default-name=ether1 ] arp=proxy-arp
/interface vlan
add interface=ether1 name=E1-PPPoE vlan-id=10
/ip pool
add name=dhcp_pool1 ranges=192.168.1.32-192.168.1.254
/ip dhcp-server
add address-pool=dhcp_pool1 disabled=no interface=ether1 lease-time=3d name=dhcp1
/ppp profile
set 0 local-address=192.168.1.1 remote-address=dhcp_pool1
/interface pppoe-server server
add authentication=pap disabled=no interface=E1-PPPoE max-mru=1480 max-mtu=\
    1480 mrru=1600 service-name=service1
/ip address
add address=192.168.1.1/24 interface=ether1 network=192.168.1.0
add address=10.1.1.1/24 interface=ether5 network=10.1.1.0 comment="management"
/ip dhcp-server network
add address=192.168.1.0/24 dns-server=192.168.1.1 gateway=192.168.1.1
/ppp secret
add name=r1 password=r1 remote-address=192.168.1.2 service=pppoe
add name=r1a password=r1a service=pppoe

If the pppoe client uses r1a to connect, it gets an address from the pool. If it uses r1, then it gets the static address specific to that profile. (if using RADIUS, you would specify framed-ip-address=xxxx for a static customer, and nothing for dynamic ones)

But if the subnet of both VLANs is the same, wouldn’t Windows still end up connecting over the DHCP VLAN?

Routers aren’t really a problem, since they usually perform either PPPoE scan or DHCP scan, not both. Plus, you can’t access Winbox “directly” from a router anyway, just with a device behind it… And if the router is connected via PPPoE, devices behind it (that are NAT-ed) will access the router over PPPoE anyway, so no problems there either.

The only real issue is with Windows PCs, which some people (myself included) might end up using with PPPoE due to the more aggressive password remembering and connection, compared to a captive portal… Not to mention the infamous HTTPS issue…

But it’s not - there is no DHCP running on the PPPoE connection in my example. That’s why I built pppoe on a separate vlan - so that the DHCP would fail (no dhcp on the pppoe service vlan) but pppoe will get its IP from IPCP (a negotiation phase of a PPP connection). Doing it like this keeps you from having to turn off dhcp client on your windows machines.

For the sake of interest, here is how ipcp negotiates the IP address.
A client connects, and authenticates successfully.
IPCP begins and client says “could I have x.x.x.x as my IP?” (if the client doesn’t care, it uses 0.0.0.0 here)
If the server agrees, then it says ACK.
If not, then it says “NACK - use this: y.y.y.y”
Then client starts over - “could I have y.y.y.y as my IP?”
Server then says “ACK” (and then thinks to itself - that’s right. Who’s yo daddy?)

Basically, I would consider PPPoE as a way to bypass hotspot for special users (myself, power users, techs, etc) and possibly a way to tie some IP routes to a particular account.

Oh… I see now, looking closer… You’ve made not just the router, but the switch too with a VLAN.

That could work, except that I don’t have a single smart switch in my topology, and even if I did, they’d only be in certain key places, not necessarily right next to the PPPoE connected PCs.

I guess I’ll just have to bite the bullet, and use a separate router that connects over PPPoE (like how other users would have CPE routers), and manage Winbox behind that only. And if I need to troubleshoot from other locations, I’d just use hotspot for that one time.

One final note - if your APs support vlan tags for second SSIDs, you could create a pppoe-only SSID. Any unmanaged switch in the middle should just happily forward the tagged packets without bothering the vlans. If that’s not feasible, then it’s not feasible. I’m just trying to help you reach your goal. :slight_smile:

That would work when accessing via WiFi, though not via (arbitrary) Ethernet. Still, it’s a good start (until EAP…) I guess.

As for whether my APs support it… Most are TP-Link routers/APs (and a few other brands, with one each…) with their built in software… But if push comes to shove, I can always replace the software with DD-WRT or Open WRT, where that’s supported.

nana - nana - nana - nana - CAPSMAAAAAN!
NANA-NaNa-Nana-nana CAPSMAAAAAN!
<POW!>
<Zowie!>
<Thwack!>
NAna nana nana nana na! CAPS MAAAAN!
(sorry, I couldn’t resist - I’m pretty silly in real life)

If you’re wondering what the heck I’m doing -
https://www.youtube.com/watch?v=1jgE-lrfZ3k


On a serious note, your comment about wired, non-pppoe clients is spot on.
This makes me wonder if dot1x port security is a planned feature for CRS or similar.
First hop security is a big deal these days with BYOD and all…

Great Idea…