Split DNS with Captive Portal
-
If I block all requests that aren't local, how will clients resolve requests once authenticated?
-
They will resolve through your pfSense DNS forwarder, which will be the only DNS server allowed in your network ;)
-
Maybe I'm confused. That is the exact setup I have now, but since the forwarder is functioning on the pfSense gateway IP, then all of the DNS requests from the client are actually getting forwarded pre-authentication. They are getting straight up connections outside of the captive portal via dns tunneling. That's what I want to stop.
-
Start reading here: https://www.google.fr/search?q=pfsense+DNS+tunneling&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla
official&client=firefox-a&channel=sb&gfe_rd=cr&ei=x-yGU4CcONCZ1AX74IDYBA for some ideas about the subject. -
Thanks, I actually have read a ton on this subject since discovering it months ago. Unfortunately, the pfSense documentation on blocking DNS to outside servers does not work with DNS tunneling. Here's a packet snip with a rule to block "everything" and they still get through.
14:34:23.639210 4c:82:cf:52:5a:0c > de:ad:60:e8:66:df, ethertype IPv4 (0x0800), length 601: (tos 0x0, ttl 64, id 24215, offset 0, flags [DF], proto TCP (6), length 587)
  192.168.30.100.38677 > 67.148.153.116.80: Flags [P.], cksum 0xcf79 (correct), seq 1672400699:1672401234, ack 350057706, win 137, options [nop,nop,TS val 46702950 ecr 3977917096], length 535
14:34:23.639299 de:ad:60:e8:66:df > 4c:82:cf:52:5a:0c, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 64, id 4969, offset 0, flags [DF], proto TCP (6), length 52)
  67.148.153.116.80 > 192.168.30.100.38677: Flags [.], cksum 0x9ce6 (correct), seq 1, ack 535, win 516, options [nop,nop,TS val 3977917510 ecr 46702950], length 0
14:34:23.650180 de:ad:60:e8:66:df > 4c:82:cf:52:5a:0c, ethertype IPv4 (0x0800), length 562: (tos 0x0, ttl 64, id 8121, offset 0, flags [DF], proto TCP (6), length 548)
  67.148.153.116.80 > 192.168.30.100.38677: Flags [P.], cksum 0x7a10 (correct), seq 1:497, ack 535, win 520, options [nop,nop,TS val 3977917511 ecr 46702950], length 496
14:34:23.711058 4c:82:cf:52:5a:0c > de:ad:60:e8:66:df, ethertype IPv4 (0x0800), length 77: (tos 0x0, ttl 64, id 41340, offset 0, flags [DF], proto UDP (17), length 63)
  192.168.30.100.41219 > 192.168.30.1.53: [udp sum ok] 36848+ A? www.dishaccess.tv. (35)
14:34:23.711346 de:ad:60:e8:66:df > 4c:82:cf:52:5a:0c, ethertype IPv4 (0x0800), length 175: (tos 0x0, ttl 64, id 63996, offset 0, flags [none], proto UDP (17), length 161)
  192.168.30.1.53 > 192.168.30.100.41219: [udp sum ok] 36848 q: A? www.dishaccess.tv. 3/0/0 www.dishaccess.tv. CNAME iptv-catalog.echostarcdn.com., iptv-catalog.echostarcdn.com. CNAME dc-catalog.echostarcdn.com., dc-catalog.echostarcdn.com. A 67.148.153.243 (133)
14:34:24.663393 4c:82:cf:52:5a:0c > de:ad:60:e8:66:df, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
  192.168.30.100 > 74.125.20.103: ICMP echo request, id 1536, seq 256, length 64 -
Well, I figure that there must be something wrong on a pre-auth or root DNS packet handling by pfSense. Even with an ipv4 block all tcp/udp rule on the guest wifi interface, dns tunneling packets still get through since the endpoint has their own authoritative servers. I've stuck in a pfSense bug. Hopefully it can be addressed by a developer soon.
https://redmine.pfsense.org/issues/3683
-
I figured I'd write back to say how I solved this. As it stands, I'm 100% confident that pfSense captive portals have a DNS tunneling security hole. Apparently the pfSense bug report people didn't agree even though my packet capture clearly shows a direct connection from my guest vlan to an outside IP without authentication and with a complete block all rule in place.
In the end, I had to remove pfSense from my guest wifi vlan and use packetfence to administer clients. My neighbor is still connecting, but packetfence is properly stopping remote dns requests until authentication.
-
Hi,
I'm not an sniffer expert, but I'm trying to understand.
This part :14:34:23.639210 4c:82:cf:52:5a:0c > de:ad:60:e8:66:df, ethertype IPv4 (0x0800), length 601: (tos 0x0, ttl 64, id 24215, offset 0, flags [DF], proto TCP (6), length 587)
  192.168.30.100.38677 > 67.148.153.116.80: Flags [P.], cksum 0xcf79 (correct), seq 1672400699:1672401234, ack 350057706, win 137, options [nop,nop,TS val 46702950 ecr 3977917096], length 535
