[ale] HELP, need to setup wireless access point!

[Ron Frazier]

Michael T.,

Trying to catch up on some replies.  Keep in mind that I'm coming from 
the networking perspective of the home office user, with a simple 
network with a couple of routers and a cable modem.  My comments, from 
that perspective, may not apply to enterprise networks, which is your 
specialty.  Thanks for explaining all the NAT stuff.  See comments in 
line.  I've snipped out the parts I'm replying to.

On 02/05/2011 12:54 AM, Michael B. Trausch wrote:

> jump through ten thousand hoops just to get it done. That reminds me, I
> need to write a utility (that I would not have to write if NAT didn't
> exist) so that I can actually support my family's computers.  They're
> out of state, and there are a fair number of computers, and I am
> _absolutely_ not paying for services like LogMeIn.  Not to mention, I
> don't _trust_ such places.
>
>    

Their router probably has NAT, router, and firewall functionality.  I 
don't think NAT, per se, is the issue.  If you port forward through 
their firewall (a security risk), and address packets to their public IP 
of (for example) 76.22.150.5, and those packets get translated to go to 
192.168.1.23, as long as they get to their PC, it shouldn't be a 
problem.  So, I think the question is, how to get through the family 
member's firewall and maintain their security without using a 3rd party 
service.  (I'm sure there are SOME trustworthy 3rd party services.  
GoToAssist, by Citrix, has a good reputation.)    If it's worth the 
money, you could use a remote IP based KVM.  I think you can get them 
for around $ 300 these days.  That gives you total access to the 
machine, even at the BIOS level.  It would be nice if you could attach 
the KVM directly to the cable or dsl modem.  Then, you'd have direct 
access to it.  Once it properly authenticates you, you'd have direct 
access to the machine without having to penetrate the firewall.  Of 
course, having that KVM exposed like that might be a security risk.  The 
problem is, I think the cable modem is only going to provide one IP 
address on it's inside ethernet port.  So, if the KVM sucks that up, 
there is no address for the router to take.  There may be some sort of 
way to have the KVM pass through IP traffic not destined for it.  I 
don't know about that.  Otherwise, you'd have to put the KVM inside the 
firewall.  I'd be inclined to look into newer routers with port knocking 
capability, which only open incoming ports in the firewall when hit with 
a special coded sequence of incoming port numbers.  Once that happens, 
incoming traffic on the designated port numbers is forwarded to the 
internal PC.  This could be done without a KVM.  I don't really see why 
you'd need a custom written utility.

This link to a Going Linux podcast has information about Remote 
Assistance software for Linux:

http://www.goinglinux.com/2010shownotes.html#glp118

You might also try one of these VPN routers from Netgear.  This will let 
you establish your own VPN from the internet directly into your family 
member's network.  I own one of the wired models, but have never taken 
the time to figure out how to do this.  Theoretically, I could be at a 
hotspot, establish a VPN to my house, and access anything on my network 
just as though I was in the house.  I think that would be really cool.

http://www.netgear.com/service-provider/products/security/wired-VPN-firewalls/default.aspx
http://www.netgear.com/service-provider/products/security/wireless-VPN-firewalls/default.aspx

I have an interest in remote access for my own family members (running 
Windows).  So, I'd be interested to learn about anyone's experiences 
with this type of thing.

>   * Certain software programs that don't use intermediary third party
>     services rely on the ability to somehow control the NAT (mostly a
>     thing for consumer/home type stuff), such as via uPnP.  Not a bad
>     idea, except that it'll only work on the innermost NAT in a
>     multiple-NAT setup.
>
>    

UPNP can be a substantial security risk if something bad gets in your 
machine through another vector.  Then, it can open up holes in your 
firewall without you knowing it and invite all it's friends in.

> * If a system on the outer NAT needs to talk to a system on the
>     inner NAT, you first have to have the system on the inner side
>     communicate with the one on the outer side, just like the
>     Internet.  This makes pull backups impossible unless you do it
>     at the deepest NAT level or use an inverted connection.
>
>    

For most home users, I would recommend only one router, then the cable 
modem.  Everything, such as a NAS or printer plugged into the router 
switch ports would be accessible to everyone on the internal net.  The 
NAT only comes into play when exiting to the internet.  However, even if 
there's a reason to have multiple routers, such as I do, if you hang the 
printer or NAS on the router closest to the internet, you should still 
be able to access it.  I don't think pull backups are a requirement in a 
home office.

> Half the overhead of a NAT is precisely about stateful firewalling,
> which, by the way, is not necessary on each and every one of the 65,535
> available ports unless you have a NAT.  And it gets worse: the more
>    
I'm not following you there.  If we have only one external IP address, 
why would we not need firewall functionality on all the incoming ports, 
whether or not we're NATting?

