Wireless Access Point

The journey of a thousand miles begins with the first step.

Can you get to the AP using CAT5 and a PC?
What are the network settings on the PC and the AP when the firewall is out of the equation??

I took your advice and hooked the AP directly into another computer and I got the 3COM admin screen.  For some reason after this things started working and all of my old setting were still in the WAP.

The WAP is recognized and is getting an IP address and the media server works all over the house, which is good. 

Now the next question.  I currently have the WAP hooked into a switch on the internal interface.  I have read in other posts that for the highest security the WAP should be connected into another NIC card by itself like a DMZ.

I have other NICs already in ASL5 that are available.  Should I take the WAP off of the switch and configure another interface?  If I do it this way what changes to ASL do I need to make other that adding another interface card?  I am going to take a WAG at this but should I 1)  Add another interface for the NIC card 2) add a rule to the packet filter to allow connection for the interface card.

Also, how is the security higher for the WAP if it is connected to its own NIC as the only device as apposed to just being added to the network switch along with all of the other devices?

Thanks in advance

I have a few suggestions for you.

1. Use 192.168.20.1 for the ASL Internal network NIC, instead of 192.168.2.100. Since this NIC is the gateway for the network it serves, .1 is the appropriate address to use, not .100. Furthermore, using single digit numbers (0, 1, 2 or 3) in the third octet is not such a good idea, if you want to create VPNs to other 192.168 series private networks later on.

2. Use 192.168.30.1 for the ASL NIC serving the DMZ interface, not 192.168.3.100. The reasons are the same as those given in item #1.

3. Bind a secondary IP address, such as 192.168.20.5 to the Internal NIC discussed in item #1. Then set up a DNAT masquerade rule in ASL that maps your Wi-Fi access point's HTTP port across to this address. Create packet filter permissions to match. That way you will be able to access the webadmin interface of the access point, which is located on the DMZ network, by browsing to a local address on your Internal network. This approach will solve your current problem with remote administration of the Wi-Fi access point.

I have tried and have no problem changing the 192.168.3.100 interface to 192.168.30.1 but how do I change the 192.168.2.100 internal interface without hosing the system again?

Can I just edit the internal interface and change it to 192.168.20.1 or is something else required such as reinstalling from scratch and then putting 192.168.20.1 when the install program asks for IP?

Thanks,

Maybe I'm missing something?

Of course you can change it...

I have taken a shot at the binding, DNAT and packet filter.  I am pretty sure that I did something wrong as I still cannot get to the files on the server computer.  I am getting a valid IP address from the AP and a connection is made.  I am using a crossover cable on the DMZ NIC to the AP.

I think that about all that I may have gotten right is the IP binding if that.  Anyway, if you would please take a look and give me some direction on what is incorrect I would appreciate it.


Thanks

Either add a seperate NIC for the wireless access point, or get rid of that additional address on the Internal interface...

Giving it a network number that's different might also get it to work, but having such a configuration would be meaningless from a security standpoint. If you're going to seperate the networks, they have to be on separate NICs and wires...

Or is the Internal interface dedicated for WAP use?
If it is, just define the Class C network on the NIC and set the WAP as the NIC's gateway.

The additional interface trick would only be used if you were constrained to supporting two sets of network addresses on one interface; but that is not the case here. We can program the WAP as we see fit; and we're going to choose a simpler network topology that reflects what you are actually doing.

If other machines that don't go through the WAP are on the Internal network, there is no real firewalling going on between them in the configuration you lay out there.

And by using an overlapping network number on different virtual interfaces, the routing kernel does not know which one to use (that 255.255.255.255 for the WAP Virtual interface address also exists on the Internal virtual interface). Interfaces should have mutually exclusive network numbers on Astaro (and that goes for Virtuial Interfaces too...).

The Access Point is on its own dedicated NIC card with an address of 192.168.30.1 and is connected straight to the ASL box NIC card using a cross over cable.

The internal network is also on its own NIC card and is 192.168.20.1 and is connected to my internal lan.

The external interface is connected to the WAN.

The Access Point has two purposes.  The main one is to connect my SlimDevices media server via wireless so that the SlimDevices media server can access another computer on the 192.168.20.1 internal network to stream out my music.  The other purpose would be to allow access of my work laptop so that I can use it and the SlimDevice media server anywhere in the house.  

If I had added an internal PCMCIA wireless card that is on the ASL hardware list would I still have these problems?

I am getting more confused as what do do.

Relax!

Why is "WirelessAP" showing on eth0, the same physical interface as "Internal"?

Shouldn't "WirelessAP" be on its own interface, like eth3??

If you read the message about 5 up from VelvetFog this was to be a solution so that I could access the AP admin screen.  For some reason being on 192.168.20.1 I could not access the AP on the 192.168.30.1 network by starting IE and typing in the AP IP Address.

This was just an additional IP address to the internal NIC per the referenced message.  The AP is on its own NIC.

The access point is on its own NIC card.  If you look up about 5 messages this was a fix recommended by VelvetFog on how to access the AP Admin screen.  I was having problems since the internal LAN is 192.168.20.1 and the AP is on 192.168.30.1.

The AP is actuall hooked into the interface with a name of DMZ.

I don't know if that's what he meant you to do, but that configuration is not going to work.
Delete the additional interface on Internal.

