I am pretty sure "debug crypto isakmp" just confirmed my thought, but I welcome any other discussion!
On Wed, Mar 7, 2012 at 1:15 AM, Joe Astorino <[email protected]> wrote: > As we know, ISAKMP SA's are bi-directional and run over UDP port 500 > by default, but IPSEC SA's are unidirectional -- We must have one in > each direction. Say we have a topology like this where R1 wants to > make an IPSEC tunnel to R2 through an ASA > > R1 --- ASA --- R2 > > R1 is on the "inside" where R2 is on the "outside". If we use regular > old ESP, the connection from R1 --> R2 is permitted because it is high > --> low but the ESP from R2 back to R1 is dropped because by default > the ESP is not inspected and the return traffic will not be part of > any existing connection. We can fix this with "inspect > ipsec-pass-thru" in the MPF, or we can do something like NAT-T, IPSEC > over TCP or IPSEC over UDP. > > My question is in regards to these tunneling implementations, > specifically on how the unidirectional IPSEC SA is setup from the > responder back to the initiator. If the responder initiates a NEW > connection for a unidirectional SA back to the intiator, I would think > it would be dropped by the ASA. I would think the unidirectional SA > from responder to initiator would have to be some sort of stateful > reply to something sent by the intiator so it is allowed through the > ASA as a return connection....but that doesn't seem like it is a vey > "unidirectional" > > For example, let's say we use cTCP encapsulation, so we have ESP > encapsulated in TCP port 10000. So, after phase 1 is complete R1 sets > up an IPSEC unidirectional SA to R2 over TCP 10000. The source will > be > 1024 but let's call it 6666 for sake of example. At this point > the ASA would have a connection for R1:6666 --> R2:10000 and it would > expect traffic back from R2:10000 --> R1:6666. At this point, is the > unidirectional SA from R2 back to R1 truly sourced from 10000 and > destined back to R1:6666 or is it a NEW connection initiated by R2 on > the outside because it is a "unidirectional" SA? If that was the > case, I don't see how that would work. > > I think the first thing I said would be correct, because that is the > only way the ASA would allow it back in without an exception, but I'm > not sure because it is always described as a unidirectional SA in each > direction. > > Can anybody clarify this? Thank You! > > -- > Regards, > > Joe Astorino > CCIE #24347 > http://astorinonetworks.com > > "He not busy being born is busy dying" - Dylan -- Regards, Joe Astorino CCIE #24347 http://astorinonetworks.com "He not busy being born is busy dying" - Dylan _______________________________________________ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com Are you a CCNP or CCIE and looking for a job? Check out www.PlatinumPlacement.com