> we already knew that.  The Internet is a bloody hostile place.  That's
> why we have IPsec, to prevent those things from happening.  Two
> cooperating networks using IPsec will be able to securely talk to each
> other (so long as there is no NAT in the middle).  That's also why we
>    

I don't think most home users are running IPsec.

> Furthermore, stateful firewalls can only be stateful about protocols
> that they know about.  There are protocols other than TCP, UDP, and SCTP
> that run directly on top of IP.  AH, which is a security mechanism, runs
> directly on top of IP, and itself encapsulates an IP payload (which
> might itself carry a part of a TCP stream, or a UDP datagram, or
> something else altogether.  If your stateful firewall doesn't know about
> that, it cannot do anything at all and just has to give up.
>
> This is one reason why most consumer grade NAT appliances are so broken.
> They are unable to deal with protocols that they weren't designed for,
> such as protocol 41 (IPv6 encapsulation and tunneling).  That's because
> they know nothing about the protocol itself, not its semantics or
> requirements, whether it is something like TCP or UDP with a concept of
> port numbers, or whatever.
>
>    

I don't want my firewall passing any traffic that is anything other than 
TCP or UDP or those functions necessary for NAT traversal without 
creating security risks, unless I've upgraded the firmware to support it 
(assuming it's available) and I've explicitly turned it on.

> "Unwanted traffic" is defined differently for every single useful
> network in existence.  The thing is that most people don't notice
> because of the great lengths that application software will sometimes go
>    

Here's my definition of unwanted traffic.  I want my firewall to:
    Allow NO general traffic in from the outside world that I didn't 
explicitly request via my applications, as much as technologically possible.
    Allow NO open ports to be exposed to the general public, all should 
be stealthed.
    Allow NO services to be exposed to the general public.
    Make NO response to unsolicited queries from the outside world, not 
even ping.
    Allow ONLY prearranged, highly authenticated, encrypted, incoming 
transmissions from SPECIFIC users for things like remote access.

> For that matter, consider a common case for people like myself.  I don't
> mind helping others.  And for most problems, I need not be physically
> present to help, just to have access to their screen.  But even if the
> person on the other end is running Ubuntu, I have to have them jump
> through hoops just to get it so that I can make the initial connection
> to the VNC server running on their system.  If NAT were not an issue,
> then I would not have this problem at all.
>
>    
If NAT were not an issue, or more specifically, if their firewall were 
not an issue, they'd have no perimeter defense against crackers.  That 
would be a bad ides.  See prior comments on remote access.

> A simple daisy chain is fine.
>
> Just don't introduce NAT every step of the way.  There's no point.
> There is less than no point: it can and will break things in subtle ways
> that will take time to figure out.
>
>    

If I, as an average consumer, using IPv4, wish to have several internet 
devices connected to my one cable modem, and have several internal 
addresses in use, I don't see any way to avoid some NAT as the cable 
modem will only provide me with one address from it's ethernet port, as 
far as I know.

> network's edge.  Relying on the security of the network's edge to get
> you through the day is just asking for failure.  Lots of cases of data
> theft, database breakins, and the like happen from NAT'd nets.  When
> people rely on the network edge to keep them safe, they will get burned,
>    

This is absolutely true for the enterprise.  It is not so much true for 
the home user or the home office user with no employees.  In this case, 
a perimeter defense is one of the most important things the user can 
do.  Almost all the danger is outside the walls of the building.  
Software firewalls on the PC's, possibly anti virus software, some 
passwords, and family user training about safe computing, are all 
important, just in case something gets loose on the internal network.  
The router itself should be secured too.

> Proper, real, effective security comes only from know-how and proper
> setup.  If you have a network and you don't know how to keep it secure,
> that's why we have people who get paid for that sort of thing.  If you
>    

Most home users cannot afford to pay.  That's why they call us!  8-)

> But really, if you want to learn how this stuff works, I'd suggest
> diving into the Linux kernel, or the FreeBSD kernel, or any operating
> system kernel that has a full IP stack.  There is lots of
> information---and subtle details---to be found there!
>
> 	--- Mike
>    
>

 From an intellectual point of view, I'd love to dissect the Linux 
kernel.  However, as a practical matter, I doubt I'll ever have the time 
unless someone pays me to do it.

Sincerely,

Ron

-- 

(PS - If you email me and don't get a quick response, you might want to
call on the phone.  I get about 300 emails per day from alternate energy
mailing lists and such.  I don't always see new messages very quickly.)

Ron Frazier

770-205-9422 (O)   Leave a message.
linuxdude AT c3energy.com