SQL Server 2016 – Always On Listener Setup

It can connect from SQL 1 server, which is the primary for AG.

By "connect", do you mean it can ping AG-LISTENER from SQL1?

It sounds like what your problem might be is with the port number you chose for your listener. By choosing 5525, you are selecting a non-default port (1433 would be the default).

So when you try to connect to the listener, what does your connection string look like? I'm guessing it looks something like this:

data source = ag-listener; initial catalog = ...

You have two options here. You can either be explicit with your listener's port number:

data source = ag-listener,5525; initial catalog = ...

Likewise, if you're testing this out with SQL Server Management Studio (SSMS), then for the Connect to Server dialog box, instead of putting in ag-listener for the Server name text box, put in ag-listener,5525.

Or you can change the port that your listener is listening on to 1433 (read the below BOL reference before considering this change):

alter availability group YourAvailabilityGroupName
modify listener 'AG-LISTENER'
(
    port = 1433
);

It is worth noting when you can use the default port (1433). Take a look at this reference on BOL explaining when you can and can't use 1433 for the listener (excerpt copy/pasted below for reference):

You can configure the default port to 1433 in order to allow for simplicity of the client connection strings. If using 1433, you do not need to designate a port number in a connection string. Also, since each availability group listener will have a separate virtual network name, each availability group listener configured on a single WSFC can be configured to reference the same default port of 1433.

(portions omitted for brevity)

If you use the default port of 1433 for availability group listener VNNs, you will still need to ensure that no other services on the cluster node are using this port; otherwise this would cause a port conflict.

EDIT: If the above isn't your problem (as seen from your comment below) then, after you look through the logs, I'd say the next best course of action is to start looking at the network traffic to see what is (and isn't) happening. You can use a network monitoring tool like netmon to accomplish this.

Another thing I'd do, and I realize you said the firewall isn't a problem, but I'd see if the port is actually listening (my favorite tool for this is portqry).

Not having a listener IP means that you will get the functionality provided by a FCI (Failover Cluster Instance) rather than a fully fledged AG + FCI solution. In effect you are asking what are the effects of using a FCI as a data source as opposed to an AG and how can I expand on it.

The FCI will require you to stop a service on one node with shared storage and wait for it to start on a different node after the resources are started on it. This takes time. By using this IP you will have to deal with this downtime every time you patch or fail over.

An AG has the service running at all times on all the nodes and you get to set much better priority, along with assigning read only node options to your clients connection strings. This means faster failover, dynamic rerouting of applications with the READ_INTENT connection setting, and better management of your entire AG solution and cluster as a whole.

It is very simple to add or remove a listener so do not worry if you don't have one yet.

Edit to question: Having a listener or not in SQL Server doesn't affect a FCI failover unless you do something with the dependencies with each other. Outside of that a FCI will remain independent and operate on the instance level. The FCI will failover if there is a issue with the heartbeat or it's initiated, the AG solution with a listener will do so at the database level. Thus you can have your application working off an AG listener which can work independently of the FCI depending on how the solution is designed. We have some FCI/AG MCM's and experts here who can give you more in depth answers too.