[ previous ] [ next ] [ threads ]
 
 From:  SDamron <sdamron at gmail dot com>
 To:  "Don Munyak" <don dot munyak at gmail dot com>
 Cc:  m0n0wall at lists dot m0n0 dot ch
 Subject:  Re: [m0n0wall] IPSEC router-to-router (or) IPSEC client-to-router
 Date:  Mon, 12 Jun 2006 14:53:00 -0500
If you are doing drive mapping remotely, you will need to open a few
more ports on both ends.  What OS are you using on the remote servers?
 Usually, the encrypt, decrypt function does use a little more
processor, but not enough to make a difference on a good modern box.

If running a good modern OS (Linux/UNIX) you should REALLY be fine.

My 2 cents

On 6/12/06, Don Munyak <don dot munyak at gmail dot com> wrote:
> IPSEC router-to-router (or) IPSEC client-to-router
>
> I am in the final stages setting up a co-lo solution and have reach a
> point of confusion and need some opinions. Being almost finished, I
> don't want to reinvent the wheel, however if I can keep the solution
> simpler, I would benefit from any additional time spent. Our current
> solution is a follows:
>
> We have fours servers which will be in the co-lo. Each server is
> currently provisioned and setup for an SSH-server service using
> BitVise (http://www.bitvise.com/). My plan upto this point was to
> allow only ports 80, 443 and 22 'IN' through m0n0wall. Port 80/443
> will be for public access. Port 22 would be further restricted with
> the source being our main office only. Anytime I need to access any of
> these servers, I would first create an ssh tunnel from my workstation
> using the BitVise client, and then use RDP/VNC through the tunnel as
> well as any commandline needs.
>
> We have a few other people in the office that need to access three of
> these servers all day long. So in essence, there will be almost an 8
> hour persistent tunnel to/from the co-lo network. An unfortunate
> side-effect will be the additional cpu's for en-crypting/de-crypting
> the tunnel traffic on the server.
>
> I have setup router-to-router IPSEC with m0n0wall with success, but in
> trying to be security conscientious, I was leaning away from using a
> full time connected tunnel for this application. I beleive that with a
> full time tunnel, if one of the co-lo servers is compromised, the
> attacker conceiveably could have access to our main office (and
> vice-versa) ...???
>
> Then there's the possibilty of using an IPSEC client like GreenBow. In
> this scenario, the client pc on the main office network would
> initiated an IPSEC seesion with the m0n0wall firewall at the co-lo
> end. Having not really researched this yet, I am assuming that the
> IPSEC connection is not only initiated but also torn-down by the
> client...hence temporary.
>
> So now I'm at an impass.
>
> The IPSEC solution would
> * be cheaper (not having to buy Bitvise SSHserver)
> * remove cpu cycles from the servers. (the firewall has been upsized
> to a 1Ghz processor)
> * simpler to setup and administer.
>
> The downside would be the single point of failure (compromise).
>
> My needs are simple. I have a client workstation that needs to access
> the server,s securely. I also need the ability to map a drive on the
> client pc to a resource on the server. Both networks will have
> m0n0wall firewall/routers as gateways.
>
> I'll take any suggestions or comments. I am kinda in a knowledge
> vaccum and have learned much of what I know from research.
>
> Thanks
>
> Don
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: m0n0wall dash unsubscribe at lists dot m0n0 dot ch
> For additional commands, e-mail: m0n0wall dash help at lists dot m0n0 dot ch
>
>


-- 
-------------------------------
When all you have is a hammer, everything starts to look like a nail.
Registered Linux User #409723