Category Archives: Tech

Tech

Disabling Mikrotik Hotspot DNS Proxying for Authenticated Users

My wireless ISP (WISP) uses the Mikrotik hotspot feature with RADIUS on the back end to authenticate our users. This implements a captive portal that redirects all DNS requests so that the user is taken to a login page if they’re not logged in. Once they log in once, the system associates their radio with their account, and they don’t have to log in anymore under normal circumstances.

However, once logged in, users still have all their DNS requests proxied through the routers. A lot of users want to use their own DNS (like OpenDNS or Google Public DNS), and that’s fine with me, but a user ran the namebench utility and found that their DNS was being forcibly proxied.

It took some hunting, but I finally found this post on the Mikrotik forums which details how to get around this. Basically:

  • The hotspot adds dynamic DNS redirect rules. If you go to /ip firewall nat and just print, these rules don’t show up. If you do print dynmic they do. The relevant lines are:

    2 D chain=hotspot action=redirect to-ports=64872 protocol=udp dst-port=53 log=no log-prefix=""
    3 D chain=hotspot action=redirect to-ports=64872 protocol=tcp dst-port=53 log=no log-prefix=""
  • We still want non-logged-in-users to have their DNS redirected, so we need to add something here that will enable authenticated hotspot users through. The magic incantation here (because it’s entries 2 and 3) is set 2,3 hotspot=!auth, which results in the following:

    2 D chain=hotspot action=redirect to-ports=64872 protocol=udp hotspot=!auth dst-port=53 log=no log-prefix=""
    3 D chain=hotspot action=redirect to-ports=64872 protocol=tcp hotspot=!auth dst-port=53 log=no log-prefix=""

And now namebench works as expected.

Preventing BGP Advertised Route Flapping in Mikrotik RouterOS

I am not an expert on this, I just wanted to document a problem I had and a solution I found today, in a concise way. Comments correcting me or suggesting better ways are very welcome.

I have a network running OSPF internally, and advertising routes to the upstream ISP over BGP at two separate edge routers (multi-homed, single ISP). We discovered last night that internally bringing down any of the subnets we advertise results in the dropping of those routes from the tables of the edge routers (as expected). This drops the advertisements. What we did NOT expect was that flap damping from upstream of us then null-routes that subnet for up to a few hours.

So, how do we retain our adaptive internal routing (OSPF) while avoiding route flap? I was a bit stumped about this, but I found a more complex article that describes a multi-homed BGP setup. A key part of that setup was a little trick to avoid this problem. Nameley, set up a static, black hole route for the subnet on the edge router, with maximum distance. This way, even if the OSPF route disappears, the router still “knows” a route to the subnet and won’t drop the advertisement.

For example, if you want to advertise the subnet 1.1.1.0/24, you should add a static route like


/ip route add dst-address=1.1.1.0/24 type=blackhole distance=254 comment="prevent flapping of the route over BGP"

I’ve tested it and it seems to work as expected. The route is not active as long as the OSPF route is in the routing table. If it disappears, the black hole route becomes active.

Comments? Suggestions?

Gun terminology

It seems like every time guns are in the news someone misuses terminology, usually in the name of making something sound scary. I’m posting these here so I can refer back to this later.

  • Semi-automatic = loads another round after a round is fired, requires a trigger pull for each shot. Basically any modern gun that’s not break-action, lever action, pump action, or revolver.
  • Fully automatic = can fire multiple shots with one trigger pull
  • Assault rifle = fully automatic rifle
  • Assault weapon = anti-gun term made up to make semi-automatic weapons sound more scary
  • Magazine = holds bullets
  • Clip = holds your pen in your shirt pocket (mostly)

Passing vlans through to KVM guests in Linux

If you want to be able to pass VLANs along to your linux guests from a linux KVM host, there’s a trick.

The most common way is to create special bridges for each vlan you want to pass, but that’s a big pain. Such an approach is detailed here.

After a surprisingly large amount of searching, I came across this article, which details the first way, and then another — the way to trunk vlans to KVM guests. Here’s the key quote that made me understand what I needed to do:

The difference is that when subinterfaces are defined on eth0, as noted previously Linux will strip the vlan tag, but when defined on the bridge, the vlan tags are kept.

Basically, if you put the vlans on the ethernet device, the tags will get stripped and not pass through the bridge to the guests. If you put the vlans on the bridge, the tags get passed through to the guest. So, a brief example.

You make a bridge br0 with eth0 on the kvm host. You then set up your guest to use br0 as its network interface (eth0 in the guest). You’d expect at this point that vlan tags would be passed. They won’t. However, if you want to pass vlan 2 through to the guest, then you add vlan 2 to br0 on the host (host: br0.2). Then, you add vlan 2 to eth0 on the guest (eth0.2). Boom. The vlan tag 2 is being passed through to eth0.2 on the guest.

Thanks so much to David Vassallo for figuring this out and posting it on his blog. Here’s hoping I can amplify the signal to help future seekers of this information.