Yes AG support multiple subnets as described here. Also make sure that your data provider supports MultiSubnetFailover .. .NET Framework 4 supports it.
To answer your question ...
IF you use .NET framework 4 or 3.5 then the provider will support it as described here.
Also, a good reference to SQL Server Multi-Subnet Clustering is well documented.
With legacy client libraries or third party data providers, you cannot use the MultiSubnetFailover parameter in your connection string. To help ensure that your client application works optimally with multi-subnet FCI in SQL Server 2012, try to adjust the connection timeout in the client connection string by 21 seconds for each additional IP address. This ensures that the client’s reconnection attempt does not timeout before it is able to cycle through all IP addresses in your multi-subnet FCI.
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).
Best Answer
It's generally considered a really bad idea to make your database accessible from the internet.
Making the database accessible from the public internet is a HUGE security risk. It's easy to port-scan and find publicly accessible databases. Even if you run on a non-standard port, it's relatively trivial to discover the SQL Server instance that is internet-facing. Your database would be available to anyone to exploit. It's likely that you'd be victim of every zero-day exploit, in addition to brute force attacks. Eventually, your data will be stolen or destroyed.
Take a look at shodan.io to see how easy it is to discover databases on the public internet. You will essentially have a big sign saying "HACK ME" hanging on your IP address.
Ideally, you would have a web service that the application would interact with. That public web service would be the only thing that connects to the (non-public, firewalled) database. Doing this would require re-architecting your application to use the web service, rather than a direct client-server database connection. If you can't re-architect the application, then VPN is the only secure solution.