Do you wonder if your IT business is truly profitable or if you should raise your prices? Learn how to calculate your overhead burden using our free interactive tool and use it to determine the right price for your IT services. Start calculating Now!
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.
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.
Do more with
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
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.
You need to change the Remote site Subnet from .1 to .2 and things should work fine.
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...
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.
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.
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
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:
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... ????
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?
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
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
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.
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? ...
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? ...
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.
At this point, I only really care about the regular VPN clients laptops... Forget the site-to-site from the original question.
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
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.
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.
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.
@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.
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.
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.
Tried just adding a route in windows to that 192.168.1.223 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)
(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.
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.
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.
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.
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.
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!
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?
Premium Content
You need an Expert Office subscription to comment.Start Free Trial