[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: I-D ACTION:draft-ietf-ipsec-udp-encaps-00.txt
> Also I would think that the 5 minute default is too long. If VPN
> wasn't involved the "server" wouldn't normally be able to connect
> back to the "client" after 5 minutes so I'm not sure why this
> capability should be provided for VPN. One or two keepalive
> packets after the last SA has been deleted should be more than
> sufficient as the default.
5 minutes seems like a reasonable default to me; it's comparable in
length to the (as specified) TCP TIME_WAIT interval.
I think you want to attempt to keep things alive across a brief loss
in connectivity (between the NAT and the outside-the-nat peer); 30
second outages while BGP does its thing are not uncommon..
> There is probably a better solution to this than sending a packet
> every 20 seconds for TCP connections that are idle for a very long
> time.
Yes there is: get rid of the NAT :-)
For what it's worth, it seems like the impact on the network of the
NAT-keepalives could be reduced by sending them with a reduced IP TTL
(so that they die just beyond the last NAT being traversed).
Unfortunately there doesn't seem to be an easy way to figure out what
that TTL should be..
- Bill
Follow-Ups:
References: