Sonicwall and XP Help!!!

I have installed a Sonicwall Firewall at both sides of a VPN. Sonicwall,
for security reasons, has the wired and
wireless in their router set up with two separate IP addresses. 172.x.x.x
for
wireless and 192.x x xfor wired. The Main office has a Server with WINS
installed, so the wireless laptops are able to connect to the wired network,
using the WINS server
but at the branch office, there is no Server, and wireless laptops are
unable to connect to the wired computers
and cannot print: the printer is shared on one of the desktops.
There is a setting in the Sonicwall to assist with the probem, but it is not
enough.

Does someone have a solution for this? I posted already once, but thought I
would try again.

It is still us same guys trying to answer the questions. There's about half
a dozen or so of us and we often try to cover multiple groups. I monitor 12
groups and try to answer questions in about 7 of them.

I remember your post, but I don't think I ever fully understood the
situation. This does not sound like a wireless -vs- wired situation, or
have anything to do with XP either,...it seems to be just a plain old
networking issue. Please try to re-explain the situation without specifying
anything about what "medium" the data travels over. Whether the data moves
over "air" or "copper" is really irrelevant. Even the fact that it is VPN
is irrelevant,...it would be the same even if it was all in the same
building,...VPN is just a Virtual Private WAN over the Internet instead of a
true Private WAN over a leased line, but either way it is still just a
Private WAN link.

Here's a few things to think about:

If each Sonicwall is involving two subnets (192 & 172), then that means the
same is propbably happening at both ends,...which gives you 4 subnets. So if
you have the same IP ranges being used at both ends then you have an
unresolvable routing issue,...so you have to make sure that the 192 Sets and
the 172 Sets are all completely unique.

Example:

Site #1
Subnet-A = 192.168.1.0/24
Subnet-B = 171.16.1.0/24

Site #2
Subnet-C = 192.168.2.0/24
Subnet-D = 172.16.2.0/24

