- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-15-2019 06:10 PM
We have a client who is VERY protective of their internal address space and servers that reside therein. This causes some issues when we come to implement a guest solution for them using ISE 2.4. We have pretty much nailed down everything except DNS. The issue is in the re-direction of user traffic to the the portal - as far as we can tell this relies on DNS and our client would very much prefer that guests are only ever given access to external DNS servers.
Anyone got any ideas of how this MIGHT be achieved?
Thanks
Al
Solved! Go to Solution.
- Labels:
-
Identity Services Engine (ISE)
Accepted Solutions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-15-2019 06:58 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-15-2019 07:20 PM
Solved.
Thanks for the suggestions guys but they all involve scenarios we were trying to avoid. However - we did come across this:-
which is perfect for our needs. Just a bit of re-configuration of rules required.
Thanks all
Al
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-16-2019 02:43 PM
If you don't want your guest portal to be internet facing (and why should it? I don't need to resolve a USA based guest portal over here in Australia! I would imagine guest portals are hosted on private address space)
In my opinion a standalone DNS server that performs conditional forwarding is the answer. Even Microsoft DNS servers can do it.
Conditional DNS forwarding does what it says: it has conditions built in with simple logic like:
1) if resolving guest.company.com then I will resolve it for you
2) for everything else I will forward your query to an external DNS service (Google, ISP, etc)
This means your guests will never be able to resolve your intranet services except the guest page

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-16-2019 10:39 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-15-2019 06:58 PM

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-15-2019 07:08 PM
You have several different options:
- Put the real FQDN names of the ISE nodes in the external DNS with their private IP addresses on the inside network and open the TCP/8443 on the FW to the ISE nodes.. It sounds odd to put private IPs in public DNS but not uncommon these days, but many customers do this.
- Put generic guest names in DNS, i.e. guest1.mycompany.com and guest2.mycompany.com, and point them to the inside IPs of the ISE nodes and open up TCP/8443 on the FW.
- Use 2nd NICs on the ISE nodes to put an interface either on the guest wireless segment or another DMZ and put either the real or generic guest DNS names in DNS pointing at the DMZ IPs. If the ISE nodes are on a different DMZ then allow TCP/8443 to the ISE DMZ IPs.
- Use any of #1 through #3 but setup public NATs on the FW to totally obscure the private IPs. Setup either DNS fixup if the FWs support it or just NAT the traffic through to ISE on the inside network or the DMZ. Again allowing TCP/8443 through the FW.
Public DNS for guest wireless is pretty much the standard in most of my deployments. I have done all of the above across my customers.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-15-2019 07:20 PM
Solved.
Thanks for the suggestions guys but they all involve scenarios we were trying to avoid. However - we did come across this:-
which is perfect for our needs. Just a bit of re-configuration of rules required.
Thanks all
Al

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-15-2019 07:30 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-16-2019 02:43 PM
If you don't want your guest portal to be internet facing (and why should it? I don't need to resolve a USA based guest portal over here in Australia! I would imagine guest portals are hosted on private address space)
In my opinion a standalone DNS server that performs conditional forwarding is the answer. Even Microsoft DNS servers can do it.
Conditional DNS forwarding does what it says: it has conditions built in with simple logic like:
1) if resolving guest.company.com then I will resolve it for you
2) for everything else I will forward your query to an external DNS service (Google, ISP, etc)
This means your guests will never be able to resolve your intranet services except the guest page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-16-2019 03:20 PM
Hi All,
Thanks for all the replies. I now have an interim solution for our testing purposes and a final solution once we are happy with everything. We are using the static address assignment for testing and will discuss setting up a DNS to resolve the PSN addresses and forward all other to an external DNS with the customer.
Cheers
Al

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-22-2019 07:50 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-22-2019 03:28 PM
Hi All,
Our final solution to this conundrum was to use static assignment for testing purposes in our solution and accept the certificate warnings. When it comes to putting this into production we shall use a couple of specially created DNS servers which will contain two entries for our PSN nodes. All other queries will be forwarded to an external DNS.
Thanks

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-16-2019 10:39 PM
