I haven't worked with the Cisco RV180w, but I want to try to throw out a few suggestions based upon other VPN experience.
For starters, in your first screenshot, I'm seeing you are requesting the "Remote" side identify themselves with a FQDN, which you have filled out as "remote.com".
Usually this would be some sort of "Group Username" or "Group Identifier". I don't know what other options exist in that drop down, but look for something along those lines.
On the client side, the configuration would use the same "Group Username" as above in their username configuration. And then they would use what you have in the "pre-shared key" box as their password. Note, that multiple users will share the same username and password here. (see below on how to amend that)
You have the same setting to change in your 2nd screenshot. THe remote end point will probably identify themselves with some sort of Group Username or Password.
The "Local Traffic Selection" should be an identification of the subnet(s) that exist behind your Cisco router. If you're only network is 192.168.12.0/24, then you're fine. But if you have other subnets, you should update this.
The Remote Traffic Selection should identify the IP address that is given to the users who connect through the VPN. On Cisco Firewalls, typically an IP pool is created (it doesn't much matter what IPs you pick, just pick something that probably won't' be used at either the client end or your end). Then you configure the "remote traffic selection" as that subnet. I'm not sure the implications of leaving that set to Any. I feel that might cause potential routing issues, so I would avoid it.
Back on your first screenshot, you have XAUTH set to None. This is fine while you are testing, but in production this is a pretty big security vulnerability. For two main reasons:
5.1: All of users will now share only one Group Username and Pre-Shared Key for password.
5.2: Due to how Aggressive Mode negotiates, the packet which contains the hash of the Pre-Shared Key is sent in clear text. Which leaves you vulnerable to someone eavesdropping that packet, and running offline brute force attacks on a hash (which can be performed at relatively high speed).
Better to not leave yourself open to this. XAUTH creates a second layer of username/password challenge, but these are all transferred securely through the VPN tunnel. So I would suggest turning that on.
The last thing I would suggest, is running a packet capture on your Cisco box's outside interface, when you have a client trying to connect. The result of that would be very useful in determining why the VPN connections are not working.