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. |

| 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> |
|---|---|---|
| ||
| Previous by Date: | Front End/Back End communication, timpacalypse |
|---|---|
| Next by Date: | RE: Front End/Back End communication, Devin Ganger |
| Previous by Thread: | Front End/Back End communication, timpacalypse |
| Next by Thread: | Re: Front End/Back End communication, Steve Friedl |
| Indexes: | [Date] [Thread] [Top] [All Lists] |