Join the Conversation

To sign in, use your existing MySonicWall account. To create a free MySonicWall account click "Register".

Connect to a remote Side over VPN


i have the following issue:

A costumer of me has differnet remote sides. one in europe, one in Amerika one in south america.

Different User are connected on the remote firewall with the GVC Sonicwall VPN Client. The DHCP Server is the internal AD DHCP Server and it is working fine. The user connect becomes a IP from the internal dhcp server and can connect to the differnet side's. from america to europe etc. now the costumer wants to have a deticated ip range from the vpn clients ( not anymore the internal dhcp server). i reconfigured the DHCP server from the sonicwall that the client becomes now a deticated ip range ( comes form the DHCP Server from the Sonicwall). That works, user connect, becomes a ip from the sonicwall dchp server and can work, but he can not connect anymore the the remote location, name resolutions works, but no connection anymore, i read some articel about it, but it does not solve my issue. did somebody konw, what i have to do that the client form america can connect after he becomes a ip from the america firewall to europe, do i have to setup some firewall rules, that these ip can connect over the vpn tunnel to the remote location ?

Thanks for your help

Category: Mid Range Firewalls


  • BWCBWC Cybersecurity Overlord ✭✭✭

    @frank123 you should check that you have the appropiate rules on the Zone VPN to Zone VPN for the site where your GVC users connecting to and trying to access a remote site. On the remote site you have to make sure that Zone VPN to Zone LAN access rules are matching for your remote GVC network.

    All related networks in the VPN routing configuration (Local/Remote network) have to cover the GVC networks as well.

    It's not complicated, but you have to pay attention to the details.


  • frank123frank123 Newbie ✭

    Ok will check the settings....thx

  • frank123frank123 Newbie ✭



    i tried these morning.....setup the dhcp again from the remote side and checked if the users can log on there, that works. when i trace the packets i see the remote location from the network send the data's out to the vpn -> direction europe, that should be also fine. i enable a firewall rule on the main sonicwall, where all the traffice can pass from the remote location to the internal (firewalled netoworks) and i checked if these works, but no traffic hit these rule. i checked the routing and setup a route, that the traffic from the main location to the remote side for these traffice....but still now success :-( can i check some more ?


  • BWCBWC Cybersecurity Overlord ✭✭✭

    @frank123 what kind of VPN you're using, Site-to-Site or Tunnel Interface? I guess Europe is your main site?

    Did you have the GVC network from your remote site configured on the main site pointing into the Tunnel?

    Did you do a Packet Monitor on both sides to see if any traffic gets dropped or goes the wrong way?


  • frank123frank123 Newbie ✭


    @BWC it is a IPSEC Point to Point tunnel....and yes Europe is the main side.....

    When i'm connected to the Remote Side with my GVCS Client and i make a ping to the europe side....i see that the firewall send the packets to the tunnel....

    I think the firewall rule on the main side... (do i have to do 2 Rules one for incomming and the other for outgoing ? i sugest yes or ?)..will check again...but i can do it do only in the morning hours.....;-)


  • BWCBWC Cybersecurity Overlord ✭✭✭

    @frank123 then we are talking site-to-site, I guess. It's either Site to Site or Tunnel Interface.

    Remote site: You defined a group object covering all local networks (including the GVC client network) and used that group as local network in your tunnel definition? Does the Active VPN Tunnel listing show multiple SAs pointing to your main site?

    Main site: You just need a single rule from Zone VPN to LAN (if this is where you need to connect), because it's stateful. This might change if you need to access the GVC clients from the Main site. Make sure that you have the GVC client network defined and have it in the Group used as Remote Network in your Tunnel definition.

    Does the Packet-Monitor on the Main site does show any traffic regarding the ping test?


  • seems to me a firewall rule...

    Do you monitor the link? Is there a package being dropped?

  • frank123frank123 Newbie ✭

    hi...checked yesterday again the settings....establish the vpn on the remote side, internal name resolution works, and i have access to the internal server's. enable the packet monitor and setup a rule how monitor my ip and the remote ip into the main location. i see on the log that the ip from me will be cosumend and forwared. but on the firewall ( setup also the packet filter) is see nothing.

    i setup a firewall rule into the main location with the ip range from the remote location should enable all the traffice ( any any) to the vpn, but these rule will never been hit....

    dont know why...the firewall in the main locatin know the ip range and resit into the vpn ...( the firewall into the main location should know what should be done with these net or ?).....

    a little bit lost at the moment :-(

  • BWCBWC Cybersecurity Overlord ✭✭✭

    @frank123 if your tunnel configuration is properly configured (including all relevant local and remote networks on both sides), did you added the main site network in the VPN access tab of your remote site to have the client traffic destined to main routed via GVC?

    The traffic should be handled then via VPN-VPN Access rules on the remote site and VPN-LAN on the main site.

    Just make sure that the relevant SA's got established on both sides.


  • frank123frank123 Newbie ✭

    yes the tunnel is working fine , main location /24 remote location communication over ipsec into these location i setup the dhcp ipsec pool on the firewall to / 24....and as i said external -> ( dhcp inside) it works to but when i come with 24 i can communication internal but not to :-(

Sign In or Register to comment.