14:34:23.639299 de:ad:60:e8:66:df > 4c:82:cf:52:5a:0c, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 64, id 4969, offset 0, flags [DF], proto TCP (6), length 52)
  67.148.153.116.80 > 192.168.30.100.38677: Flags [.], cksum 0x9ce6 (correct), seq 1, ack 535, win 516, options [nop,nop,TS val 3977917510 ecr 46702950], length 0
14:34:23.650180 de:ad:60:e8:66:df > 4c:82:cf:52:5a:0c, ethertype IPv4 (0x0800), length 562: (tos 0x0, ttl 64, id 8121, offset 0, flags [DF], proto TCP (6), length 548)
  67.148.153.116.80 > 192.168.30.100.38677: Flags [P.], cksum 0x7a10 (correct), seq 1:497, ack 535, win 520, options [nop,nop,TS val 3977917511 ecr 46702950], length 496
is part of an existing TCP ipv4 connection between a device "192.168.30.100" (the neighbor) and a non-identified web server somewhere on the net (67.148.153.116)
I really would like to see the start of this connection.
For what I know, no one can just to send TCP all over the net when using the portal of pfSense.I expected to see some massive UDP (destination using port 53 == DNS on the pfSEnse) data streams ….
And see the same trafic on the WAN, coming the DNS-forwarder of pfSense NOT doing any typical DNS request to YOUR Internet's supplier DNS (hard locked) but a chosen service somewhere on the net that un-tunnels the pakect.Something that should like some kind of VPN .....
The second part is classic:
14:34:23.711058 4c:82:cf:52:5a:0c > de:ad:60:e8:66:df, ethertype IPv4 (0x0800), length 77: (tos 0x0, ttl 64, id 41340, offset 0, flags [DF], proto UDP (17), length 63)
  192.168.30.100.41219 > 192.168.30.1.53: [udp sum ok] 36848+ A? www.dishaccess.tv. (35)
14:34:23.711346 de:ad:60:e8:66:df > 4c:82:cf:52:5a:0c, ethertype IPv4 (0x0800), length 175: (tos 0x0, ttl 64, id 63996, offset 0, flags [none], proto UDP (17), length 161)
  192.168.30.1.53 > 192.168.30.100.41219: [udp sum ok] 36848 q: A? www.dishaccess.tv. 3/0/0 www.dishaccess.tv. CNAME iptv-catalog.echostarcdn.com., iptv-catalog.echostarcdn.com. CNAME dc-catalog.echostarcdn.com., dc-catalog.echostarcdn.com. A 67.148.153.243 (133)
14:34:24.663393 4c:82:cf:52:5a:0c > de:ad:60:e8:66:df, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
  192.168.30.100 > 74.125.20.103: ICMP echo request, id 1536, seq 256, length 64
is easy: your neigbour's device is doing a DNS name request to your pfSense (192.168.30.1.53).
pfSense is replying ….Maybe to late, but do you have a
ipfw -N -x cpzone show
and
ipfw -N -x cpzone table all list(cpzone = is the name of your zone)
edit: Ok, I saw the more detailed https://redmine.pfsense.org/issues/3683
I understand that you can't go to the neighbor and ask: "Hi, dudu, surfing goes well ?".On the other hand, pfSense offers a free ride .... that info would be on CNN right now.
-
The part that looks like a connection to 67.148.153.116 or any other Internet IP from the pre-auth device is actually the connection to load the portal page. Every CP has to hijack that initial TCP connection, doing NAT translation on the firewall in such a way that the firewall's own traffic looks like it's from elsewhere (like that 67.x) and issue a redirect to the portal page.
The default dnsmasq and captive portal config will return DNS replies from the Internet. That means you can potentially do IP over DNS tunneling (with something like iodine), though that's a really, really crappy way to get Internet, it's mediocre at best for SSH and that's about the best you'll get out of it. Though it's pretty clear from that packet capture that you're dreaming up something that isn't actually happening (IP over DNS looks much diff from anything there).
-
Gertjan:
I've got a baby on the way and have been pretty busy as of late, so it could take me a while to get back to testing this and provide the results of your posted commands. I've also got a buddy down the street from me who will assist in setting up a remote iodine server so we can test the tunneling techniques against pfSense.
cmb:
You're correct about the packet capture not showing any dns tunneling results. I must have attached the wrong capture that day. I was running late for meeting at work and had about 10 tabs open with various packet captures. I did have one that showed more details about the initial connection, but I apparently attached the wrong capture.
I'm not the only one that has had this issue though –> https://forum.pfsense.org/index.php?topic=65739.0
Digging more into the location requests, I believe this could be hardware fallback technique done by dish network for subscribers to properly pay for their pay-per-view purchases. Search results over the net show all kinds of results with people noticing that certain Dish devices are establishing a lot of DNS connections back to homebase.
I'll post back on this thread later after my buddy gets his side of the iodine setup and I have some more detailed packet captures to provide.
For right now, packetfence is fitting the bill and I don't show any established connections to 67.148.153.116 in the table states anymore. And he's still hanging off my guest vlan.
