[Openswan Users] Problems with ipsec via UMTS

[Pawel Gasieniec]

Thanks for reply
Unfortunately I cannot cancel my subscription, it is the only really working
mobile solution in my area.
Putting additional NAT would be probably difficult. I have been waiting for
Openswan machine for weeks. Buying another one is almost impossible. 
Putting more nat rules on my Openswan seems to be the best solution, if my
skills would allow this. When I find some time I'd try it and I'll make some
experiments with MTU on clients.
Main reason for building L2TP/ipsec was remote acces to our mail server. I
have walked around problem by using Outlook Web Access.
For now I have some other things to do, so UMTS must wait.
Thanks again

-----Original Message-----
From: Paul Wouters [mailto:paul at xelerance.com] 
Sent: Thursday, March 23, 2006 11:17 PM
To: Pawel Gasieniec
Cc: users at openswan.org
Subject: [SPAM] Re: [Openswan Users] Problems with ipsec via UMTS

On Thu, 23 Mar 2006, Pawel Gasieniec wrote:

> I have successfully configured openswan. It now works for Linux - Linux
> permanent links and for Windows Roadwarrior (with l2tp).
> The only problem is when Roadwarrior tries to connect via UMTS (Polish
> GSM/UMTS operator named ERA).
> I noticed that sometimes (most of the times to be precise) TCP, ICMP and
> ISAKMP packets come from one IP and UDP packets come from another. The
> result is "packet from 213.158.197.36:2658: phase 1 message is part of an
> unknown exchange" in log and, of course, no connection to Openswan.
>
> I have called them and asked for it, but the only thing they told me is
that
> they do not guarantee anything but working internet browser and mail
client.
> Their technicians are not responsible for nothing else.

The obvious thing to do is to cancel your subscription and ask for your
money
back.

The only thing I can possible imagine, is to put a NAT router in front of
openswan (or on openswan with lots of complex rules) and NAT the packets
back
yourself.

Perhaps lowing the mtu on your client machine might help, and you are just
seeing some artifact of Very Bad network design.

What I don't understand is why ISAKMP packets are from a different IP then
other UDP packets, since ISAKMP packets *are* UDP packets.

Paul
-- 
Building and integrating Virtual Private Networks with Openswan:
http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155