Solved

Routing packets, destined for subnet #3, from subnet #1, via VPN A to subnet #2 and hence to subnet #3 via VPN B.

Posted on 2013-12-17
9
534 Views
Last Modified: 2014-01-02
This question comes up often enough.  I've asked a few times but never got down to fundamentals (my fault).  So, I don't "know" the answer - even though it may have been "given" in the past.  Here is a reference:
http://www.experts-exchange.com/Hardware/Networking_Hardware/Routers/Q_22673991.html#a19419853

(The assumption is that there can't be an internet VPN set up directly between subnet #1 and subnet #3.  Packets must pass through subnet #2 because e.g.:
- one of the VPNs is on an MPLS link and the other on an internet link.
- one of the VPN devices at subnet #2 is controlled by a 3rd party and a 3rd VPN going direct from #1 to #3 is not possible.
- etc.))

What I would like to see  is a description of the packets something like this:

Packet is launched on subnet #1 destined for subnet #3.
Routes for subnet #3 send packet to VPN A device on subnet #1.
[If VPN A tunnel points to subnet #2 then how does it accept packets destined for subnet #3?]
assuming I know the answer to this, then:
Packet arrives at output to VPN A at subnet #2.
Routes for subnet #3 send packet to VPN B device on subnet #2.
[presumably there is a route on the VPN A device at subnet #1 that acts on the unencrypted packets in order to accomplish this?]
VPN B at subnet #2 forwards packet to VPN B at subnet #3 where it goes directly to the destination address.

I was told once upon a time that the VPN A tunnel would only accept traffic for subnet #2 .. period.  Is this indeed a limiting factoid?

If I could understand the packet macro structure as above and the device's macro configuration then it would be more understandable and memorable.

I don't want to know some [brand] CLI commands.  I want to know how this works in principle.
0
Comment
Question by:Fred Marshall
  • 4
  • 3
  • 2
9 Comments
 
LVL 57

Expert Comment

by:giltjr
ID: 39724823
The simplest thing to do is to think of the VPN tunnels as another set of subnets and routers.  So instead of 3 subnets you have 5, your 3 and the two that represent the 2 VPN tunnels and  the end points of those tunnels are extra routers.

--> I was told once upon a time that the VPN A tunnel would only accept traffic for subnet #2 .. period.  Is this indeed a limiting factoid?

If that is true, then yes that is a limiting factor.   However in reality the "tunnel" can't filter traffic out, the VPN end point may have ACL's to filter out/drop traffic for anything other than subnet#2.
0
 
LVL 25

Author Comment

by:Fred Marshall
ID: 39733922
I can think of the tunnels as subnets but they aren't subnets.  So, it makes it a little hard to use that idea to figure out what the packet structure might be.

"if it does" means "I don't know"??
0
 
LVL 57

Expert Comment

by:giltjr
ID: 39734123
Maybe I don't know how your VPN is setup but but typically when you connect to a VPN there are two sets of IP addresses that are on different subnets.

One set is the end points of the VPN tunnel.  The other set is the IP address within the tunnel.

Anyway the packets don't look any different from any other packet going through a VPN tunnel.

You have the packet that has the source and destination IP addresses of the two end points of the VPN tunnel.

In side that packet is the packet that has the source and destination IP address of the two hosts involved in the data transfer.
0
 
LVL 68

Accepted Solution

by:
Qlemo earned 250 total points
ID: 39734761
What giljr states is correct (in most points). I'll try to draw a picture, putting more flesh into it. I'm omitting the public IP parts for now, just considering the VPN tunnels like physical networks.

Assumption: Site#1 PC 10.10.10.10/24 connects to Website 1.1.1.1, and the packets have to go thru Site#3, Site#2 and then Internet.
I'll name those tunnels VPN13 for VPN from Site#1 to #3, and consider VPN13 and VPN31 to be the same (bidirectional, as Site-to-Site VPNs work).

1. PC 10.10.10.10 ---> VPN13 ---> Site#3 10.10.11.0/24
The IP address just enters Site#3's subnet as if the PC were connected directly. No translation. Of course this requires to have proper routing info on the Site#1 VPN device, which is:
   from: local subnet to: all tunnel: VPN13

2. Site#3 knows of route
   from: local subnet to: all tunnel: VPN32
   and passes the packet accordingly. Again, no change in IP addresses.

3. Site#2 finally is able to route the packet, but will have to apply NAT from Site#1 addresses to its public IP.

4. Answer from 1.1.1.1 to Site#2 public IP, matches the NAT session entry, so will get translated to target IP 10.10.10.10. Then routing is applied again, which means that Site#2  needs to know how to route packets for Site#1 - via Site#3, using VPN32.

Guess the remaining routes are obvious.
0
How to improve team productivity

Quip adds documents, spreadsheets, and tasklists to your Slack experience
- Elevate ideas to Quip docs
- Share Quip docs in Slack
- Get notified of changes to your docs
- Available on iOS/Android/Desktop/Web
- Online/Offline

 
LVL 25

Author Comment

by:Fred Marshall
ID: 39735008
Qlemo:  I will paraphrase your response in keeping with the notation I initiated:

Assumption: Site#1 PC on Subnet #1 = 10.10.10.10/24 connects to Website 1.1.1.1, and the packets have to go [first] thru Site#3/ subnet #2 [and then to] Site#2 / subnet #3 and then Internet.
I'll name those tunnels VPN13=VPNA for VPN from Site#1 to #3, and consider VPN13=VPNA and VPN31=VPNA to be the same (bidirectional, as Site-to-Site VPNs work).

1. PC 10.10.10.10 at site #1 / subnet #1 ---> VPN13=VPNA ---> Site#3 / subnet #2 10.10.11.0/24
The IP address just enters Site#3's subnet #2 as if the PC were connected directly. No translation. Of course this requires to have proper routing info on the Site#1/subnet#1 VPN device, which is:
  from: local subnet to: all tunnel: VPN13

2. Site#3/subnet#2 knows of route
  from: local subnet to: all tunnel: VPN32
  and passes the packet accordingly. Again, no change in IP addresses.

3. Site#2/subnet#3 finally is able to route the packet, but will have to apply NAT from Site#1 addresses to its public IP.

4. Answer from 1.1.1.1 to Site#2 public IP, matches the NAT session entry, so will get translated to target IP 10.10.10.10. Then routing is applied again, which means that Site#2  needs to know how to route packets for Site#1 - via Site#3, using VPN32.
***********

OK.  I understand this and it's very helpful.  But, you have added a twist which I did not intend.  This is not intended to be an internet gateway path.  If it were, then I understand what you've described and do believe it could work that way .. depending on the VPN device perhaps.  e.g. an RV042??

I should also be careful to say that these are site-to-site VPNs so we don't have to worry about "split VPNs" as in client-to-site VPN implementations.  Each site has its own internet gateway.  I had hoped that would have been clear in that one VPN is based on an internet tunnel implying that there is an internet gateway at both ends; and, the other VPN is on an MPLS link which, yes,  could imply the need for an internet link over that VPN.  So, I hope this clarifies.

So, the route:
from: local subnet to: all tunnel: XXXX
came as a bit of a surprise.
All of the site-to-site VPNs that I've implemented HAD to have a subnet at each end.
And, packets destined for the terminating subnet were routed into the tunnel.
You're suggesting that one could do this (based on my perhaps faulty understanding):

Set up a VPN between subnet #1 and subnet #2 (with their public addresses used in the configuration of course).

Set up a route on subnet #1 VPN A device that says:
from: local subnet to: subnet #3/ tunnel: XXXX (going to subnet #2)

I can imagine setting up a route on the subnet #1 *gateway* (separate from the VPN A device) that says:
from: local subnet to: subnet #3/ VPN A (which goes to subnet #2)

The question I have about this, which I tried to address above, is:
How does the VPN A device on subnet #1 know to accept and tunnel this packet destined for subnet #3 onto VPN A which only goes to subnet #2.  What keeps this packet from being dropped at the VPN A device on the subnet #1 side?

My impression has been that VPN A will *only* accept packets on subnet #1 that are destined for subnet #2.  But your ALL route seems to contradict this notion.  Fair enough but what if it isn't going to be ALL and, rather, limited to adding subnet #3?
0
 
LVL 57

Assisted Solution

by:giltjr
giltjr earned 250 total points
ID: 39735111
--> How does the VPN A device on subnet #1 know to accept and tunnel this packet destined for subnet #3 onto VPN A which only goes to subnet #2.

It has a route for subnet #3 that says the next hop is the VPN A device on subnet#2, that is the other end of the VPN tunnel.

--> What keeps this packet from being dropped at the VPN A device on the subnet #1 side?

In addition to having a route for subnet #3 that says the next hop is the VPN A device on subnet#2, it also has NO ACL's that say drop that traffic.

-->My impression has been that VPN A will *only* accept packets on subnet #1 that are destined for subnet #2.  But your ALL route seems to contradict this notion.  

Qlemo most likely assumed that there were no ACL's or that VPN A device on subnet#1 had a route to subnet#3 via VPAN A device on subnet#2.  

It could also be that the VPN A device at subnet#2 does not have a route to subnet#3.

--> Fair enough but what if it isn't going to be ALL and, rather, limited to adding subnet #3?

It may be all, it could be that just the way it is stated you are assuming that something with VPN A it is limited subnet#1 to/from subnet#2.     By stating that VPN A only allows subnet #1 to/from subnet #2 and not ALL, then you are implying that if you had subnet#4 at the same site as subnet#4 it would be allow to talk to subnet #3 through the VPN.
0
 
LVL 68

Expert Comment

by:Qlemo
ID: 39735122
Of course the route can be more specific than a default route, it doesn't matter in regard of routing. The firewall/VPN config might think different, however.
0
 
LVL 25

Author Comment

by:Fred Marshall
ID: 39752175
giltjr:  
By stating that VPN A only allows subnet #1 to/from subnet #2 and not ALL, then you are implying that if you had subnet#4 at the same site as subnet#4 it would be allow to talk to subnet #3 through the VPN.
Yes.  It can't say "all" and have a local internet gateway that would work reliably.  And, new subnets can be added as they are created - which is generally not a big deal while one is doing that job.

But, OK.  I'm getting the impression that some devices ( perhaps many devices) will support such routing.  My only experience in trying to do this was with RV042s in the inter-site VPN links.  And those did NOT work as described - subject to whatever limitations that my tests may have had.  I believe they won't do this but could be corrected.
I do believe it's correct that an RV0452 won't handle the *any* default route unless the WAN ports all point to the internet gateway.  This means at the site with the internet gateway, the RV042 has to be pointed WAN side "in" to the LAN.  That's how I get MPLS links to work.
And, it seems obvious that you can't do a VPN with: the WAN side of a VPN device pointing to a the LAN side of a VPN device and expect the VPN to work at all.  Well .. on an RV042 at least.  In general, all the WAN sides point to each other if there's a VPN link.  But some devices may be more capable/general in how they can be set up.
0
 
LVL 57

Expert Comment

by:giltjr
ID: 39752291
O.K., I went back and read through this again.

--> I do believe it's correct that an RV0452 won't handle the *any* default route unless the WAN ports all point to the internet gateway.

Yes it will, the problem is that if you want to talk to anything over the Internet, you would need to define specific routes for all the subnets you want to talk to on the Internet.  So it is best to leave the *any* default route pointing to the Internet.

I think I will go back to my originally statement.  You need to treat the VPN tunnels as they are unique links, don't think of them as tunnels.


You have at least 3 connections:

1) The Internet.
2) "Private link" to site#1, which just happens to be a VPN tunnel over the Internet.
3)  "Private link" to MPLS cloud.

