We have acquired a small company which uses a Sonicwall PRO 1260 firewall and I have configured a Site-to-Site VPN tunnel from the Sonciwall to our Cisco ASA firewall. Behind the Cisco ASA firewall I have 8 different subnets. I have configured the VPN connection on the Sonicwall to use an Address Object Group which contains all the required subnets.

The VPN tunnel from Sonicwall to Cisco ASA establishes fine and I have full connectivity from the remote site to 'subnet 1'. From 'subnet 2' (and all others), the only traffic that gets through to the remote network is ICMP (ping), http and https.

I know this screams 'access rules' but I have spent hours pouring over the Sonicwall and can find no access rules that would cause all traffice except the services mentioned above to be blocked. The Sonicwall automatically creates access rules from LAN > VPN and VPN > LAN that say 'allow any host, any service, all the time' - these rules cannot be modified, deleted or deactivated (only by removing the VPN).

I have exactly the same configuration setup for 5 other remote sites using site-to-site VPN, connecting to the same Cisco ASA and everything works fine however those sites are using Fortigate firewalls so I'm sure this is related to the Sonicwall.

Question 1: Has anybody experienced the same issue and how did you resolve it?

Question 2: What command do I need to run via CLI on the Sonicwall to get a full text output of the running configuration?

Thanks in advance for any assistance.


Do you have each of the subnets in question defined as VPN subnets in the Sonicwall network object configuration? If you have them classified as LAN or WAN, then your "LAN to VPN" rules won't apply to them even if you have them defined in the VPN tunnel. I'm not sure if this applies to the model you have (ours are TZ17/8/90 and 3060s, but if it is running the SonicOS, I think it does)


Thanks for the comments Kevin, I had thought of this but actually tested using the Address Object for the subnet which was working by classifying the object in turn as a LAN or WAN or VPN object but it made no difference, it worked in all cases. It would seem that the auto-added VPN rules for the site to site VPN disregard what you manually classify the object as.

Long story short, this testing led me to question more and more if the Sonicwall was actually the problem - in the end it wasn't. After much the Cisco ASA at the other end is managed by a hosting service and therefore out of my control. After looking at the config for the ASA we found that the genius who added the rules for the other end of the VPN connection had placed an access rule after a 'deny all' rule. Moving the access rule ahead of the deny all rule solved the problem immediately.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy