Ethical Hacking

Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package.
Computer Forensics Training at InfoSec Institute

Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors.




Network Security Focus-Microsoft
[Top] [All Lists]

Re: Front End/Back End communication

Subject: Re: Front End/Back End communication
Date: Mon, 15 May 2006 15:42:12 -0700 (PDT)
I'm **not** an expert on this, so more qualified
people may want to correct what I say below. The
general concepts should be okay and will hopefully
help Tim out.

Tim,

1. IPSec has two modes--tunnel and transport. Tunnel
mode might work for you.

Per
http://www.microsoft.com/technet/security/topics/networksecurity/ipsecarc.mspx#EYF:

"The tunnel mode is used in cases when security is
provided by a device that did not originate packets -
as in the case of VPNs - or when the packet needs to
be secured to a destination that is different from the
actual destination."

As I understand it, IPSec has two parts--AH (header
related) and ESP (data payload related).
Theoretically, if IPSec can be set to only encrypt the
payload of each data packet and not encrypt a packet's
headers, it should work with NAT. I'm not sure how
much this would decrease IPSec's security.

After a quick look, I found a note on the Internet
that implies that something like this may work. Per
http://marc2.theaimsgroup.com/?l=vpn&m=102796863626037&w=2:

"I understand that using AH in tunnel mode is
imcompatible with NAT as NAT rewrites the IP header
and thus breaks the AH header. Is this the only IPSec
mode that is incompatible with NAT? e.g., AH +
Transport, ESP + Tunnel or Transport work with NAT,
correct?"

In response
(http://marc2.theaimsgroup.com/?l=vpn&m=102796980027381&w=2),
someone says:

"AH in any mode is incompatible with NAT or PAT
(NAPT).
ESP in transport mode is incompatible with NAT of PAT
(NAPT), if you are using UDP or TCP, since the TCP or
UDP checksum will break.  In other words, it's
incompatible for anything useful.
ESP in tunnel mode itself is not completely compatible
with NAT or PAT (NAPT), depends on how smart your PAT
(NAPT) box is (most are stupid)."

or

2. Another encryption method may suffice...maybe a
type of S/Mime implementation?

or

3. Can you offload the IPSec encryption/decryption to
hardware (such as an "IPSec hardware accelerator") or
a server in front of the NAT device? If so, you may be
able to do something like this:

IPSec traffic <-IPSec-> IPSec decryption device
(immediately in front of the NAT router) <-TCP/IP->
NAT router <-TCP/IP-> Exchange server

Good luck.

Scott

--- timpacalypse@yahoo.com wrote:

I'm curious about how people are implementing FE/BE
Exchange communication.
[...]

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

---------------------------------------------------------------------------
---------------------------------------------------------------------------

<Prev in Thread] Current Thread [Next in Thread>