Static routing across VPN for specific public IP addresses

From the  192.168.0.x site how are your nat rules set. Are you NoNatting source traffic just to the 192.168.1.x network  as a destination? Or are you NoNatting source traffic to any destination. It sounds like you are NoNatting to any destination. Otherwise, only traffic destined to the 192.168.1.x network would traverse it. Alternately, it would do that also if you set up a default route on your 192.168.0.x ASA to point to that ASA firewall with the 1.223 address.

The issue is, at the remote site there is another VPN router located at 192.168.1.223,

You need to change the Remote site Subnet from .1 to .2 and things should work fine.

Can you restate which is considered the main site? And what do you mean force a route?

If by main site you are referring to the site not local to the 1.223  vpn router. The vpn client will only use the gateway to the 4.x network. The only way to get it to use the .223 as a gateway to the internet is if the firewall you SSL into has a default route pointing to it.  In the case of a VPN client. It's simpler to just split tunnel the traffic and allow the client to use it's own local internet connection to access internet sites.

Why not change the subnet? More durable and problem free over the long haul.  Use 63 or some such unlikely subnet number

The picture i got: (remote site = )192.168.1.0/24 -> 192.168.1.223 ---- TUNNEL ----- 192.168.0.254 ---> (mainsite) --> internet

This has to do with the IPSEC tunnel.
A tunnel has a specification like
(192.168.0.0/24 ) TUNNEL ( 192.168.1.0/24 )

The IP ranges are PART of the tunnel specification. Not only allowing that traffic but also FILTERING what is allowed.

I your case  you need:

(192.168.1.0/24) TUNNEL (0.0.0.0/0)  
as the tunnel specification (meaning that from the p.o.v. of 192.168.1.0/24) the internet (0.0.0.0/0) is behind the tunnel.
As 192.168.0.0/24 is part of 0.0.0.0/0 you don;t need two tunnels.

On 192.168.1.0/24 the default gateway needs to the local router. (192.168.1.223)
On that router either the tunnel adds a route, or you need to add a route 0.0.0.0/0 pointing to 192.168.0.254

I sense a typo here:

From the remote site, when I need to get to a certain public IP that is 207.187.66.x it needs to go across the site-to-site, onto the 1.x network and hit the 1.223 router to continue down that tunnel at the main site.

But, it might also be a good idea to explain this a bit further.
Do you mean "to reach ANY public IP address" or do you mean "to reach this one range of public IP addresses"?  
I'm looking to see if there's a special routing or general routing to public addresses just for clarity.

As I read the original quesiton:
192.168.0.0 is LOCAL
192.168.1.0 is REMOTE
So, going from remote to 1.x seems like saying going from remote to remote... ????

Yeah, this topology seems to get more confusing with each comment. @PHREAK can you mock up a quick diag of your topology just so we all are on the same page?

Where is the 0.x network mentioned in the original question?

One last question I hope. Are you tunneling all the vpn client traffic over their tunnels, or split tunneling? Is this server accessible over the internet by any source or no?

If you need one host on the internet through the 192.168.4.x tunnel then you need another (extra) tunnel between each 192.168.4.x client and the Cisco ASA which specifies the 192.168.4.x/24  -> 207.187.66.x /32  and you need a route on the ASA that sends all 207.187.66.x traffic to 192.1681.223....

Depending on VPN... You may need an addition tunnel between the VPN router and the endpoint. (207...)  to allow traffic from 192.168.4.x
Also does the system at 207... known where to find 192.168.4.x? ...

I use NCP Secure Entry for this kind of stuff.  Try it. There is 30 day full function free trial to determine if it fits you.

It handles NAT Traversal where many VPN clients do not. I have used it for years since the beginning of Windows 7 (long gone) and it works great in Windows 10.

www.ncp-e.com

what is wrong here? #a42787036
If the internet access is not for that one address, through route that address through the 2nd tunnel as described....
Any address can be tunneled if specified into the tunnel config.
And traceroute fails (most probably) due to tunnel failure to forward for that address.

Coming  in late so apologies if I've missed something :-)

To clarify my understanding:

