Hello.

Here is the situation:

We created a point-to-point VPN tunnel using 2 sonic wall 3060 devices locally at my office using 2 different T1 from 2 different ISP in order just to test them out.

Basically, as soon as the connection was established, the internet died for the entire company. As soon as the was tunnel was shut down, the internet started working again.

My question is does simple creating a point-to-point VPN tunnel between 2 points require an enormous overhead on bandwidth that may of exceeded the T1 capacity? The tunnel was simple established but no data was being transferred with it.

I must also point out that my network also as 2 juniper VPN tunnel on both the T1 connecting to another office in Boston. I am not sure if that was a factor in what caused the internet to crash when the sonic wall VPN tunnel was established.( perhaps something conflicting)

Also, I will mention that we have people with the sonicwall VPN client software who connect remotely.

1.No network performance loss happens with the Juniper tunnel which have been running for years( but installed by the company in Boston so we were not involved in the configuration)
2.No performance loss with the remote sonicwall VPN software clients connecting.
3.It only happened with the VPN tunnel between the 2 sonicwall 3060 servers.( These are also our firewalls)

Unfortunately we have not yet installed the MRTG software so we have no way of knowing the actual use of bandwidth.

I was wondering if there may be a common network mistake made when doing a point-to-point tunnel with a VPN that would kill the internet.

Thanks.

In theory it should work fine. I would guess you had put in an IP that was in use or something similar. There may have also been DHCP servers on both devices that was confusing the clients, etc.

The bandwidth usage of a tunnel with no data is very minimal, just "I'm alive" chatter back and forth.

Are both T-1s connected to your local network? What are they currently used for? Sounds like a routing issue on the surface, or, as djweis mentioned, an ip conflict. I would be inclined to run some ping and traceroute tests on the clients just to see where the traffic is going.

I really do not know how you have set this up but on a PIX or an ASA when you build the tunnel you have to create a nat(0) or "no nat" policy that says when my tunnel is up DO NOT NAT the traffic destined to xxx.xxx.xxx.xxx where xxx are all of the network addresses of the destination tunnel, all other traffic go out to the internet. Here is how I set it up in my PIX -

access-list 100 permit ip 192.168.1.0 255.255.255.0 192.168.202.0 255.255.255.0
access-list 100 permit ip 192.168.2.0 255.255.255.0 192.168.202.0 255.255.255.0
access-list 100 permit ip 192.168.3.0 255.255.255.0 192.168.202.0 255.255.255.0
access-list 100 permit ip 192.168.4.0 255.255.255.0 192.168.202.0 255.255.255.0
!
global (outside) 1 interface
nat (inside) 0 access-list 100
nat (inside) 1 192.168.0.0 255.255.0.0 0 0
!
Like someone mentioned allow ICMP and run some traceroutes.