[Openswan Users] "cannot install eroute" occurs for Mac OSX users behind same NAT (v2.6.33)

Richard Schmidt huntingtonsurfca at gmail.com
Thu May 19 16:29:51 EDT 2011


Success!

The very slight difference between our configs was:

mine: rightprotoport=17/1701 
yours: rightprotoport=17/%any

I'd had this earlier and I guess when I tried upgrading OpenSwan from scratch I ditched my old ipsec.conf for the new one.

Just for my information, the reason why this blows up simultaneous NAT clients is because (based on my first email's log) both were trying to get in via port 1701. Encryption and using the same port means NAT is no help when deciding who to switch packets to? So eroute gives up.

And wait a second, why is the peer proposal message showing up when rightprotoport=17/%any and not when rightprotoport=17/1701? Port numbers don't affect proposed addresses...? Or is that pluto would have no way to distinguish it anyway so... like... whatever dude...

Richard Schmidt


On May 19, 2011, at 11:09 AM, Brian Mastenbrook wrote:

>> I'm using OpenSwan v.2.6.33 and xl2tpd v1.2.8 on Ubuntu 10.10 with 2.6.35-28-generic kernel. Both OpenSwan and Xl2tpd were built from source. Xelerence only links the latest release (v1.2.8).
>> 
>> The previous package I was using was from Ubuntu package manager 1.2.6+dfsg-1 which (I think) was upgraded when I did the `make install` after making the 1.2.8 source. I also tried a complete removal of the Ubuntu package and make install from 1.2.8 source but it didn't create any of the required folders or made an appropriate link in /etc/init.d/ from which to stop/start/restart things for testing. If you think that this could be my issue, I'd really appreciate a little help getting the 1.2.8 source to hook into Ubuntu cleanly other than my previous method of upgrading an existing package from source.
>> 
>> Other than that I'm using pretty much exactly the same configs you are (w dpd). The only difference is that I have a passthrough connection in addition to the l2tp-psk-nat/noNat connections, and options.xl2tpd has "noipx" in it. Niether of which will probably be the solution I'm looking for.
>> 
>> It's good to know that you have a working platform for this problem, though. I have high hopes that this issue can be resolved!
> 
> Xelerance maintains a PPA for xl2tpd from which you should be able to install xl2tpd 1.2.8:
> 
> https://launchpad.net/~xelerance/+archive/xl2tpd/
> 
> I never upgraded my system simply because I had a working package already (and why mess with success?).
> 
> It's seems possible that this is a result of a difference between 2.6.32 and 2.6.35. Just for yucks, can you share your config files (scrubbed of any IP addresses you don't want to share)?
> 
> Just for reference, here's a relevant snippet from my logs corresponding to the point where you get the "cannot install eroute" message. Based on this, maybe check the "virtual_private" list to make sure it includes the client NAT IPs and excludes the server-side NAT ranges?
> 
> May 18 14:50:12 isc pluto[28838]: "L2TP-PSK-NAT"[3] RIGHT_PUBLIC_IP #3: Applying workaround for Mac OS X NAT-OA bug, ignoring proposed subnet
> May 18 14:50:12 isc pluto[28838]: "L2TP-PSK-NAT"[3] RIGHT_PUBLIC_IP #3: the peer proposed: LEFT_PUBLIC_IP/32:17/1701 -> RIGHT_PUBLIC_IP/32:17/0
> May 18 14:50:12 isc pluto[28838]: "L2TP-PSK-NAT"[3] RIGHT_PUBLIC_IP #3: peer proposal was reject in a virtual connection policy because:
> May 18 14:50:12 isc pluto[28838]: "L2TP-PSK-NAT"[3] RIGHT_PUBLIC_IP #3:   a private network virtual IP was required, but the proposed IP did not match our list (virtual_private=)
> May 18 14:50:12 isc pluto[28838]: "L2TP-PSK-noNAT"[2] RIGHT_PUBLIC_IP #4: responding to Quick Mode proposal {msgid:e294a4cd}
> May 18 14:50:12 isc pluto[28838]: "L2TP-PSK-noNAT"[2] RIGHT_PUBLIC_IP #4:     us: LEFT_PUBLIC_IP<LEFT_PUBLIC_IP>[+S=C]:17/1701
> May 18 14:50:12 isc pluto[28838]: "L2TP-PSK-noNAT"[2] RIGHT_PUBLIC_IP #4:   them: RIGHT_PUBLIC_IP[192.168.30.37,+S=C]:17/64318
> May 18 14:50:12 isc pluto[28838]: "L2TP-PSK-noNAT"[2] RIGHT_PUBLIC_IP #4: transition from state STATE_QUICK_R0 to state STATE_QUICK_R1
> 
> -- 
> Brian Mastenbrook
> brian at mastenbrook.net
> http://brian.mastenbrook.net/



More information about the Users mailing list