Is the WAP hooked up to interface "DMZ"?
What is its current IP and netmask?

Get rid of the 3COMAP NAT rule for now.

I don't know if that's what he meant you to do, but that configuration is not going to work.
Delete the additional interface on Internal.

Is the WAP hooked up to interface "DMZ"?
What is its current IP and netmask?

Get rid of the 3COMAP NAT rule for now.

Ok, I have deleted the WirelessAP interface and deleted the packet filter and DNAT rule.  All that I have now is the DMZ interface where the AP is connected to.

The DMZ  interface is 192.168.30.1 with a netmask of 255.255.255.0

The actual AP has a static IP of 192.168.30.10 and a netmask of 255.255.255.0

And I presume:

• The Internal to Any rule is still in place
• The WAP uses HTTP and not HTTPS
• The AP's gateway is set to 192.168.30.1
• The Internal machine you are trying to access the AP from also has its gateway set to 192.168.20.1
• You understand that a "crossover cable" is not just any type of network cable, but is specially wired for NIC to NIC connections (as opposed to NIC to hub or switch...)
  

[/list]
If all ICMP options are enabled on Astaro, can you ping the AP from that PC on Internal whose gateway is set to Astaro?
Can you browse to the AP from that machine in Internal??

And to simplify matters, you have disabled the HTTP proxy for now...

The Internal to Any rule is still in place -YES
The WAP uses HTTP and not HTTPS - YES
The AP's gateway is set to 192.168.30.1 - YES
The Internal machine you are trying to access the AP from also has its gateway set to 192.168.20.1 - YES, all internal LAN computers have 192.168.20.1 set as the gateway

You understand that a "crossover cable" is not just any type of network cable, but is specially wired for NIC to NIC connections (as opposed to NIC to hub or switch...) - YES

If all ICMP options are enabled on Astaro, can you ping the AP from that PC on Internal whose gateway is set to Astaro?

When all ICMP options are enabled I can ping 192.168.20.1 and 192.168.30.1 and get replies ok.  When I try to ping 192.168.30.10, the AP static address, I get the following no matter which machine on the LAN I try it from:

Request timed out, Reply from 192.168.20.1, Destination host unreachable.

HTTP proxy disabled - YES
 
Can you browse to the AP from that machine in Internal?? NO, not from any internal LAN machines

Now we're going to narrow it down to the Astaro config or your AP:

Take a PC and give it the same IP as your WAP; take the WAP temporarily offline and put the PC in its place with the crossover connection. Reboot Astaro and do the same ping test.

If you're up to it, repost screenshots of your current configuration.

That "unreachable" message is peculiar; that's a message being generated by a routing component. The AP? Your test will tell us that...

Temporarily delete the LAN-to-WAN masquerade rule too; that will not affect going from one private interface to another, so we simplify things to focus on getting LAN-to-LAN working first...

You didn't enter any routes on Astaro, did you??
(The routing tab)

I setup a Windows 98 machine and gave it a static IP of 192.168.30.10, the same as the AP, with a subnet of 255.255.255.0

I got the same results as before including the destination host unreachable.

Before I did the test I deleted the LAN-to-WAN masq rule and restarted ASL.

From within ASL, with the same ICMP settings all enabled, I could ping 192.168.20.1 and 192.168.30.1 but not 192.168.30.10.

I then went to the internal LAN music server computer and could ping 192.168.20.1 and 192.168.30.1 but not 192.168.30.10.

An no I have not set any routing rules.

The only other item that is set is the DNS Proxy which has been there all along.  It was set to listen to the internal network checked and I added in the two DNS IPs for my provider.

I will post another screen shot of the current settings.  The family needs to use the network tonight so after I post the screen shot that is all that I can do for tonight.  

Thanks for all the help.  I would think that with the AP being so popular that Astaro would have a "How to Guide" for just this problem as there are many more external AP's available then the ASL hardware compatability list PCMCIA cards for wireless.

Anyway I will keep trying to get the problem resolved.

Here is the first screen shot of my current configuration.

I'm not fully following this thread, but I'd like to point out that most wireless APs can be treated as a (wireless) hub.

So, configure the thing on a single network, and then it should work when you plug it in to the other NIC.

Have you tested the other ASL NIC's network with an ethernet connection?

Also, you shouldn't need NAT to get to the AP from another internal net, simple packetfilter rules are enough.

Barry

OK, some progress (I think!).
I will presume you plugged in that Windows box with the same cable that was connected to the AP.

IT DOESN"T WORK WITH THE WINDOWS MACHINE EITHER. That is what that test confirms, right?

Unless I misunderstood you, it's beginning to sound like your crossover cable. Do another ping of the Windows box from Astaro's console when you get this simplified test configuration all hooked up again (delete the masquerade rule; reboot the box to make sure it gets the proper MAC for the newly connected PC)

Do you have VPN connections going on?
(if a remote connection also needed to use that address, that could mess things up)
What version of Astaro is this? (including patch#).

The DNS proxy does not come into play because we are pinging by IP addresses and not names (right??!).

So it's not the AP, it's the Astaro config; why can't we ping the Windows box on a different NIC with a crossover cable??

I will take a look later; anybody else feel free to look at his last config he uploaded and spot the problem...