If deciding that "right=%any" might be causing problems and changing it to "right=[ip address]" you'll find you hit an OpenSwan bug (claimed fixed in CVS for 2.4.10, but still present in Debian 2.4.12-based package) that says "pluto[10083]: "L2TP-PSK" #2: ASSERTION FAILED at kernel.c:2254: c->kind == CK_PERMANENT || c->kind == CK_INSTANCE".
Just go back to "right=%any" and if you MUST restrict the possible client IPs use iptables to do it (restrict incoming UDP port 500 and also all of protocol 50 to just the IPs you want to allow, also port 4500 if needing the whole 'NAT Traversal' thing, which I never did quite figure out the nature of).
Apparently that assertion fails because when you have "right=[ip]" you're expected to have a *specific* rightprotoport not a "17/0" or "17/%any". You can only have that specific port if the client can set such. My phone has no such option. Gotcha #2In a prior Linux IPSec implementation a new network interface 'ipsec[x]' would be created, i.e. ipsec0. The connection would come in on
( ... )
Also it seems the Android 2.1 (well Cronos specifically) IPSec stuff doesn't like Perfect Forward Security. This is meant to mean that if law enforcement get hold of your key and had previously captured packets they still can't decrypt those prior packets.
Might be a configuration issue at this point though. Atm I get:
ASSERTION FAILED at ikev1_quick.c:1847: st->st_connection != NULL
with it on along with a brief connection that then dies. Works perfectly with this off.
Oh yeah, and I'll likely fiddle with PPTP tunnels too, just for options, especially if I can have those run over port 80 on an IP not otherwise using that so it should always work unless behind a content-inspecting firewall.
Comments 3
If deciding that "right=%any" might be causing problems and changing it to "right=[ip address]" you'll find you hit an OpenSwan bug (claimed fixed in CVS for 2.4.10, but still present in Debian 2.4.12-based package) that says "pluto[10083]: "L2TP-PSK" #2: ASSERTION FAILED at kernel.c:2254: c->kind == CK_PERMANENT || c->kind == CK_INSTANCE".
Just go back to "right=%any" and if you MUST restrict the possible client IPs use iptables to do it (restrict incoming UDP port 500 and also all of protocol 50 to just the IPs you want to allow, also port 4500 if needing the whole 'NAT Traversal' thing, which I never did quite figure out the nature of).
Apparently that assertion fails because when you have "right=[ip]" you're expected to have a *specific* rightprotoport not a "17/0" or "17/%any". You can only have that specific port if the client can set such. My phone has no such option.
Gotcha #2In a prior Linux IPSec implementation a new network interface 'ipsec[x]' would be created, i.e. ipsec0. The connection would come in on ( ... )
Reply
Might be a configuration issue at this point though. Atm I get:
ASSERTION FAILED at ikev1_quick.c:1847: st->st_connection != NULL
with it on along with a brief connection that then dies. Works perfectly with this off.
Reply
Reply
Leave a comment