- SonicWALL does not support Group VPN (GDOI) or other mesh VPN technologies, leaving manual configuration as the only option.
- Configuring site to site VPNs for each and every site in your organization is time consuming, and depending on your SonicWALL model you may be limited by the number of IPSec tunnels allowed on your device (i.e. The TZ-105 only allows 5 IPSec tunnels).
I recently ran into this very situation. I was deploying a phone system at multiple sites for a customer, which required LAN-like communication between all sites. Rather than building tunnels at each site to every other site, I remembered the 'Forward packets to remote VPNs," feature. It would be great because it would save me time, as all traffic would just route through the hub site. However, in newer versions of the software this option is no longer present, so I had to do some research on how to make it work. I thought I would share what I did, since there is really no information out there (none that I could find anyway...) that walks you through the process.
For simplicity's sake, let's assume that we have 3 sites:
- Los Angeles - This is our main office (AKA the hub site). The LAN subnet for this site is 10.0.0.0/24.
- Austin - This is a branch office (AKA our first spoke site). The LAN subnet for this site is 192.168.0.0/24.
- Atlanta - This is a branch office (AKA our second spoke site). The LAN subnet for this site is 172.16.0.0/24.
Here are the general configuration steps:
- On Los Angeles (the hub site):
- Define address objects for each site under Network -> Address Objects:
- Los Angeles:
- Name: Los Angeles LAN
- Zone Assignment: VPN
- Type: Network
- Network: 10.0.0.0
- Netmask: 255.255.255.0
- Austin:
- Name: Austin LAN
- Zone Assignment: VPN
- Type: Network
- Network: 192.168.0.0
- Netmask: 255.255.255.0
- Atlanta:
- Name: Atlanta LAN
- Zone Assignment: VPN
- Type: Network
- Network: 172.16.0.0
- Netmask: 255.255.255.0
- Create an address group for each site under Network -> Address Objects:
- Create a group called Austin:
- Add Atlanta LAN
- Add Los Angeles LAN
- Note that we are calling this group "Austin" even though we are not adding Austin LAN to the group. This group will be referenced in a VPN policy that will allow both the Los Angeles LAN and Atlanta LAN subnets to communicate with Austin. More information to follow...
- Create a group called Atlanta:
- Add Austin LAN
- Add Los Angeles LAN
- Same thing applicable here as above. We are calling the group Atlanta because it will be applied to the Atlanta VPN, but these address objects we are referencing do not include the Atlanta LAN address object.
- Create VPNs to each remote site under VPN -> Settings:
- Create a VPN called Austin:
- Under the General tab:
- Policy Type: Site to Site
- Authentication Method: IKE using Preshared Secret
- Name: Austin
- IPSec Primary Gateway Name or Address: (public IP of Austin site)
- Shared Secret: (enter whatever password you want here, just remember that it has to match on both ends)
- Under the Network tab:
- Local Networks: (choose Austin from the list)
- Remote Networks: (choose Ausitn LAN from the list)
- Under the Proposals tab:
- This varies, but I usually choose IKEv2 mode, and AES-256 for encryption at the very least.
- Under the Advanced tab:
- Check the Enable Keep Alive check box
- Create a VPN called Atlanta:
- Under the General tab:
- Policy Type: Site to Site
- Authentication Method: IKE using Preshared Secret
- Name: Atlanta
- IPSec Primary Gateway Name or Address: (public IP of Atlanta site)
- Shared Secret: (enter whatever password you want here, just remember that it has to match on both ends)
- Under the Network tab:
- Local Networks: (choose Atlanta from the list)
- Remote Networks: (choose Atlanta LAN from the list)
- Under the Proposals tab:
- This varies, but I usually choose IKEv2 mode, and AES-256 for encryption at the very least.
- Under the Advanced tab:
- Check the Enable Keep Alive check box
- On Austin (the spoke site):
- Define address objects for each site under Network -> Address Objects:
- Los Angeles:
- Name: Los Angeles LAN
- Zone Assignment: VPN
- Type: Network
- Network: 10.0.0.0
- Netmask: 255.255.255.0
- Austin:
- Name: Austin LAN
- Zone Assignment: VPN
- Type: Network
- Network: 192.168.0.0
- Netmask: 255.255.255.0
- Atlanta:
- Name: Atlanta LAN
- Zone Assignment: VPN
- Type: Network
- Network: 172.16.0.0
- Netmask: 255.255.255.0
- Create an address group for the other sites under Network -> Address Objects:
- Create a group called Other Sites:
- Add Atlanta LAN
- Add Los Angeles LAN
- Create a VPN to the Los Angeles site under VPN -> Settings:
- Under the General tab:
- Policy Type: Site to Site
- Authentication Method: IKE using Preshared Secret
- Name: Los Angeles
- IPSec Primary Gateway Name or Address: (public IP of Los Angeles site)
- Shared Secret: (enter the same password you entered when you created the Austin VPN on the Los Angeles SonicWALL)
- Under the Network tab:
- Local Networks: (choose Austin LAN from the list)
- Remote Networks: (choose Other Sites from the list)
- Under the Proposals tab:
- Enter the same information you entered on the Los Angeles SonicWALL
- Under the Advanced tab:
- Leave everything as is
- On Atlanta (the other spoke site):
- Define address objects for each site under Network -> Address Objects:
- Los Angeles:
- Name: Los Angeles LAN
- Zone Assignment: VPN
- Type: Network
- Network: 10.0.0.0
- Netmask: 255.255.255.0
- Austin:
- Name: Austin LAN
- Zone Assignment: VPN
- Type: Network
- Network: 192.168.0.0
- Netmask: 255.255.255.0
- Atlanta:
- Name: Atlanta LAN
- Zone Assignment: VPN
- Type: Network
- Network: 172.16.0.0
- Netmask: 255.255.255.0
- Create an address group for the other sites under Network -> Address Objects:
- Create a group called Other Sites:
- Add Austin LAN
- Add Los Angeles LAN
- Create a VPN to the Los Angeles site under VPN -> Settings:
- Under the General tab:
- Policy Type: Site to Site
- Authentication Method: IKE using Preshared Secret
- Name: Los Angeles
- IPSec Primary Gateway Name or Address: (public IP of Los Angeles site)
- Shared Secret: (enter the same password you entered when you created the Atlanta VPN on the Los Angeles SonicWALL)
- Under the Network tab:
- Local Networks: (choose Atlanta LAN from the list)
- Remote Networks: (choose Other Sites from the list)
- Under the Proposals tab:
- Enter the same information you entered on the Los Angeles SonicWALL
- Under the Advanced tab:
- Leave everything as is
Upon completion, you will see a green light on the VPN -> Settings page, which indicates that the VPN is up. On the remote sites, you will see 2 green lights, indicating connectivity to both the hub and spoke sites.
I get the green lights but i am only able to ping the gateway address. Nothing on the other side of the vpn is accessible.
ReplyDeleteI would look at the firewall rules and verify that we are allowing LAN <--> WAN and WAN <--> LAN on both firewalls. I would also verify that there are no static NAT rules that are in place that would conflict with the LAN networks in question.
DeleteIf you get both VPN tunnels to the central site GREEN and you don't get connectivity between the remote sites you have to ADD a firewall rule from VPN > VPN that lets through the traffic. In it's simplest form "Source VPN > Destination VPN > Any Source > Any Destination > Any Service". (Our router is a NSA 4600 on SonicOS Enhanced 6.2.2.2-19n)
ReplyDeleteHello, great guide but unfortunately for us it's not working. We are using nsa2600 SonicOS Enhanced 6.1.2.3-20n. We have main office as 192.168.0.0/23, two remotes as 192.168.122.0/24 and 172.16.0.0/24. We can vpn to main from both sides but not able to pass traffic from one vpn to another. No drops, nothing. Rules were automatically created upon creating vpn with 2 source nets(according to the guide),but no joy. We even created rules to direct pass one vpn to another- the same. any ideas?
ReplyDeleteI would double check the VPN remote and local lan addresses and make sure that they are correctly configured.
DeleteSpencer, thank you for fast response! Seems to me that everything is set up correctly: remote1:
ReplyDeleteS~ 192.168.0.0/ 255.255.254.0 via 62.233.177.90 VPN-1
* 0.0.0.0/ 0.0.0.0 via 62.233.177.89 WAN1
S~ 192.168.122.0/ 255.255.255.0 via 62.233.177.90 VPN-1
C 62.233.177.88/ 255.255.255.248 directly connected WAN1
C~ 172.16.0.0/ 255.255.255.0 directly connected LAN1
Remote2:
Key: C - connected, S - static, R - RIP, * - default, ~ - private
S~ 192.168.0.0/ 255.255.254.0 via 62.233.177.90 VPN
* 0.0.0.0/ 0.0.0.0 via 62.233.177.89 WAN1
C~ 192.168.122.0/ 255.255.255.0 directly connected LAN
C 62.233.177.88/ 255.255.255.248 directly connected WAN1
S~ 172.16.0.0/ 255.255.255.0 via 62.233.177.90 VPN
Above two are Drayteks (yeah, I know..)
the HQ nsa:
LAN > VPN 1 lanAnd_172 draytek-192_168_122
LAN > VPN 2 lanAnd_122 draytek-172_16_0
VPN > LAN 4 draytek-192_168_122 lanAnd_172
VPN > LAN 5 draytek-172_16_0 lanAnd_122
VPN > VPN 3 draytek-192_168_122 lanAnd_172
VPN > VPN 4 lanAnd_172 draytek-192_168_122
VPN > VPN 5 draytek-172_16_0 lanAnd_122
VPN > VPN 6 lanAnd_122 draytek-172_16_0
Every rule is allow any any. Everything created automatically upon creating vpns.
lanAnd_172=local lan 192.168.0.0/23+vpn 172.16.0.0/24
lanAnd_192=local lan 192.168.0.0/23+vpn 192.168.122.0/24
draytek-192 and 172 are remote vpn lans.
Am I missing something?
as addition I found a source of connection problem:
DeleteEthernet Header
Ether Type: IP(0x800), Src=[00:1d:aa:9f:27:01], Dst=[c0:ea:e4:cb:d7:d3]
IP Packet Header
IP Type: ICMP(0x1), Src=[172.16.0.1], Dst=[192.168.122.1]
ICMP Packet Header
ICMP Type = 8(ECHO_REQUEST), ICMP Code = 0, ICMP Checksum = 4579
Value:[1]
DROPPED, Drop Code: 339, Module Id: 20, (Ref.Id: _585_krugeQevgqpKprwv) 1:1)
but the code means:
339 Octeon Decrypyion Failed for inbound packet
???
Ok I have managed to find the reason and solution. Drayteks cannot properly send packets of you specify more than one network for single vpn. To workaround you need to create separate profile on draytek to each network it has to connect. There is an additional option called something like "create separate phase2 tunnel for each network" and this works same way like above workaround. Regards
DeleteFor the hub site, I had to assign the local network Address Object to the LAN zone instead of VPN zone, then things began working as intended.
ReplyDeleteI know your expertise on this. I must say we should have an online discussion on this. Writing only comments will close the discussion straight away! And will restrict the benefits from this information. vpn schweiz
ReplyDelete