In a normal setup you would have at least 3 routes:

1) Default route that points to the route to Internet.
2) Route for all IP subnets that exist at site#1 that points to the route to site#1.
3) Route for all IP subnets that exist in the MPLS network that points to the route to the MPLS network.

I can't tell if you are calling the MPLS network a VPN (which it technically is) or if you have a VPN tunnle to site#2 that goes over the MPLS network.  If you have a VPN tunnel that goes over the MPLS network, then you have a 4th connection and would need a 4th route.

Now when you route traffic over one of these links, the router at the other end also need to know how to get to the host you are trying to get to.

Again, just think of the VPN tunnels as their own unique connections to specific IP networks and use normal routing.
0

Featured Post

IT, Stop Being Called Into Every Meeting

Highfive is so simple that setting up every meeting room takes just minutes and every employee will be able to start or join a call from any room with ease. Never be called into a meeting just to get it started again. This is how video conferencing should work!

Join & Write a Comment

Data center, now-a-days, is referred as the home of all the advanced technologies. In-fact, most of the businesses are now establishing their entire organizational structure around the IT capabilities.
Shadow IT is coming out of the shadows as more businesses are choosing cloud-based applications. It is now a multi-cloud world for most organizations. Simultaneously, most businesses have yet to consolidate with one cloud provider or define an offic…
Get a first impression of how PRTG looks and learn how it works.   This video is a short introduction to PRTG, as an initial overview or as a quick start for new PRTG users.
In this tutorial you'll learn about bandwidth monitoring with flows and packet sniffing with our network monitoring solution PRTG Network Monitor (https://www.paessler.com/prtg). If you're interested in additional methods for monitoring bandwidt…

743 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

12 Experts available now in Live!

Get 1:1 Help Now