Allowed Hostname Wildcards
-
So, is there any way to allow wildcards for hostnames? We want TeamViewer to be able to get through the captive portal firewall and it uses tons of servers like server1400.teamviewer.com or server1101.teamviewer.com. When we tried to add wildcards with *'s %'s and $'s it tossed an error.
-
No. There is not.
The only way that hostnames work is because they can be (re)resolved to definite IPs. A wildcard cannot.
That would require doing reverse DNS checks for every single IP that was accessed and also relies on reverse DNS matching. Not feasible on any kind of scale.
-
I was thinking about something more elegant. Instead of the hostname system being a pseudo IP entry table, how about a system that checks to see if the attempted ip connection reverses to an allowed hostname? So, we are talking about true hostname whitelisting here instead of just another way to add IPs.
-
See above, re: does not scale. I mentioned exactly what you are describing and why it doesn't work.
You cannot possibly do a reverse DNS request on every IP accessed by clients and hope to have it work well. It would be slow, add a ton of overhead, and would not be accurate.
-
Well:
A) Wouldn't this only check new connections not all connections? I'm not sure how that would be massively intense. Cache previously looked up entries to make things quicker. And again, you don't have to look everything up, only lookup what the client is attempting to connect to.
B) I'm not sure I care if it scales. The system is designed to be firewalled from everything except for remote connections, anti-virus updates, and one email server. Although for another purpose it might not work so well, this isn't designed to scale massively. I have previously seen other systems that do exactly what I'm talking about without even being a full blown version of BSD. -
Well you might not care if it scales - but everyone else would. :-)
There are clients using the portal with hundreds (or thousands) of clients and extremely large numbers of connections. And even if you cache DNS results, it doesn't help you in most cases.
Say you want to allow access to *.microsoft.com - well there are plenty (hundreds? thousands?) of sub-sites that forward resolve from something.microsoft.com to an IP, but in reverse they are randomly pulled from some CDN pool and have no way to track them back to something.microsoft.com
What you are after is better handled by a proxy which can inspect the host headers that an HTTP client tries to use to control access.
Relying on reverse DNS for this is not reliable, and would only lead to further frustration.
Here is but one example:
$ host www.youtube.com www.youtube.com is an alias for youtube-ui.l.google.com. youtube-ui.l.google.com has address 74.125.225.40 youtube-ui.l.google.com has address 74.125.225.47 youtube-ui.l.google.com has address 74.125.225.33 youtube-ui.l.google.com has address 74.125.225.36 youtube-ui.l.google.com has address 74.125.225.44 youtube-ui.l.google.com has address 74.125.225.41 youtube-ui.l.google.com has address 74.125.225.43 youtube-ui.l.google.com has address 74.125.225.37 youtube-ui.l.google.com has address 74.125.225.46 youtube-ui.l.google.com has address 74.125.225.34 youtube-ui.l.google.com has address 74.125.225.42 youtube-ui.l.google.com has address 74.125.225.38 youtube-ui.l.google.com has address 74.125.225.32 youtube-ui.l.google.com has address 74.125.225.39 youtube-ui.l.google.com has address 74.125.225.35 youtube-ui.l.google.com has address 74.125.225.45 $ host 74.125.225.38 38.225.125.74.in-addr.arpa domain name pointer ord08s06-in-f6.1e100.net.If someone tried to allow *.youtube.com or even *.google.com it would just fail. It isn't practical.
If you are doing something non-HTTP you are better off looking up the IP blocks owned by a company you want to allow and going that way.
-
Hmmm… you have something of a point there.
What would be the easiest way to lookup IP blocks owned by a company?
-
Depends on the company. Some, like Facebook, are all in nice blocks. You can find an IP, look it up via whois to find the netblock, then check ARIN or other registries to find the IPs assigned to them. Others aren't so easy if they just have random IPs at colos all over the world.
Here's an example for Facebook:
$ host www.facebook.com www.facebook.com has address 69.171.224.11$ whois -a 69.171.224.11 [...] NetRange: 69.171.224.0 - 69.171.255.255 CIDR: 69.171.224.0/19 OriginAS: AS32934 NetName: TFBNET3 NetHandle: NET-69-171-224-0-1 Parent: NET-69-0-0-0-0 NetType: Direct Assignment RegDate: 2010-08-05 Updated: 2010-10-15 Ref: http://whois.arin.net/rest/net/NET-69-171-224-0-1 OrgName: Facebook, Inc. OrgId: THEFA-3 Address: 1601 S. California Ave City: Palo Alto StateProv: CA PostalCode: 94304 Country: US RegDate: 2004-08-11 Updated: 2011-09-24 Ref: http://whois.arin.net/rest/org/THEFA-3 OrgAbuseHandle: OPERA82-ARIN OrgAbuseName: Operations OrgAbusePhone: +1-650-543-4800 OrgAbuseEmail: domain@facebook.com OrgAbuseRef: http://whois.arin.net/rest/poc/OPERA82-ARIN OrgTechHandle: OPERA82-ARIN OrgTechName: Operations OrgTechPhone: +1-650-543-4800 OrgTechEmail: domain@facebook.com OrgTechRef: http://whois.arin.net/rest/poc/OPERA82-ARINThen open up http://whois.arin.net/rest/org/THEFA-3 and click "Related networks"
-
I was hoping that wasn't the only way. Crap.
TeamViewer is from Germany so it's RIPE.
-
Here is a question for you…
Does pfSense support setting up a password protected proxy system so we can program TeamViewer and other allowed programs to byass the captive portal by going through the proxy with a username/password?
-
We do actually have support for wildcard hostnames in a private build right now, it's still under development and being tested, but it appears to work nicely. It just snoops all the DNS responses, and if you allow *.example.com it allows every IP that's returned via DNS for *.example.com. No extra overhead in doing additional DNS lookups or anything else crazy like that.
When or whether that hits the open source side, I'm not sure yet.
Does pfSense support setting up a password protected proxy system so we can program TeamViewer and other allowed programs to byass the captive portal by going through the proxy with a username/password?
Could probably do that with Squid.
-
@cmb:
We do actually have support for wildcard hostnames in a private build right now, it's still under development and being tested, but it appears to work nicely. It just snoops all the DNS responses, and if you allow *.example.com it allows every IP that's returned via DNS for *.example.com. No extra overhead in doing additional DNS lookups or anything else crazy like that.
When or whether that hits the open source side, I'm not sure yet.
Does pfSense support setting up a password protected proxy system so we can program TeamViewer and other allowed programs to byass the captive portal by going through the proxy with a username/password?
Could probably do that with Squid.
I love you guys. Hopefully wildcards gets some attention for the next release build as this is very important for captive portal builds.
Regarding setting up Squid to bypass the Captive portal, it doesn't appear as if that works. If I have both Captive portal and Squid on the same interface, Captive portal will always require authentication before allowing itself to be used as a proxy. If I try to set up a virtual interface and bridge it with the WAN, Captive portal will throw a warning and won't turn on saying that it can't be activated on a bridged connection. So, short of having two firewalls, I don't see another way to make that work.
