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



On Fri, Aug 14, 2009 at 3:55 PM, David
Gillett<gillettdavid@xxxxxxxx> 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
------------------------------------------------------------------------



Relevant Pages

  • FreeS/WAN - Routing all traffic (0.0.0.0) through a client tunnel
    ... the client to forward ALL traffic through the tunnel? ... I have experience with this type of configuration using a Nortel ... but have never tried it with freeswan. ... anything that comes in through the tunnel is dumped out ...
    (comp.os.linux.security)
  • Re: What Benefits does Exchange have over POP?
    ... If you don't like the Outlook interface, ... would see nothing in a web mail client (a couple of my clients on POP ... all of your ISP clients did that, they would have even more problems. ... We only have 15 users and they don't poll in real ...
    (microsoft.public.windows.server.sbs)
  • Re: problem with connect computer wizard - permission issue
    ... The ISP provided a cisco IAD2400, ... --> SBS machine ... --> client 1 ... and these devices hold the public IP, not the server. ...
    (microsoft.public.windows.server.sbs)
  • Re: Unable to send attachments still
    ... I am going through an ISP called TPG. ... MS MVP - Outlook Express ... an e-mail client. ...
    (microsoft.public.windows.inetexplorer.ie6_outlookexpress)
  • Re: Unable to send attachments still
    ... I meant to ask who you use for an e-mail server / ISP, not client. ... And are you able to post the error message completely? ...
    (microsoft.public.windows.inetexplorer.ie6_outlookexpress)