Routing packets, destined for subnet #3, from subnet #1, via VPN A to subnet #2 and hence to subnet #3 via VPN B.
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:
https://www.experts-exchange.com/questions/22673991/Routing-from-subnet-1-through-VPN-to-subnet-2-through-router-to-address-on-subnet-3.html?anchorAnswerId=19419853#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.
https://www.experts-exchange.com/questions/22673991/Routing-from-subnet-1-through-VPN-to-subnet-2-through-router-to-address-on-subnet-3.html?anchorAnswerId=19419853#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.
ASKER
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"??
"if it does" means "I don't know"??
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.
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.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
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?
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?
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
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.
ASKER
giltjr:
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.
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.
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.
--> 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.
--> 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.