VPN chaining
Talleyrand
Newbie ✭
OS 6.5
so hub & spoke VPN between 3 sites works fine
However if we need to tunnel from 1 spoke, thru spoke2 & to the central hub.
yes we have reasons, and it is not something i would normally do, i would just go spoke to hub, but that is not possible.. sometimes...
what is the best way? without SDwan
if the hub is 172.18.5.n, then it is not a simple case of just directing spoke2 to another spoke, since the return traffic from the hub would not know which is the endpoint. 1 or 2
do we need something like
hub real ->spoke1 dummy->nat->spoke1 dummy->spoke2
172.18.5.n->192.168.5.n->(NAT at spoke 1)->192.168.6.n->192.168.1.n
192.168.1.n->192.168.6.n->(NAT at spoke 1)->192.168.5.n->172.18.5.n
where 192.168.5.n & 192.168.6.n are dummies at spoke 1 used purely to ensure the traffic is correctly routed locally in spoke1 or passed thru to spoke 2
so traffic from spoke 2 hits a gateway in spoke 1 , is natted, then passed to another subnet for exit.
(since sonicwall will nto allow over lapping addresses)
Answers
Hi @Talleyrand , presuming you are using SonicWalls at all the sites :
change the policy type to Tunnel Interface in the vpn policy rather than Policy based (site to site) on all three of the sites. you can still do hub and spoke by using the Source and Destinations in the route policies
but not using the ( VPN Tunnel Interfaces) in the Interfaces Page, this is only needed for Advanced routing)
with the Tunnel Interface method you have a lot more flexibility regarding subnets via the custom routes, so you can route the destination traffic via two separate VPN policies with different metrics, which from your description is what you need to do.
you can also if needed use network ranges via the custom routing which isn't possible via the policy based method
have you read this thread?
https://community.sonicwall.com/technology-and-support/discussion/comment/9785
This is NOTHING like the same thing.
clients are easy since they appear in the subnets of a local firewall and the routing takes care of it.
there is no duplicate routing/ split routing.
Wont work due to the sonicwall......
1.you cannot have multiple VPN type setups on the same external peer address at other end (site to site & tunnel interface)
which we need since not every site world wide is using "sonicwall", preventing "tunnel int."
the sonicwall instructions state clearly you must use the ip addess listed on the interface zone
so if you have a single external connection with 16 ip addresses, they all come into 1 zone, due to the subnet mask
you are expected to use firewall routing to pick off the other ip addresses, but since the VPN is bound to the ZONE not the ip address!!!!
you cannot have multiple VPN settings on a single zone even if you have multiple addresses in the subnet.
so if your X1 interface is bound to 192.168.0.55/24
You CANNOT setup a virtual interface with x1:y1 192.168.0.56 and use that to accept vpn traffic
and at the other end it will not allow you to have site to site & tunnel interface bound to 192.168.0.55
even if you setup the x1 interfaces at each end to other ip addresses in the sub net range, the connection will not come up.
Hi @TALLEYRAND,
Do you have overlapping subnets across Spoke 1 and 2? Are you trying to access the resource between Spokes via Hub?
Regards
Saravanan V
Technical Support Advisor - Premier Services
Professional Services
No there are no over lapping subsets.
and NO i'm not trying to go spoke->hub->spoke, that is EASY.
I want to go spoke to spoke, without adding another damned leased line
The overlapping subnets occurs if you try to assign a virtual interface to a wan as a way of adding another ip address.
When building VPN you can ONLY send traffic for VPN to an interface.(in the VPN advanced tab.)
which is garbage, if you consider a "interface" can cover a full subnet.
The vlan then forcefully sends the traffic to the ip address that is registered in the interface tab, with no regard for other ip addresses in the same external subnet.
so you would think . ah,,, lets just add an "virtual interface" to the base interface using one of the spare external ip addresses
but no.... you cannot , since then you get a message saying, that the base interface is overlapping!!!!!!
so you can only add 1 type of VPN to a gateway address, you cannot add a "tunnel interface" with a n extrnal target the same as a "site to site.
and you might then say "well just make it all "tunnel", but then.... you realise you have a multi country network that not everyone is using sonicwall, so you MUST use site to site for those connections.
So even if you have a 100Gb/S optical link, you can only use 1 ip address that is bound to an interface base.
and sonicwall expects all other "ip addresses in the subnet" are handled by internal routing rules.. which is garbage, because they tie the interface to a single damned ip address, that all the VPN traffic goes out over.
This could ALL be solved , by sonicwall saying ah..... you have a subnet that is more than 1 ip address on your wan....
I'm gonna let you setup virtual interfaces for the other ip addresses.
at which point you can tie your VPN interface to a virtual, set up your damned routing & allowable types and get the damned packets out of another ip addess in your WAN subnet.
The really sad thing ..... is if i added some cheap crappy wifi router between one of the other interfaces
and then plugged BOTH sonicwall ports into that cheap crap....
I could then set another interface with a different ip, do NAT in my cheap crap & it would all work....
hi @Talleyrand, yes if you are not using SonicWalls at each site you won't be able to do what you want,
it sounds like you are overcomplicating, you would be better putting up network diagrams, with simple diagrams there is less chance that people reading will misread what you are actually trying to achieve the scenario you have and then the scenario you want to achieve.
if the other Sites even though they are not SonicWall do support route (tunnel) based vpn you may still be able to achieve using this method depending on the other vendors capabilities, with policy mode (site-site) though it is not possible.
The devices involved in this ARE sonicwalls. all 3
BUT, the sonicwalls also have to connect to NON sonicwall devices, HOWEVER they are not part of the spoke to spoke path.
the issue is that sonicwall will not allow two types of VPN on the same WAN subnet, even if there are multiple ips in that subnet.
so for example if i have :
1.1.1.1/24 assigned to X1 WAN
i CANNOT use any of the other 250ish ip addresses as a WAN VPN ingress/egress point....