[WINS Srv]
[& Clients #1] [Clients #2]
| |
192.168.1.0/24 171.16.1.0/24
\ /
\ /
[S-wall #1]
|
|
<WAN>
|
|
[S-wall #2]
/ \
/ \
192.168.2.0/24 171.16.2.0/24
| |
[Clients #3] [Clients #4]

If you only have one WINS Server,...let's say it is 192.168.1.5,...then all
machines, no matter where they are, no matter what subnet they are
in,...will use that same WINS Server. But it is the job of the "routing
scheme" to make the WINS Server "reachable" to the Clients. It is not the
job of the WINS Server. The SonicWall boxes are effectivly being the
"routers" so it is up to them to make that happen.

What I've said obvoiusly doens't give you any real answers,..but I'm hoping
that is may clarify the situation.

Make sure you set up a rule in each sonicwall so that all WLAN -> LAN
traffic is allowed. Presuming of course that's what you want, and you aren't
using VPN.

Notes:
Nobody connects using WINS, either - that's NetBIOS name resolution, not a
means of connectivity.
If you're using AD, and the remote office is part of the same domain, you
ought to have a DC out there (in its own AD site/subnet) or your
authentication will all be taking place across the VPN connection, which is
not good.
I also discourage locally-attached/shared printers on workstations; it's
much better to stick with entirely networkable printers.

In the SonicWall, did you enable the "NetBIOS (or MS networking) broadcasts
from WLAN to LAN" setting ?

Nah, you did not understand the question.

The problem is with the communication between wired & wireless clients on
the *same* "side" of the VPN.

Since there is no WINS server on this side you need to enable the "NetBIOS
broadcast pass through" between 192.168.x.x (wired) and 172.x.x.x
(wireless). There is a special settings for this in the Firewall | Advanced
section of the SonicWall.

Hi - SonicWALLs have some kind of broacast helper between the discrete
wired/wireless networks- it ain't WINS.

Hmm. I may have misunderstood. Yes, if that's the case, then there's nothing
to do in the Sonicwall at all.

Yes, but it's easy to open up LAN-WLAN segment interclient communication
..... as long as it's TCP & not UDP

If all the workstations have specified the correct WINS server IP, it should
all be working as is.....although I personally don't bother using WINS in a
workgroup environment. I'd have the other office as part of the domain, with
a local DC/GC/DNS/DHCP/WINS box.

Did you hear something?

I think they're correct - this is an issue with your config somewhere.

You should be doing the same for the other SonicWALL - have *everyone* point
to the WINS server in the main office. Frankly, I'd have everyone point at
an AD-integrated DNS server as well.

"See" means browse, I presume? I imagine you can ping - and can access via
UNC.

You'd have a much better time of this if you used AD in the other office as
well - stick a cheap & cheerful box in there as a DC/GC/DNS/WINS server in
the existing domain.

These would be different subnets on opposite sides of the WAN link, so it
would not be broadcasting in this case. Multiple subnets forces WINS to be
used and when WINS is used there are no broadcasting,..it is "directed"
instead,...pretty much the similar scenario as with DNS lookups,...it is
just a WINS Server being queried instead of a DNS Server.

Ok. Fair enough. I'm not personally familiar with SonicWalls specifically.
It just doesn't seem logical to have to enable something related to Netbios
Broadcasting when WINS is not Netbios Broadcasting because the WINS Server
is not accessed by broadcasts.

Ok,... but what I understand the OP needs is WINS to work between all 4
segments with all machines accessing a single WINS Server that lives on of
the segments,...so would this setting not be relevant to that? It doesn't
sound like it would be since there are no broadcasts involved and whatever
this thing is, it isn't WINS.

Do these boxes have ACLs between the Segments the way ISA does?,...maybe it
is just blocking the WINS Queries in a more "normal" fashion and it hasn't
been noticed. If these were two ISA Boxes doing a S2S VPN with two Internal
Segments at each site,...then Access Rules are the first thing you have to
create to allow traffic between the 4 segments,...and that would be
regaurdless of Wired -vs- Wireless or VPN -vs- not VPN.

Me too.

Well, I haven't heard from the OP since the original post, so I don't even
know if my assumptions about everything are even correct. The example in my
first post is just a bunch of assumptions based on what I think she was
describing,...so I guess we will have to just see where it goes.

I have been reading all the posts to my original post, and will be
addressing the problem again this week. The techs at SonicWall I have
talked to said it is a Microsoft problem, and are not willing to help. I
have enabled the NETBIOS helper in the Sonicwall on both sides of hte VPN.
At the main office I had to add WINS to the IP protocol settings to get the
wireless laptops to work on the network there. I have been uable to get the
wireless laptop at the branch office (peer to peer network) to see the
network, even with the settings in the SonicWall

Did you have to do anything on the workstation at the remote site to make
things work?

I have the same network than you have (main site with AD, remote site
without server linked with SonicWall Lan-2-Lan VPN) and it works fine, so
there is definitively a way to make it work for you.

This said, I agree with the other poster. Installing a server for AD, DHCP,
WINS, etc. at the remote site is the best.

I called Sonicwall and was able to get help. Changes had to be made in the
Sonicwall. Laptops can now connect to the network and print locally. Am
still working on printing from the terminal server session.

I have a similar network. One main office with server, AD, dns etc. and one sonicwall tz. A remote office with no server. Offices connected with VPN. Both offices have wireless access (Sonicwall).

The VPN link between the offices works correctly, routing all both ways - except traffic originating from the Sonicwall wireless connection. The wired computers connect properly beetween offices, the wireless laptops do not - although the laptops on wireless can access all resources within their local office - printers, shared files, internet, etc.

This suggests that I have the network and VPN configured almost correctly and the problem is not windows-related.

I need: laptops using Sonicwall wireless access should connect through the VPN in exactly the same way as the wired computers. IOW, in this company, wireless connections and wired connections should be treated the same for routing and firewall purposes.

Does anyone know what needs to be configured to make this work?