[Openswan Users] Port floating and DPD

[sertys at estates.bg]

Yeah, i do realise the difference between dpd and nat-t keepalives. I'm
still afraid to mess with the code, but the connections are matched
correctly. Phase1 cookies are included in the dpd r-u-there and packets
are correctly mapped to the SA nat pair. This gave me hope that there
might be some configuration option i might've missed. The gate(which is
now openswan, but my testbed is strongswan) is having packet xchanges like
this:
1.2.3.4:1000 > vpngate:isakmp
vpngate:isakmp:isakmp > 1.2.3.4:2000
vpngate:isakmp:isakmp > 1.2.3.4:2000
vpngate:isakmp:isakmp > 1.2.3.4:2000
vpngate:isakmp:isakmp > 1.2.3.4:2000
where 2000 is the port that is pointed in the newest ISAKMP. I want to
make this behaviour dynamic. How about if i try ikev2 and mobike?

> On Thu, 27 May 2010, sertys at estates.bg wrote:
>
>> I have been setting mobile VPNs for quite some time now. Mappings go
>> through the 3g operator's gateway natted. There're moments at which the
>> udp-mappings get deleted. It's an operator issue, but they seem to be
>> unable to fix it. I'm setting the dpd heartbeat at 120 seconds, which is
>
> dpd heartbeats are not the same as NAT-T keepalives. You should not need
> DPD
> for keepalives.
>
>> enough for the mapping not to be closed under normal conditions. But in
>> force majeure the mapping changes. If the SA has been mapped to
>> gprs-gate.operator.com:1234, i now receive packets from
>> gprs-gate.operator.com:5678. Is there a way to configure strongswan to
>> recognize these DPDs and re-map the SA or re-negotiate it. The devices
>> keep sending notify messages, but the answer goes to the old mapping.
>
> [I don't know anything about strongswan]
>
> If the port mapping is modified, and you start sending your traffic on a
> different
> port, there is no way openswan can know this is the same connection or a
> different
> client at this point. There might be tricks that can be played, but they
> should
> all work in the light of multipe roadwarriors behind the same nat, rekeys,
> etc.
> Trying out various crypto keys to match the changing ports might not be
> all that
> safe. From a protocol point of view, the IPsec SA should die and a new one
> should
> be started, perhaps assisted with DPD that will kill the old SA.
>
> That middleware machine is severely broken.
>
> Paul
>