Secure a wired network from wireless clients

I have a wired network, Network A, using 10.x.y.z range, with a gateway to
the Internet.

Also have a totally separate wireless network, Network B, using 172.16.a.b
range.

On Network A, I intend to set up another gateway PC (running ISA Server).
The PC will have 2 network interfaces, one to the wired network, and the
other a PCI wifi card. The Local Address Table on the ISA Server will be
10.x.y.z only.

The PCI wifi card will have a static 172.16.a.b address.
In other words the wifi card interface is considered external
and therefore ISA's firewall service will protect the wired network.

I intend to allow inbound VPN connections on the external interface
using a single account with a strong password.

If possible I also want to:

Restrict potential VPN clients by limiting wireless clients with certain MAC
addresses.
Restrict potential VPN clients by limiting wireless clients to certain
172.16.a.b ranges.

Is the above scenario the right way to secure a wired network?
Any pitfalls I should be aware of?
Using ISA, is it possible to reject clients based on MAC addresses and/or IP
ranges?

When a VPN client authenticates against a VPN server (as in the above
scenario) doesnt the password go thru the air and therefore be susceptiable
to
snooping? (The VPN tunnel has not been set up at this stage).

Can anyone suggest a even more secure way of doing things?

I have yet to learn about IPSec and Certificate services. Anyone got simple
walkthru scenarios on IPSec and Certfificate services?

>> I have a wired network, Network A, using 10.x.y.z range, with a gateway
to
the Internet.

Also have a totally separate wireless network, Network B, using 172.16.a.b
range.

On Network A, I intend to set up another gateway PC (running ISA Server).
The PC will have 2 network interfaces, one to the wired network, and the
other a PCI wifi card. The Local Address Table on the ISA Server will be
10.x.y.z only.

The PCI wifi card will have a static 172.16.a.b address.
In other words the wifi card interface is considered external
and therefore ISA's firewall service will protect the wired network.

I intend to allow inbound VPN connections on the external interface
using a single account with a strong password.

If possible I also want to:

Restrict potential VPN clients by limiting wireless clients with certain MAC
addresses.
Restrict potential VPN clients by limiting wireless clients to certain
172.16.a.b ranges.

Is the above scenario the right way to secure a wired network?
Any pitfalls I should be aware of?
Using ISA, is it possible to reject clients based on MAC addresses and/or IP
ranges?

When a VPN client authenticates against a VPN server (as in the above
scenario) doesn't the password go thru the air and therefore be susceptible
to snooping? (The VPN tunnel has not been set up at this stage).

Can anyone suggest a even more secure way of doing things?

I have yet to learn about IPSec and Certificate services. Anyone got simple
walkthru scenarios on IPSec and Certificate services?


Sphere:

What I use: (using PPTP and R&RA, not IPSec or ISA):
WiFi clients/subnet <> AP <> Win2k3 Server R&RA <> wired subnet

Control points:
Use AP to control:
WiFi clients by MAC address
(you could use this with static addresses to achieve "Restrict potential VPN
clients by limiting wireless clients to certain
172.16.a.b ranges")
WEP settings

Use R&RA as VPN server end point to control:
Access by date and time of day
User authentication

>> When a VPN client authenticates against a VPN server (as in the above
scenario) doesn't the password go thru the air and therefore be susceptible
to snooping? (The VPN tunnel has not been set up at this stage).

No, not per packet sniffing that I have done on a PPTP VPN test setup.
The PPTP control connection to port 1723 on the server is in readable.
The GRE data packets are readable thru the IPCP setup, then VPN compression
and encryption is used, and the rest of the VPN session is not readable
(which includes VPN client passwords).

>> I have a wired network, Network A, using 10.x.y.z range, with a gateway
to
the Internet.

Also have a totally separate wireless network, Network B, using 172.16.a.b
range.

On Network A, I intend to set up another gateway PC (running ISA Server).
The PC will have 2 network interfaces, one to the wired network, and the
other a PCI wifi card. The Local Address Table on the ISA Server will be
10.x.y.z only.

The PCI wifi card will have a static 172.16.a.b address.
In other words the wifi card interface is considered external
and therefore ISA's firewall service will protect the wired network.

I intend to allow inbound VPN connections on the external interface
using a single account with a strong password.

If possible I also want to:

Restrict potential VPN clients by limiting wireless clients with certain MAC
addresses.
Restrict potential VPN clients by limiting wireless clients to certain
172.16.a.b ranges.

Is the above scenario the right way to secure a wired network?
Any pitfalls I should be aware of?
Using ISA, is it possible to reject clients based on MAC addresses and/or IP
ranges?

When a VPN client authenticates against a VPN server (as in the above
scenario) doesn't the password go thru the air and therefore be susceptible
to snooping? (The VPN tunnel has not been set up at this stage).

Can anyone suggest a even more secure way of doing things?

I have yet to learn about IPSec and Certificate services. Anyone got simple
walkthru scenarios on IPSec and Certificate services?


Sphere:

What I use: (using PPTP and R&RA, not IPSec or ISA):
WiFi clients/subnet <> AP <> Win2k3 Server R&RA <> wired subnet

Control points:
Use AP to control:
WiFi clients by MAC address
(you could use this with static addresses to achieve "Restrict potential VPN
clients by limiting wireless clients to certain
172.16.a.b ranges")
WEP settings

Use R&RA as VPN server end point to control:
Access by date and time of day
User authentication

>> When a VPN client authenticates against a VPN server (as in the above
scenario) doesn't the password go thru the air and therefore be susceptible
to snooping? (The VPN tunnel has not been set up at this stage).

No, not per packet sniffing that I have done on a PPTP VPN test setup.
The PPTP control connection to port 1723 on the server is in readable.
The GRE data packets are readable thru the IPCP setup, then VPN compression
and encryption is used, and the rest of the VPN session is not readable
(which includes VPN client passwords).

>> I have a wired network, Network A, using 10.x.y.z range, with a gateway
to the Internet.

Also have a totally separate wireless network, Network B, using 172.16.a.b
range.

On Network A, I intend to set up another gateway PC (running ISA Server).
The PC will have 2 network interfaces, one to the wired network, and the
other a PCI wifi card. The Local Address Table on the ISA Server will be
10.x.y.z only.

The PCI wifi card will have a static 172.16.a.b address.
In other words the wifi card interface is considered external
and therefore ISA's firewall service will protect the wired network.

I intend to allow inbound VPN connections on the external interface
using a single account with a strong password.

If possible I also want to:

Restrict potential VPN clients by limiting wireless clients with certain MAC
addresses.
Restrict potential VPN clients by limiting wireless clients to certain
172.16.a.b ranges.

Is the above scenario the right way to secure a wired network?
Any pitfalls I should be aware of?
Using ISA, is it possible to reject clients based on MAC addresses and/or IP
ranges?

When a VPN client authenticates against a VPN server (as in the above
scenario) doesn't the password go thru the air and therefore be susceptible
to snooping? (The VPN tunnel has not been set up at this stage).

Can anyone suggest a even more secure way of doing things?

I have yet to learn about IPSec and Certificate services. Anyone got simple
walkthru scenarios on IPSec and Certificate services?


Sphere:

What I use: (using PPTP and R&RA, not IPSec or ISA):
WiFi clients/subnet <> AP <> Win2k3 Server R&RA <> wired subnet

Control points:
Use AP to control:
WiFi clients by MAC address
(you could use this with static addresses to achieve "Restrict potential VPN
clients by limiting wireless clients to certain
172.16.a.b ranges")
WEP settings

Use R&RA as VPN server end point to control:
Access by date and time of day
User authentication

>> When a VPN client authenticates against a VPN server (as in the above
scenario) doesn't the password go thru the air and therefore be susceptible
to snooping? (The VPN tunnel has not been set up at this stage).

No, not per packet sniffing that I have done on a PPTP VPN test setup.
The PPTP control connection to port 1723 on the server is in readable.
The GRE data packets are readable thru the IPCP setup, then VPN compression
and encryption is used, and the rest of the VPN session is not readable
(which includes VPN client passwords).