Thank you for the post! We had the same issue.

You don't have to bypass the discovery process with SQL server on named instances. SQL has the option to use either dynamic ports or a fixed port for a named instance. If you enter a fixed port then you just need to open up port 1433 (or maybe 1434) and the fixed port on the SQL server and the discovery process will always allocate the same port to the clients. The advantage of doing it this way is that if for any reason you need to change the port you only have to modify the server and firewall but not all the connection strings on the clients.

From what I understand from the OP, the problem is the discovery service runs over UDP, which we block externally by default. Our network architects are very leary about opening ports on our firewall. If this were an internal application or an application that did not need to access external tables (via an extension), that would not be a problem. In this case, we have a web-facing application that needs to access external database connections that exist behind the firewall. It runs fine on our intranet, but hitting it on the DMZ causes problems. Using advanced configuration with a fixed port may be our best bet given that we use virtualized environments that may reside on the same physical server for our SQL instances. 

Thats no problem, not using discovery is a valid option, although as a qualified DBA and software developer myself I've found from experience that opening the correct ports and enabling it gives the least problems over time and doesn't make your setup any less secure, after all it's the SQL port itself that is most vulnerable point not the discovery one.