RE: looking for a hub or switch that can connect a VPN and apply firewallrules to all ports

["David Gillett" <gillettdavid () fhda edu>]

> On Fri, Aug 14, 2009 at 3:55 PM, David 
> Gillett<gillettdavid () fhda edu> wrote:
> >  So your clients' Internet traffic doesn't go through the VPN?
> > (If it did, all the ISP would see is the encrypted tunnel...)
>
> Some does - some doesn't.  Connections to 192.168.*.* go 
> through the VPN but no other traffic goes through it as per 
> the routers configuration.

  Traffic to private addresses (such as 192.168.*.*) falls outside
what I was distinguishing as *Internet* traffic.

  This configuration is known as "split tunnelling", and is often 
avoided as a security risk.  The normal argument is that this can 
allow a compromise client to be exploited as a back door into your 
secure central network via the VPN connection.  Having clients prompt 
an effective DoS attack against your branch site is another kind of
security risk, as you've found....
  The normal alternative is for all branch office client traffic to be
sent to HQ, where the traffic that is bound for the Internet then goes
through the corporate filters/firewalls and ISP.  It does mean that
your tunnel traffic volume goes up since it now includes the Internet 
traffic of all of the site clients.
  The good news is that this may just mean tweaking your router config,
with no new equipment to purchase.  Of course, the HQ network is going 
to need to route Internet traffic back to the clients, but with luck
that's just a case of making sure the HQ<->Internet NAT config includes
the branch clients' address range.
 
> > 1) Police your own network so the ISP doesn't see things they 
> > shouldn't (*), or
>
> The ISP (this isn't a normal ISP, btw) complained about 
> traffic that was being sent to 212.117.185.19:80.  Beyond 
> that, I don't know why they complained about it.  Maybe 
> 212.117.185.19 is in a DNSBL and they believe any requests 
> sent to an IP address in a DNSBL is justification enough for 
> shutting the whole network down?  That would seem pretty dumb 
> (what if someone just mistyped the IP address?) but I don't 
> really know.  The ISP is not being particularly forthcoming 
> which is aggravating, but there's not a whole lot I can do about that.

  The reverse-DNS name on that IP address looks like the sort of names
many ISPs provide for their DHCP client ranges so they can send mail
past brain-dead filters that assume sources without rDNS entries must be
sending spam.  (This practice renders such filters worse than useless, 
of course.)
  *I* look askance when my clients establish server connections to hosts
that are DHCP clients, because useful/legitimate *public* servers normally 
are hosted at static addresses.  (Whether connections to private servers 
are reasonable may depend on the TOS/AUP that applies.)

> > 2) Purchase routable address space so each of your clients 
> has their 
> > own visible address.  I'm sure the ISP will be glad to handle the 
> > technical details in exchange for a reasonable monthly charge.
>
> That's not a problem.  The problem is, as stated, applying 
> the VPN settings and select firewall rules to all the computers.

  Well, the addresses would still all be in the same subnet, so setting
your existing firewall to work with these addresses should be trivial.
It's even possible that your current client and tunnel configurations 
can remain unchanged and that these addresses exist only as static NAT
entries for Internet-bound traffic.

  Your current VPN configuration is a single site-to-site tunnel.  
Configuring multiple tunnels between the same pair of sites can be tricky,
and it's not the tunnelled traffic that is causing problems for you.  Trying
to create a separate site-to-site tunnel for each client (a) may not be
practical, and (b) won't do ANYTHING to solve your problem.  What you NEED
is for your ISP, if you continue to use them for client Internet traffic,
to be able to associate "bad" traffic with a specific client and not cut off
the whole office.  Separate routable addresses for each client will do that.

David Gillett

------------------------------------------------------------------------
Securing Apache Web Server with thawte Digital Certificate
In this guide we examine the importance of Apache-SSL and who needs an SSL certificate.  We look at how SSL works, how 
it benefits your company and how your customers can tell if a site is secure. You will find out how to test, purchase, 
install and use a thawte Digital Certificate on your Apache web server. Throughout, best practices for set-up are 
highlighted to help you ensure efficient ongoing management of your encryption keys and digital certificates.

http://www.dinclinx.com/Redirect.aspx?36;4175;25;1371;0;5;946;e13b6be442f727d1
------------------------------------------------------------------------