NSLOOKUP behavior when utilizing Captive Portal
-
Hello! I'm trying to work out a slight issue I'm seeing when using a guest LAN in conjunction with Captive Portal
For reference, I'm working with the following here:
- Management LAN (For managing everything)
- Trusted LAN/VLAN (For all trusted devices)
- Guest LAN/VLAN (For guests)
I'm fine with both the management and trusted LANs being able to do nslookup..... I just don't want the guest LAN to be able to perform that on anything
If I manually setup the DHCP server for the guest LAN to use public DNS, all works well. I cannot do nslookup on anything within the network
However if I enable Captive Portal, the box is then unable to resolve to itself, and thus the ability to use Captive Portal is no longer available
Anyone deal with this in the past, and have a potential fix/workaround?
-
nslookup use the system's DNS to have host names resolved.
Typically, when you use a device on a captive portal, your device should use DHCP.
This "must" be the DNS situated on the device that handles also the portal = pfSense.
After all, a captive portal that woks fully transparent for the portal user should be using "https" login page. This means you need a certificate with the portal's (pfSense) host name (which means you have to use a existing 'offcial' domain name that you have to rent, get a certificate for it (with the acme.sh pfSense package) etc)
and it can never be some remote DNS server that can be aware of what devices you have locally (with RFC1918 network IPs).
I've informed the resolver that :
so when the portal clients starts resolving "portal.my-local-captive-portal-network.tld" it will receive "192.168.2.1" which is my pfSense portal network.
Also, I have to add to my portal RFC8910 support - way better, faster and essay to add.
Also : according to the manual "Troubleshooting Captive Portal" you "should not break DNS" :
You should have the remote DNS IPs to the "allowed IPs" list -and make sure that that server can give the correct answers, not sure if that's possible though if you use a public (euh ...private) remote DNS like 1.1.1.1 or 8.8.8.8.
@mpeterson0418 said in NSLOOKUP behavior when utilizing Captive Portal:
I just don't want the guest LAN to be able to perform that on anything
You want to 'hide' some of your LAN devices ? Even if the portal visitor has (knows) the host name of a device that exist on your LAN, and the local resolver gives it an RFC1918 LAN IP, your portal's firewall rules won't let it access it.
What can do / try :
Use the resolver for your fist two trusted LANs.
And the forwarder for your captive portal.
For this to work, unbound has to be bound (=listen) to only these two trusted LANs interfaces.
Dnsmasq, the forwarder, should listen to the portal interface only.
Needed captive portal overrides can be listen under the forwarder.
DNS caching won't be shared with unbound, the resolver, so the forwarder can't tell anything to the portal users about the other local networks.
Be ware : you probably have to remove the interlock build into the GUI that inhibits the forwarder's use if unbound is also, running, as no process can listen on the same interface using the same port (53). There is a forum thread that explains how to do that.Take note : All this breaks the KIS concept, and is imho, something that really isn't needed to be done.
Me, for example, don't give a sh*t about the fact that my hotel captive portal users find (dono how btw) that I have a NAS called diskstation2 or a printer called printer3 or some PC's on my trusted LAN. They will never be able to access it as they can't access my 1923.168.1.1/24 network.So :
@mpeterson0418 said in NSLOOKUP behavior when utilizing Captive Portal:
Anyone deal with this in the past, and have a potential fix/workaround?
if this issue isn't referenced or mentioned anywhere else (check this forum), then maybe the issue is wrong
I mean, be my guest : my disksation2 (with some DVD quality ripped movies on it ^^) has IP 192.168.1.33 : now : you, from WAN or my portal visitor on 192.168.2.0/24, what can you do ?
I could even give you the IPv6 of my disktation2, but the portal isn't IPv6 capable yet. -
@Gertjan said in NSLOOKUP behavior when utilizing Captive Portal:
Me, for example, don't give a sh*t about the fact that my hotel captive portal users find (dono how btw) that I have a NAS called diskstation2 or a printer called printer3 or some PC's on my trusted LAN. They will never be able to access it as they can't access my 1923.168.1.1/24 network.
Fair enough I guess. I mean look the odds of someone on the guest network actually looking up other addresses is slim to none. Thing is though...... although ARP has no insight of these clients (because they can't ping due to firewall rules), NMAP can STILL scan an internal client and pull info -
For a security guy - that's a concern
-
What / who is that host ? is that a web server accessible somewhere on your LAN ?
It's an ancient web server protocol = http, after all. Should that even exist to day (security issue by itself )??On your portal network, nmap creates 'packets' to be send to other hosts, other networks. Normally, nothing (that includes TCP, UDP, ICMP, etc ^^ ) can pass. So nmap won't receive any answer back.
-
That's my host on the internal management network I have here to access everything on. Running nmap on the guest client, "if" they have knowledge of the internal IP address it can still pull data
-
@mpeterson0418 said in NSLOOKUP behavior when utilizing Captive Portal:
That's my host on the internal management network
Your host ? You mean the pfSense web interface ?
Your other two interfaces can't access that host, even if some one knows that IP (network) exists.
That said, all depends on the the firewall rules you've created for the other two two (guest) interfaces. If you don't allow access to LAN from these interfaces, you're good. That's what a firewall is all about.edit : you can also add a firewall rule on the LAN interface, allowing web access to the GUI only from a single, or small set of LAN 'only' IPs.
-
Yeah firewall-wise nothing can really communicate across LANs except for the management LAN. I think maybe I'm just over worrying about guests having a potential exploit if they by some miracle stumbled onto the pfSense web interface IP
I pointed the rest of the LAN to a separate DNS server too so that's a bit more comforting. Also forgot to mention that this is all a virtualized lab so I'd guess even if users on the guest LAN can ping one another, having some client isolation options on an actual wireless AP would further prevent that
Think I'm good here. Thank you
-
@mpeterson0418 said in NSLOOKUP behavior when utilizing Captive Portal:
nothing can really communicate across LANs except for the management LAN.
Why is the management interface different ?
@mpeterson0418 said in NSLOOKUP behavior when utilizing Captive Portal:
pfSense web interface IP
The GUI web server listens on all (including the WAN and localhost !) pfSense interfaces.
Why can't some one from the Internet (= the WAN) interface access you pfSense GUI ? Look at the WAN rules : there are none : so no access.
Same thing goes for the all the extra (== OPTx= interface you've created) : initially : no rules. So no access to 'nothing' **.** one exception : DHCP will work, if you've set up an DHCP server on that LAN type interface.
-
I've always designed networks to have one internal management LAN should there ever be a need to adjust settings on a router/firewall. As a result I allow for it to have ping capabilities so that it can validate that there's communication. The VLANs that are built in conjunction are what separates everything. All the firewall rules are working as designated, and DHCP is pushing out the proper IPs based on how the switch is setup for tagging..... so I'm pretty sure it's just the inner workings for Captive Portal here within pfSense
If I stumble onto another solution I'll post it here - but I'm content with where things are at here
-
Be assured : my pfSense GUI is also only accessible from only the 'main' LAN, and not from the other non-trusted LANs which is a captive portal (I've a hotel here, that's worlds most none-trusted collection of network users ^^) and another LAN with 'other' stuff I don't trust like cameras and other "worse then Temu and Aliexpress"' combined stuff.
