4 Replies Latest reply on Jan 22, 2011 4:58 PM by bolero

    SG 565: no access to shares between LAN and WLAN

      I have a problem with LAN <-> WLAN connections (using the built-in WLAN) when it comes to file sharing: the machines can ping each other, but Windows file sharing doesn't work. The problem exists only for connections that traverse from or to WLAN or within WLAN. Within WLAN the machines can't even ping each other. LAN connections are all fine, no problems at all. The Snapgear works as a bridge and as a NAT router. I assume it is an issue with packet filtering, but it's not clear to me what I might need to configure. Also, I would have thought that I should not have to configure anything here. All machines are in the same subnet. Internet access is fine. Some time ago I had an SG 530 and a seperate WLAN access point. I'm not 100% sure but almost sure that back then the sharing worked. Thanks for any hints in the right direction.

        • 1. Re: SG 565: no access to shares between LAN and WLAN

          you need to enable 'Bridge Between Clients' under the wireless access point setup. this will allow wireless to wireless ocmmunications

          1 of 1 people found this helpful
          • 2. Re: SG 565: no access to shares between LAN and WLAN

            Hi Ross, thanks for the reply and sorry for taking a while to get back. I didn't have to revisit this problem for a while. I set as you specified after your post (it was off, indeed). The immediate effect was that the Snapgear became totally unresponsive within a few minutes. I was still able to get "thru", but not to use any of the services that the device provides (admin, dns, http proxy for instance). A reset cured that and it's not reappeared since then. I didn't check if the share connections were working as all laptops were offline then.

            Today I had time to revisit the problem and fired up two laptops, one with Windows XP, one with Windows 7. The situation has not changed, I still cannot get thru :-( But I can ping the machines and I can also VNC in to at least one of them. I didn't check the one I can't connect to via VNC, maybe there is something set incorrectly on that one, it's not been used for a long time. They are set to receive IP via DHCP from another machine on the network (not from the snapgear) and that works as well.

            So, the problem remains that I cannot open file shares via WLAN to or from these machines. Further checking on the machines themselves reveals that they can't do DNS, e.g. an nslookup shows that they can't get any data from a DNS server on the local LAN, including the snapgear. But if I tell nslookup to contact the snapgear's public IP address I can get dns data. The query log of the local dns server (same machine that handles DHCP) shows that there is no query making it thru. The nslookup command shows "query refused". It looks like the snapgear doesn't let the local dns traffic thru when it comes in via WLAN. I also can't get on the admin interface of the snapgear when I use the local LAN IP number. But I can access it when I use the public IP address. I can connect *from* a WLAN laptop to shares on a LAN machine if I try one that has a public IP address.

             

            A packet capture on the snapgear shows a Refused, but I don't believe that this is actually a refusal from the local DNS (232). It happens even with disabled firewall and there is no netry about a refused connect in the dns query log. Can you make more of the following?

            16:49:21.856629 IP 192.168.1.233.56427 > 192.168.1.232.53:  4+ A? samba.bolera.lan. (34)
            16:49:21.857033 IP publicsnapgearaddress.56427 > 192.168.1.232.53:  4+ A? samba.bolera.lan. (34)
            16:49:21.857652 IP 192.168.1.232.53 > publicsnapgearaddress.56427:  4 Refused- 0/0/0 (34)
            16:49:21.857905 IP 192.168.1.232.53 > 192.168.1.233.56427:  4 Refused- 0/0/0 (34)

             

            The capture of an attempt to open a share looks like this:

            17:18:49.390907 IP 192.168.1.229.4554 > 192.168.1.233.445: S 327651191:327651191(0) win 65535
            17:18:49.391380 IP publicsnapgearaddress.4554 > 192.168.1.233.445: S 327651191:327651191(0) win 65535
            17:18:52.317522 IP 192.168.1.229.4554 > 192.168.1.233.445: S 327651191:327651191(0) win 65535
            17:18:52.317921 IP publicsnapgearaddress.4554 > 192.168.1.233.445: S 327651191:327651191(0) win 65535
            17:18:58.353513 IP 192.168.1.229.4554 > 192.168.1.233.445: S 327651191:327651191(0) win 65535
            17:18:58.353911 publicsnapgearaddress.4554 > 192.168.1.233.445: S 327651191:327651191(0) win 65535

             

            This looks like the snapgear is forwarding the packet, but maybe on the wrong interface? e.g. shouldn't it forward the packet on the internal interface? I attempted a capture between two LAN machines about the same action for comparison, but there no packets are captured. Obviously the machine connects directly thru one of the switches and the packet doesn't touch the snapgear for this action. Makes sense.

             

            When I ping a WLAN laptop, it's somewhat different. The request is forwarded by the snapgear, but interestingly the reply appears as getting thru "directly", there is no forwarding visible.

            17:59:38.815348 IP 192.168.1.229 > 192.168.1.230: ICMP echo request, id 512, seq 17411, length 40
            17:59:38.815776 IP publicsnapgearaddress > 192.168.1.230: ICMP echo request, id 512, seq 17411, length 40
            17:59:38.816426 IP 192.168.1.230 > publicsnapgearaddress: ICMP echo reply, id 512, seq 17411, length 40
            17:59:38.816613 IP 192.168.1.230 > 192.168.1.229: ICMP echo reply, id 512, seq 17411, length 40
            17:59:38.816712 IP 192.168.1.230 > 192.168.1.229: ICMP echo reply, id 512, seq 17411, length 40
            17:59:39.816939 IP 192.168.1.229 > 192.168.1.230: ICMP echo request, id 512, seq 17667, length 40
            17:59:39.817367 IP publicsnapgearaddress > 192.168.1.230: ICMP echo request, id 512, seq 17667, length 40
            17:59:39.820181 IP 192.168.1.230 > publicsnapgearaddress: ICMP echo reply, id 512, seq 17667, length 40
            17:59:39.820376 IP 192.168.1.230 > 192.168.1.229: ICMP echo reply, id 512, seq 17667, length 40
            17:59:39.820489 IP 192.168.1.230 > 192.168.1.229: ICMP echo reply, id 512, seq 17667, length 40
            17:59:40.818143 IP 192.168.1.229 > 192.168.1.230: ICMP echo request, id 512, seq 17923, length 40
            17:59:40.818574 IP publicsnapgearaddress > 192.168.1.230: ICMP echo request, id 512, seq 17923, length 40
            17:59:40.819173 IP 192.168.1.230 > publicsnapgearaddress: ICMP echo reply, id 512, seq 17923, length 40
            17:59:40.819363 IP 192.168.1.230 > 192.168.1.229: ICMP echo reply, id 512, seq 17923, length 40
            17:59:40.819472 IP 192.168.1.230 > 192.168.1.229: ICMP echo reply, id 512, seq 17923, length 40
            17:59:41.820320 IP 192.168.1.229 > 192.168.1.230: ICMP echo request, id 512, seq 18179, length 40
            17:59:41.820760 IP publicsnapgearaddress > 192.168.1.230: ICMP echo request, id 512, seq 18179, length 40
            17:59:41.824077 IP 192.168.1.230 > publicsnapgearaddress: ICMP echo reply, id 512, seq 18179, length 40
            17:59:41.824285 IP 192.168.1.230 > 192.168.1.229: ICMP echo reply, id 512, seq 18179, length 40
            17:59:41.824397 IP 192.168.1.230 > 192.168.1.229: ICMP echo reply, id 512, seq 18179, length 40

             

            Can you make any sense of this, e.g. what I need to alter on the snapgear?

            • 3. Re: SG 565: no access to shares between LAN and WLAN

              sorry for the delay in the response....our office was flooded.

               

              check firewall -> packet filtering

               

              for automatically created rules that will block traffic like DNS.

               

              If you disbable these existing packet filter rules, I expect this will fix some of your issues.

              • 4. Re: SG 565: no access to shares between LAN and WLAN

                I've been able to fix this. The traces I posted in my last reply contained the cause. I tcpdumped directly on the dns and it was indeed refusing because the packets came from a non-allowed IP address. The snapgear was setting the source address to it's own public interface address, in other words it was doing NAT for wireless traffic to *any* destinations, even within the private subnet. I have a public subnet and a private subnet here. The Snapgear was originally set to transparently bridge the public subnet. Later I changed many of the machines to the private subnet, so only the machines where it is necessary face the net directly. I added a source NAT rule to provide internet access for them. The rule used Bridge 0 as the outgoing interface. This wasn't a problem before I added wireless because the inner-subnet packets weren't traveling thru the Snapgear. But the packets over wireless did and got all NATed. I changed the outgoing interface to "Any Internet interface"  and all is well now.