Go Premium for a chance to win a PS4. Enter to Win

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 5322
  • Last Modified:

Sonicwall Blocking Outgoing VPN Connections

ANother Sonicwall issue, not becoming a Sonicwall Fan at all. Never have I had so many issues with Sonicwall. It might also be that the past Provider were idoits but I would past judgement.

Anyways!  We have a Contractor that uses his old PC and Connects to his Companies Network Via a Cisco VPN Connection. Now it seems that our Sonicwall is blocking that connection so I am being told. How do I go about allowing a VPN Connection using say 11.11.11.11 IP Address leaving the internal Network. Would it be the IP address or would it be the Protocol...

Please be discriptive
0
rperault
Asked:
rperault
  • 6
  • 5
  • 4
2 Solutions
 
ccomleyCommented:
Hmm.

By default Sonicawll doesn't block ANY outgoing traffic, and all incoming. You need to create rules to vary this. But on a newer machine you may also have the Application Firewall blocking traffic based on it's profile. So we really need a bit more information on what's going on here.  What version are you running? What Security tools are enabled?

To permit outbound traffic that's being blocked you need to identify why.

BUT

If it's being blocked by an explcit DENY rule in the "Lan to Wan" section of Firewall/AccessRules then you can

- disable that rule or delete it completely - if you don't mind anyone using VPNs
or
- create a PERMIT rule which permits his IP address specifically to access the WAN on that port, which will automatically over-ride the more general "everyone can't" rule.
0
 
digitapCommented:
You also may want to view the logs to see if it's dropping those connections.  My guess is their end isn't allow NAT traversal since the Cisco clients are being a router that NATs traffic to the Internet.
0
 
rperaultAuthor Commented:
All of the things I have already checked..
Nothing in the Logs with the specific IP address except for my Ping Requests.
I created Special ACL's to allow traffic to the IP address and using Port 500/4500 So it has to be somewhere and I don't believe that it is on my end. Actually I am pretty sure that it is not. We recently changed ISP Providers, from Verizon to CavTel. The Connection never had an issue with Verzion but all of a sudden has one with Cavtel.

I worked with CavTel and I am told it not them. Though they aren't checking the upstrean Checkpoint Firewall for activity. I need to get ont he phone with the other end and see what they are doing different. Any other ideas?
0
 The Evil-ution of Network Security Threats

What are the hacks that forever changed the security industry? To answer that question, we created an exciting new eBook that takes you on a trip through hacking history. It explores the top hacks from the 80s to 2010s, why they mattered, and how the security industry responded.

 
ccomleyCommented:
Hmm. I would not discard the idea taht it could be the new ISP totally, it would not be the first time I've come across an ISP blocking VPN access. In the case I have in mind, it was initially in all innocence as the ISP were trying to introduce their own commercial VPN product and thus "grabbed" IKE traffic without realising it would cause people problems - but I was less inclinde to be nice about it when they didn't immediatly stop doing this on discovering they were wrong.

If it's an outbound connection, it should be covered by the default rule unless someone has created a specific one. In which case revoke it or create a MORE specific permit rule.

Other than that I don't know. Can you put Wireshark on the WAN side of the Sonicwall? (I keep a small managed switch with port mirroring enabled in order to do this sort of thing...)

What routers are in use between the Sonic wan port and the comms link? Is that the SAME router or did that change at the same time as the ISP swap?
0
 
digitapCommented:
Perhaps a long shot, but have you checked the MTU on WAN interface of the sonicwall?  Here's an article I wrote on how to set that on the Sonicwall.

http://www.experts-exchange.com/viewArticle.jsp?aid=3110
0
 
ccomleyCommented:
Good idea, as the VPN encapsulation process will make the packets from that sender longer!!!

Can't hurt to knock it back a few bytes and see if it helps.
0
 
digitapCommented:
One can certainly believe the NSA 240 does behave differently.  I remember when the 190 came out.  We had all sorts of trouble getting it to work with ISP provided WAN IP addresses on cable modems.  We worked with support from the ISP and Sonicwall.  Never could get it to work.  Ended up putting a 170 and it worked flawlessly.  Later, we discovered it was due to an improperly configured MTU.  These days, we have calculating this as our setup process for all our clients...regardless of the type of internet connection.
0
 
ccomleyCommented:
We hit MTU problems really early in the ADSL era with TZ170s and onwards, and now we click it down a couple of bytes automatically, so much so it didn't occur to me to mention it here until your suggestion!

I've not found the TZ190 to be any worse, better, or, indeed, any other way different from earlier TZs or NSA and above units. They run the same code, at the end of the day! Might've been an issue with a particular code ver.

We often have problems with the main "cable/fibre" ISP in the UK as they don't assing a block of IPs, they assign a random selection of numbers which can't be defined as a network/mask chunk and don't seem to think this is at all unusual.

0
 
rperaultAuthor Commented:
My Problem is that nothing has changed in the Configuration and it always worked with the past provider, but it woudn't work with the current provider. It's Weird.
0
 
digitapCommented:
no way to know until we try.  good luck and let us know how it goes.
0
 
ccomleyCommented:
Try reducing the MTU anyway - it may be an issue with the way your new provider's network operates! If that doesn't work then I suggest you are going to need to try to Sniff the network outside of the Sonicwall to see fi the packets in question are getting through! If they are you can defintily blame your new supplier, if not, it's definitly a Sonicwall issue.
0
 
digitapCommented:
i concur.
0
 
rperaultAuthor Commented:
Sorry I had thought I had choosen the Correct Expert
0
 
rperaultAuthor Commented:
I am now unable to assign points. Sorry Guys I got swamped and Fast so I apologize for my delay in response because it is unlike me. I agree in spliting the points, as one had Mentioned the MTU and the Other explained..... If I could award the points please
0
 
digitapCommented:
thanks for the points!
0

Featured Post

Lessons on Wi-Fi & Recommendations on KRACK

Simplicity and security can be a difficult  balance for any business to tackle. Join us on December 6th for a look at your company's biggest security gap. We will also address the most recent attack, "KRACK" and provide recommendations on how to secure your Wi-Fi network today!

  • 6
  • 5
  • 4
Tackle projects and never again get stuck behind a technical roadblock.
Join Now