IPv6 Hotspot (AAAA DNS Filter Workaround)

RouterOS General
1

When trying to setup a wireless internet hotspot based on mikrotik gear I had to notice that the hotspot feature does not handle ipv6 at all (tested with latest ros 6.33).
It is 2015, ipv6 is about 15 years old, ipv4 space is gone, and v6 is almost completely ignored by vital ros functions like hotspot.
I thought that the hotspot feature would restrict/allow (un)authorized devices based on their L2 mac address.
Of course redirecting the user to the captive portal website requires additional L3-7 handling.
The bad thing is not that redirection only works with ipv4.
As soon as you have implemented ipv6 it is completely open for everybody (i.e. also unauthorized clients)!
This means clients are having full ipv6 connectivity even if they have not authenticated yet.
At least this was my personal experience with mikrotik ipv6 hotspot.

Since I did not want to drop ipv6 I was thinking about how to workaround this bug.
Five years ago a script adding clients to ipv6 address list have been published here on this forum (link).
I thought about switching from l3 ipv6 addresses to adding l2 mac address to some kind of acl in order to better handle changing ipv6 addresses (privacy extensions).

However I wasn’t happy with this solution. I do not like dynamically changing the system configuration. (though it was still better than the current ros implementation of just completely allowing unauthenticated ipv6 traffic).

My idea: Let’s filter AAAA dns requests for unauthenticated clients.

Modern clients use to request A (ipv4) and AAAA (ipv6) records for a specific hostname (and then most likely prefer ipv6).
If we force end users to only use the local dns server and then filter AAAA queries arriving there, the user would only see ipv4 addresses (A record answers) while being unauthenticated - which would make ipv6 almost useless.
Skipping this AAAA filter for authenticated clients is enabling them full ipv6 connectivity.

Step 1: How to filter AAAA records
Well, in fact this was quite easy by using l7 filters.
All AAAA queries contain 0x0001c (type aaaa) 0x0001 (class in).
Since l7-filter strips out null bytes this magic string becomes 0x1c01.
So an appropriate l7-filter looks like this:

/ip firewall layer7-protocol
add name=DNS_AAAA regexp="\\x1C\\x01"

Step 2: Apply this l7-filter to unauthenticated hotspot clients.

/ip firewall filter
add action=reject chain=pre-hs-input comment="Filter AAAA UDP DNS Requests for unauth Hotspot Users" dst-port=64872 hotspot=!auth layer7-protocol=DNS_AAAA protocol=udp reject-with=icmp-protocol-unreachable
add action=reject chain=pre-hs-input comment="Filter AAAA TCP DNS Requests for unauth Hotspot Users" dst-port=64872 hotspot=!auth layer7-protocol=DNS_AAAA protocol=tcp reject-with=tcp-reset

Port 64872 is the local dns server port to where dns queries are nat’ed.

Step 3: Force use of local dns server by filtering outgoing dst port 53 in forward chain.
You most likely won’t need help on how to exactly achieve this if you have read so far.

Wasn’t that easy?

I mean this cannot be a real solution, but for me this looks like being the best workaround you can have right now when using mikrotik hotspots in ipv6 environments.

Feel free to comment on this if you have any ideas, or post your configs how you are currently managing ipv6 hotspots.

Just hoping providing such a dirty workaround does not prevent mikrotik from developing real native ipv6 support.

regards
David

2

Thanks dfroe.

It works, I do it your way.But I have one more question.Your step3: Force use of local dns server by filtering outgoing dst port 53 in forward chain.What’s mean? Does the client computer DNS server need to type the hotspot ip address?

Thanks again.

3

Thanks dfroe

It work, I do it your way.But I have one more question. Your step3: Force use of local dns server by filtering outgoing dst port 53 in forward chain. I don’t know what’s mean. Does the client computer dns server need to type hotspot ip address?

Thanks again.

4

Great to hear that this not only works for me :slight_smile:

You definitely do not have to change any user’s dns configuration or type any hotspot ip address.
You can (and imho should) still work with something like hotspot.example.com (fqdn) as redirect address.