You have clients outside the office dialing a VPN over the internert to the Cisco ASA on 209.69.x.x that are assigned a VPN-LAN IP of 192.168.4.x

First Q: is this correct and do these VPN clients work OK (I.E. can they see stuff on your network 192.168.1.x as planned?)

Your query is to ask how to send traffic fro these VPN clients intended for 207.187.66.x down the VPN and via a separate gateway (192.168.1.223) instead of over the internet.

Second Q: Is this correct? do clients in the office on 192.168.1.x work OK and are they correctly routing via 192.168.1.223?

Assuming I've understood correctly, you need your dial-in VPN clients to add a static route to 207.187.66.x via the gateway 192.168.1.223.
Assuming you're using the proper Cisco Anyconnect client for your dial in users, you can specify static routes in the VPN profile which would be assigned to the dial in users automatically. Assuming your firewall rules allow this traffic, it should achieve what you're asking for.

If you wish to try NCP (better than AnyConnect), they have a MAC version.

Great. just need to force this traffic via the dial-in VPN with static routes in Anyconnect then.
(Many VPN clients take over static routing duties so adding static routes in windows rarely works when using VPN clients)

So, you have AnyConnect VPN clients out on the internet who are assigned to 192.168.4.0/24 and can access devices on 192.1658.1.0/24, right?

What you want are for those clients to reach 207.187.66.xxx, is that right?

I don't know how to advise re: the exact equipment and software you're using but I'd translate the requirement into words as follows:

Packets destined for 207.187.66.xxx are launched from the 192.168.4.0/24 clients.
They must arrive and traverse the ASA.
So they first must to routed to their respective VPNs - that sounds like a route on the client pointing to 192.168.4.xxx gateway or perhaps to 192.168.1.xxx gateway.

The problem as I've always encountered it (and I believe others know how to fix this) is this:
The packet originating at 192.168.4.0, needs a destination.  The only destination addresses that will route through the VPN are in 192.168.1.0.
YOUR objective destination is 207.187.66.xxx.
So, the original packet could have a destination of 192.168.1.223 (the other VPN device) but then what?  207.187.66.xxx isn't included in this.  So, at this point, the packet is likely dropped.  You can't have TWO destinations!

In contrast, a packet originating at 192.168.1.0 with destination 207.187.66.xxx will be routed to 192.68.1.223 AND that device knows where 207.187.66.0 is to be routed (over the VPN).  These packets DO contain the ultimate destination.

With this much of a framework, perhaps someone can tell you (us) how to solve the VPN-IN to VPN-OUT/Destination problem.

It seems to me that there are TWO pieces of essential information:
1) the ultimate destination (i.e. 207.187.66.xxx)
2) the VPN device address on 192.168.1.0 (i.e. 192.168.1.223)
And the first must be in the original packet launch.
The second may be implied by this address .. somehow but the routing mechanisms aren't clear to me.

The Phreakshow:  Your descriptions are a bit too cryptic.  I'm guessing that the AnyConnect clients end up with IP addresses on the 192.168.1.0  network behind the ASA.  As virtual members of that subnet, they might well share the capabilites of the physical members of that subnet / LAN.

You absolutely need a route on the ASA for 207... that points to the 192.168.1.223 VPN device - well unless you have a route in every PC in the subnet!!
Then, any traffic to 207..... will go to the ASA (gateway) and be directed to 192.168.1.223.  That's essential for return traffic from 207 ....

Sorry I don't know how to address the site-to-site connection as in my earlier post.
N. Spears:  I don't fully understand what you said about it but it should be pursued!

Added a static route to the ASA that the AnyConnect clients were connecting and pointed it to the local router (which has the static routes to be aware of the 207.187.66.xx network and to point them to the other VPN router) and everything is working fine...

Sorry for the delayed response. glad you've found how to add static routes anyway :-)
To confirm, have you set a static route to direct the dial-in VPN clients to 192.168.1.223? thats the best option.

This does, however, still leave the issue that was in my original question, and that was how to get it working with the site-to-site connection.

Eh? confused. Thought you said above that was working fine? do you mean the machines in the office cannot reach the 207.187.66.x network over the site-to-site?

Thank you for the update.