Avatar of ThePhreakshow
ThePhreakshow
 asked on

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 192.168.1.223, 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 google.com for that matter) times out and never shows even a first hop.
* ASACiscoNetworkingVPN

Avatar of undefined
Last Comment
John

8/22/2022 - Mon
Soulja

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.
John

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.
ThePhreakshow

ASKER
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 192.168.1.223 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...
I started with Experts Exchange in 2004 and it's been a mainstay of my professional computing life since. It helped me launch a career as a programmer / Oracle data analyst
William Peck
Soulja

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

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.
ThePhreakshow

ASKER
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 192.168.1.254 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 (192.168.1.1) and never seeing 192.168.1.254.
⚡ FREE TRIAL OFFER
Try out a week of full access for free.
Find out why thousands trust the EE community with their toughest problems.
John

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

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
hypercube

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... ????
This is the best money I have ever spent. I cannot not tell you how many times these folks have saved my bacon. I learn so much from the contributors.
rwheeler23
Soulja

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?
ThePhreakshow

ASKER
Maybe a picture is worth 1,000 words....

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

Crude topology
Soulja

Where is the 0.x network mentioned in the original question?
⚡ FREE TRIAL OFFER
Try out a week of full access for free.
Find out why thousands trust the EE community with their toughest problems.
ThePhreakshow

ASKER
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.
Soulja

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?
noci

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? ...
All of life is about relationships, and EE has made a viirtual community a real community. It lifts everyone's boat
William Peck
ThePhreakshow

ASKER
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.
John

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
noci

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.
⚡ FREE TRIAL OFFER
Try out a week of full access for free.
Find out why thousands trust the EE community with their toughest problems.
Steve

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.
ThePhreakshow

ASKER
@Steve

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 192.168.1.223

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.
John

If you wish to try NCP (better than AnyConnect), they have a MAC version.
Your help has saved me hundreds of hours of internet surfing.
fblack61
ThePhreakshow

ASKER
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 192.168.1.223 and specified the IF of the AnyConnect virtual adapter, no luck.
Steve

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)
ThePhreakshow

ASKER
...Yeah.. Not sure how to force those static routes in Anyconnect..
⚡ FREE TRIAL OFFER
Try out a week of full access for free.
Find out why thousands trust the EE community with their toughest problems.
hypercube

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.
ThePhreakshow

ASKER
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.
ASKER CERTIFIED SOLUTION
Soulja

THIS SOLUTION ONLY AVAILABLE TO MEMBERS.
View this solution by signing up for a free trial.
Members can start a 7-Day free trial and enjoy unlimited access to the platform.
See Pricing Options
Start Free Trial
GET A PERSONALIZED SOLUTION
Ask your own question & get feedback from real experts
Find out why thousands trust the EE community with their toughest problems.
hypercube

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!
Experts Exchange is like having an extremely knowledgeable team sitting and waiting for your call. Couldn't do my job half as well as I do without it!
James Murphy
Steve

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?
ThePhreakshow

ASKER
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.
John

Thank you for the update.
⚡ FREE TRIAL OFFER
Try out a week of full access for free.
Find out why thousands trust the EE community with their toughest problems.