If your client is actually ipv6-capable you will notice a short 2-4 second delay for the client resolver to wait for the aaaa timeout during the captive portal redirection, but that’s it (it will work).
If you want you can also further fine tune this by applying another l7 filter to not filter aaaa queries for the hotspot fqdn you are using, so routeros responds with nxdomain to the aaaa and client directly uses ipv4 to connect to the captive portal without waiting for the aaaa timeout. But that’s just minor fine tuning.

I am applying this dns filter to the input chain, i.e. it applies to all dns traffic which is destined to the routerboard itself.
So forcing users to use the routerboard as dns server just means that you block forwarded / outgoing port 53 traffic to other dns servers to make sure your users do not skip this filter by manually using their own dns server (e.g. 8.8.8.:sunglasses:.

Most likely you will have some kind of traffic filtering from hotspot to internet (to block smtp, irc, torrent, bgp etc.). Just add port 53 to be filtered by your forward chain from hotspot to internet. And of course make sure your hotspot clients will get the routerboard itself assigned as dns server.

5

Dear dfroe:

I understood your means.My hotspot works well under ipv6 enviroment in past few days.Thanks dfroe.
By the way I have another small trouble. My desktop computer or laptop work well. But I found that my cell phone or tablet(android system) will delay more than 30 seconds. I don’t know what’s reason.I am trying to solve this problem. :confused: Anyway thanks a lot !

6

Maybe you can give the described fine tuning a try to allow aaaa queries for your hotspot fqdn if this timeout leads to your delay.

Use the following configuration instead (adjust the hotspot name to the fqdn you are using for your captive portal).
This is a more sophisticated approach to my original posting in order to optimize potential delay when accessing the captive portal.

/ip firewall layer7-protocol
add name=DNS_AAAA regexp="\\x1C\\x01"
add name=DNS_Hotspot regexp=hotspot.example.org

/ip firewall
add chain=pre-hs-input hotspot=!auth protocol=udp dst-port=64872 action=jump jump-target=hs-unauth-dns comment="filter unauth udp dns requests"
add chain=pre-hs-input hotspot=!auth protocol=tcp dst-port=64872 action=jump jump-target=hs-unauth-dns comment="filter unauth tcp dns requests"
add chain=hs-unauth-dns layer7-protocol=DNS_Hotspot action=accept comment="allow hotspot dns requests"
add chain=hs-unauth-dns layer7-protocol=DNS_AAAA action=reject reject-with=icmp-protocol-unreachable comment="deny aaaa requests"
7

I typed your new code instead and the delay time reduced from 30 seconds to 10 seconds. The delay problem had been improved. It’s great ! :slight_smile: I will continue to study this issue.

8

Sounds good.

For me it takes about 3-5 seconds to get redirected to the portal which is absolutely fine. I think most users won’t complain (or even disconnect) when they see the portal in <10 seconds.

Do you use HTTPS captive portal? Can you try with plain HTTP?
When using HTTPS with a certificates issued by a trusted CA your browser will (and should) perform a CRL/OCSP check to verify whether the certificate was revoked by the CA. You may consider this for the untrusted allowed aaaa queries as well as ipv4 walled garden. However most browsers still silently continue if CRL/OCSP fails but it might be a source for delays.

Otherwise I would try to capture the traffic between client and routerboard to see what exactly is going on and what figure out what might cause the delay.

However, we have never been that far before regarding IPv6 hotspots. :slight_smile:

9

I never use https captive portal.I think that’s a little complicated. So,I told my co-workers "Do use https URL as your homepage,that will fail ".Maybe I should study tihs issue next time…

10

Thanks for this, but is not matching at all…
Do I need to place those rules specifically at some place ?
Any jumps rules needs to be made? Specially for the hs-unauth-dns chain

Thanks

11

For me this workaround still works as of RouterOS 6.44.3.
The chain pre-hs-input is processed for hotspot traffic destined to the RouterBoard. The constraints of these rules are that the user is not authenticated and traffic for the local dns service (port 64872) is matched. It then jumps to the newly created chain hs-unauth-dns where the AAAA records are filtered out.
You could make sure that your clients are actually using the RouterBoard as DNS server, traffic is matching pre-hs-input chain etc. no narrow down.