Panwei (William) <[email protected]> wrote: >> I'm not sure I understand how you get this from the Problem >> Statement. >> Clearly, we need to clarify the purpose. >> It's not about detecting NAT, it's about determining if ESP will work or >> not. >> It's not about detecting or avoiding *NAT* per-se. >> We prefer not to have to encapsulate.
> Please forgive my ignorance of the scenarios. My understanding is that
> ESP failure is usually because of the existence of NAT.
> Do you mean ESP may not work even if there is no NAT between the two
IPsec peers?
> If yes, I'd like to know more about how ESP failed and in what kind of
> situations ESP will fail.
usually, a bad firewall.
One that allows UDP traffic (port 500/4500), but not proto=50.
For IPv4, there will often be NAT, so the proto=50 firewall doesn't matter,
as one has to UDP encap anyway.
>> I think that you are over-estimating the competency of some operators:
>> the experience with IPv6 is often not there.
>> Even when it is, not all equipment vendors are equally competent at
>> implementing/documenting things.
> Is this problem, i.e., IKE works but ESP doesn't work, only exist in
> the IPv6 network? Does IPv4 network have the same problem?
Yes.
It could exist in IPv4, and I've seen it, but NAT44 means you seldom notice.
> Second, will UDP encapsulated ESP get through in these circumstances?
Probably.
>> The purpose of this protocol is to allow that debugging.
>> The network operator people, who are not allowed into the billing
>> system, can instead use an ESPping utility to send ESP traffic, adjusting
>> their firewalls until they understand that UDP!=ESP.
> When you find out that the IKEv2 negotiation succeeds but ESP traffic
> can't get through, what more information will you get from sending the
> ESPping and not receiving a response?
That there is a problem with proto=50... So:
a) do UDP encap (maybe by manual config, if you are clueful)
b) call network support and file a problem report.
--
Michael Richardson <[email protected]>, Sandelman Software Works
-= IPv6 IoT consulting =- *I*LIKE*TRAINS*
signature.asc
Description: PGP signature
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
