Im having an issue at my office and was hoping to get some help on it. I have attached a diagram so that it is easier to understand everything. We had to setup a vpn tunnel from a sonicwall device(offsite) into our sonicwall tz170. I attach a pc to my sonicwall and it receives a 192.168.0.151 address from it. The tunnel works fine, i am able to ping pc's connected to the sonicwall on the other end(192.168.209.x), and the other end can ping my system which is plugged directly into the sonicwall. But the other end is not able to ping any systems on our internal network that do not have the gateway set to 192.168.0.150 (The IP of the sonicwall). Now im sure this looks confusing, i didnt set it up nor do i have any say in changing it. All the gateways on the 192.168.0.x network are set to 192.168.0.1, the ip of our server. As a test I had changed one of my systems gateways from 0.1 to 0.150 and it was able to be seen from the other sonicwall.

The main reason for this tunnel is for offsite access to our as400 box located at 192.168.0.119. On my system that i connected directly to my sonicwall(that receives a 192.168.0.151 address I am able to ping all systems on the 192.168.0.x network, including the 192.168.0.119 as400. Is there any way that this could work without changing the gateway of the as400 to 0.150? If this isn't clear enough please let me know what I need to explain better.

Thanks,
John

http://i102.photobucket.com/albums/m...awing1copy.jpg

I believe that your entire problem rests with the routing that is set up on the internal network. In short, the Sonicwall is at the wrong place on the network topology. No one knows to send packets to it. No one thinks of that Sonicwall as being a passageway to the outside world.

The existing routing tables in all of the client-machines tell them that "local" addresses can simply be sent straight to the target machine, and that all "non-local" addresses must be sent to the Gateway Server machine at local-address 192.168.0.1.

The "local" addresses covered by the VPN-tunnel address range, however, cannot "simply be sent straight to the target machine." They must, instead, somehow be delivered to the Sonicwall.

The most practical way to do that is to, first of all, ensure that the address-range being served by the Sonicwall does not overlap the address-range that is being used by "truly local" network clients. For example, if the addresses 192.168.0.XXX are "truly local," you set up the Sonicwall to expect to tunnel the addresses (say) "192.168.1.XXX."

Make sure that the netmasks used by the local machines do not encompass "192.168.1.XXX." Therefore, they'll send packets for those addresses to the Gateway Server.

Now, in the Gateway Server, you need to set up a routing-table entry that will reflect "192.168.1.XXX" addresses to the Sonicwall, who will deliver them to the other side.

On the other side, that is to say "your" side, you need to be sure that the ENTIRE "local" address range ... 192.168.XXX.XXX ... gets sent to "your" Sonicwall, which will then tunnel it through. Upon arrival at the other side, the Sonicwall can simply put the packets into the local network for delivery.

P.S. One other fine point ...

Be sure that the Gateway Interface machine knows which ethernet card to send the packets out on, to get them to the Sonicwall.

In retrospect, yes, you do want those to go out of the "inside" interface; that is to say, the same ones they came in on.

When talking to clients who are on the other side of the wall:
-> Most network machines simply know to send them to the GI.
-> The GI knows to forward the traffic to the Sonicwall.
-> The Sonicwall(s) take care of the tunneling.

Some attention should also be put to "where do the packets go from there, to get 'outside?'" The encrypted packets could theoretically bounce right back to the GI machine, hopping from one interface to the next and they're on their way. In moderate traffic scenarios that's fine. In high-volume that's placing a bit of pressure on the GI machine because packets have now bounced through it twice.

"That's what routers do," of course. A general-purpose machine can sometimes be an expensive "router." If the machine (the GI machine) is also tasked to do "other" things, such as to 'be' the DMZ, the competing workloads and duties can become a bottleneck. But only with truly high volume. (Tell the VPN clients to please lay-off the YouTube and iTunes. ;-) )