Open port through Tunel Interface (SonicWall)
Hello,
I wonder if it's possible that some ports are blocked between a VPN (Tunnel Interface).
Here is my problem:
We have 10 access points Adtran Bluesocket BSAP-1925.
9 of them are connected to our local network (headquarters). Everything works perfectly.
We also have a remote site with one access point. There is a VPN (Tunnel Interface) between the 2 sites.
At the remote site we have a domain controller, file server and a backup server, we have no problem.
However, the access point at the remote site is not able to connect to the management server, where all the other
Access points are connected.
When the access point is at the main site, it is able to connect to the management server.
I also have in my possession the ports used by the management server and the access point to communicate together.
Is it possible that these ports are blocked in the VPN connection?
The management server is a Bluesocket vWlan V2_3_0_09.
Thank you
I wonder if it's possible that some ports are blocked between a VPN (Tunnel Interface).
Here is my problem:
We have 10 access points Adtran Bluesocket BSAP-1925.
9 of them are connected to our local network (headquarters). Everything works perfectly.
We also have a remote site with one access point. There is a VPN (Tunnel Interface) between the 2 sites.
At the remote site we have a domain controller, file server and a backup server, we have no problem.
However, the access point at the remote site is not able to connect to the management server, where all the other
Access points are connected.
When the access point is at the main site, it is able to connect to the management server.
I also have in my possession the ports used by the management server and the access point to communicate together.
Is it possible that these ports are blocked in the VPN connection?
The management server is a Bluesocket vWlan V2_3_0_09.
Thank you
Do more with
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
Hi Janio Andre Gutierrez Gutierrez,
It is possible that the correct routes are not in the VPN tunnel. The routes/subnets need to match where the devices are located.
Let me know how it goes!
It is possible that the correct routes are not in the VPN tunnel. The routes/subnets need to match where the devices are located.
Let me know how it goes!
Hi Diverseit,
The routes/subnets objects have to be on the "Main" SonicWall (Headquarters) ?
Thanks
Janio André Gutierrez
The routes/subnets objects have to be on the "Main" SonicWall (Headquarters) ?
Thanks
Janio André Gutierrez
I don't know your network but basically whatever you want to communicate on either side needs to be in both policies (on each firewall).
So, if your WLAN manager is in Site A (HQ) on 10.10.x.x/16 and your troubled WAP is in Site B on 173.2.x.x/16, then Site A and Site B's VPN policy would need to include the local and remote subnets , in addition to the other subnets, under the Network Tab. I 'd create Address Object Groups if there are multiple subnets/VLANs in each Site location.
Example:
Site A
LAN = 10.1.x.x/16 (contains Servers)
LAN = 10.10.x.x/16 (contains the WLAN Manager)
WLAN = 172.16.x.x/16 (contains WLAN devices)
Site B
LAN = 192.168.0.x/24 (contains Servers and PCs)
WLAN = 172.2.x.x/16 (contains WLAN devices, including the troubled WAP)
In this scenario, the VPN policy for Site A under the Network tab would read:
Local Networks = The Address Object Group for Site A (which would consist of 10.1.x.x/16, 10.10.x.x/16 & 172.16.x.x/16) provided that you want the the sites to communicate on all of these subnets.
Remote Networks = The Address Object Group for Site B (which would consist of 192.168.0.x/24 & 172.2.x.x/16) again provided that you want the the sites to communicate on all of these subnets.
You'd then do the the same but flipping the objects for the Local and Remote on Site B's VPN Policy.
On the Advanced tab of both VPN policies I'd check Enable Keep Alive and Enable Windows Networking (NetBIOS) Broadcast as well.
Keep Alive uses heartbeat messages between peers on this VPN tunnel. If one end of the tunnel fails, using Keepalives will allow for the automatic renegotiation of the tunnel once both sides become available again without having to wait for the proposed Life Time to expire.
Enabling Windows Networking (NetBIOS) Broadcast will allow access to remote network resources by browsing the Windows® Network Neighborhood.
Make sense?
So, if your WLAN manager is in Site A (HQ) on 10.10.x.x/16 and your troubled WAP is in Site B on 173.2.x.x/16, then Site A and Site B's VPN policy would need to include the local and remote subnets , in addition to the other subnets, under the Network Tab. I 'd create Address Object Groups if there are multiple subnets/VLANs in each Site location.
Example:
Site A
LAN = 10.1.x.x/16 (contains Servers)
LAN = 10.10.x.x/16 (contains the WLAN Manager)
WLAN = 172.16.x.x/16 (contains WLAN devices)
Site B
LAN = 192.168.0.x/24 (contains Servers and PCs)
WLAN = 172.2.x.x/16 (contains WLAN devices, including the troubled WAP)
In this scenario, the VPN policy for Site A under the Network tab would read:
Local Networks = The Address Object Group for Site A (which would consist of 10.1.x.x/16, 10.10.x.x/16 & 172.16.x.x/16) provided that you want the the sites to communicate on all of these subnets.
Remote Networks = The Address Object Group for Site B (which would consist of 192.168.0.x/24 & 172.2.x.x/16) again provided that you want the the sites to communicate on all of these subnets.
You'd then do the the same but flipping the objects for the Local and Remote on Site B's VPN Policy.
On the Advanced tab of both VPN policies I'd check Enable Keep Alive and Enable Windows Networking (NetBIOS) Broadcast as well.
Keep Alive uses heartbeat messages between peers on this VPN tunnel. If one end of the tunnel fails, using Keepalives will allow for the automatic renegotiation of the tunnel once both sides become available again without having to wait for the proposed Life Time to expire.
Enabling Windows Networking (NetBIOS) Broadcast will allow access to remote network resources by browsing the Windows® Network Neighborhood.
Make sense?
Premium Content
You need an Expert Office subscription to comment.Start Free Trial