Static routing across VPN for specific public IP addresses

I have an existing site-to-site VPN with two Cisco ASA 55xx that is running over a cable provider connection. The local network is 192.168.0.x.

One the other end, there is a 192.168.1.x network. All traffic bound for the 1.x goes over the VPN and I can reach all of the devices with no problem.

The issue is, at the remote site there is another VPN router located at, which I can ping just fine.

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.

The other odd thing is that from the remote site, a trace route to the 207.187.66.x address (or even for that matter) times out and never shows even a first hop.
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

N. SpearsSr.Net.EngCommented:
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.
JohnBusiness Consultant (Owner)Commented:
The issue is, at the remote site there is another VPN router located at,

You need to change the Remote site Subnet from .1 to .2 and things should work fine.
ThePhreakshowAuthor Commented:
Eliminating the site-to-site from this equation, If I use just a VPN client to connect to the main site (which gets an address of 192.168.4.x from the pool) I can ping the but cannot force a route on the client who needs to use that as the gateway when they want to get to the 207.187.66.x address...
High-tech healthcare

From AI to wearables, telehealth to genomics to 3D printing — healthcare technology is seeing rapid advancement. Experts believe that this technological advancement will save money and save lives. Healthcare is changing dramatically, and emerging technology drives that change.

N. SpearsSr.Net.EngCommented:
Can you restate which is considered the main site? And what do you mean force a route?
N. SpearsSr.Net.EngCommented:
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.
ThePhreakshowAuthor Commented:
The main site is the 192.168.1.x network. I connect to the ASA at that location. The default gateway/router for everything at that location is at and has a static route in it for 207.187.66.x to point to the other router at 1.223... I guess my problem is perhaps the VPN clients are stopping at the ASA ( and never seeing
JohnBusiness Consultant (Owner)Commented:
Why not change the subnet? More durable and problem free over the long haul.  Use 63 or some such unlikely subnet number
nociSoftware EngineerCommented:
The picture i got: (remote site = ) -> ---- TUNNEL ----- ---> (mainsite) --> internet

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

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:

( TUNNEL (  
as the tunnel specification (meaning that from the p.o.v. of the internet ( is behind the tunnel.
As is part of you don;t need two tunnels.

On the default gateway needs to the local router. (
On that router either the tunnel adds a route, or you need to add a route pointing to
Fred MarshallPrincipalCommented:
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: is LOCAL is REMOTE
So, going from remote to 1.x seems like saying going from remote to remote... ????
N. SpearsSr.Net.EngCommented:
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?
ThePhreakshowAuthor Commented:
Maybe a picture is worth 1,000 words....

Sorry I forgot to include a router between the ASA and the switch. It's and has static routes to point 207.187.66.xx traffic to the

Crude topology
N. SpearsSr.Net.EngCommented:
Where is the 0.x network mentioned in the original question?
ThePhreakshowAuthor Commented:
I was just trying to simplify and remove that from the equation. I would be happy just getting the regular VPN clients working.. But if it were shown, it would be a Cisco 5505 on the 192.168.0.x network coming into the internet cloud that then leads to the ASA firewall icon.
N. SpearsSr.Net.EngCommented:
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?
nociSoftware EngineerCommented:
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? ...
ThePhreakshowAuthor Commented:
The site-to-site is using split tunneling I think (everything goes out its internet connection except traffic bound for the internal addresses at the home office), but the regular old VPN clients are not... And no, this server is not accessible from the regular old internet. Has to go through their router... and why cant any of my VPN clients do a traceroute? might be helpful in troubleshooting.

At this point, I only really care about the regular VPN clients laptops... Forget the site-to-site from the original question.
JohnBusiness Consultant (Owner)Commented:
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.
nociSoftware EngineerCommented:
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 ( 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

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
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.
ThePhreakshowAuthor Commented:

First Q: Yes, works fine. VPN clients can access 192.168.1.x
Second Q: Yes, clients in the office on 192.168.1.x work fine and route via

I am a Mac user, so I go about connecting with the native VPN to MacOS. Having issues with the Windows AnyConnect client setup though.
JohnBusiness Consultant (Owner)Commented:
If you wish to try NCP (better than AnyConnect), they have a MAC version.
ThePhreakshowAuthor Commented:
AnyConnect client working fine now on a Windows PC... No problem getting to anything on the 192.168.1.x network... Cannot figure out how to add the static route for VPN clients though...

Tried just adding a route in windows to that and specified the IF of the AnyConnect virtual adapter, no luck.
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)
ThePhreakshowAuthor Commented:
...Yeah.. Not sure how to force those static routes in Anyconnect..
Fred MarshallPrincipalCommented:
So, you have AnyConnect VPN clients out on the internet who are assigned to and can access devices on 192.1658.1.0/24, right?

What you want are for those clients to reach, 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 are launched from the 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 gateway or perhaps to gateway.

The problem as I've always encountered it (and I believe others know how to fix this) is this:
The packet originating at, needs a destination.  The only destination addresses that will route through the VPN are in
YOUR objective destination is
So, the original packet could have a destination of (the other VPN device) but then what? 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 with destination will be routed to AND that device knows where 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.
2) the VPN device address on (i.e.
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.
ThePhreakshowAuthor Commented:
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...

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.
N. SpearsSr.Net.EngCommented:
For the site to site you will need to add that 207 ip to the phase 2 portion of your vpn configuration and nat exempt it. Once the traffic reaches the ASA where you added the route, it should route it accordingly.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Fred MarshallPrincipalCommented:
The Phreakshow:  Your descriptions are a bit too cryptic.  I'm guessing that the AnyConnect clients end up with IP addresses on the  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 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  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 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?
ThePhreakshowAuthor Commented:
I re-built the site-to-site and it picked up the static routes.. Added the NAT exemption for dial-in and Both are working now.
Thanks for all the help.
JohnBusiness Consultant (Owner)Commented:
Thank you for the update.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.