Excuse the poor title, just researching now why this "STABLE" upgrade broke my VPN. The tip of the iceberg alone is hardcoded paths in verify.
% grep sbin/ss openswan-2.6.39/image/usr/libexec/ipsec/verify
p = subprocess.Popen(["/usr/sbin/ss", "-n", "-l", "-u", "sport = :500"], stdout=subprocess.PIPE, stderr=subprocess.PIPE)
(Ditto the 'ip' command)
See also: http://comments.gmane.org/gmane.network.openswan.user/21974
I cannot find a fix for my other issues so I will have to downgrade the version for now
Sorry about that; I should have told ago to hold off on security bug 483204 to give it some time in ~arch.
I'll try to patch this /usr/bin/ss issue soon. If you are having other issues, please provide whatever information you can.
I didn't notice it launching only the bin. Apologize for the issue.
Created attachment 357854 [details]
log file diff
(In reply to Mike Gilbert from comment #1)
> I'll try to patch this /usr/bin/ss issue soon. If you are having other
> issues, please provide whatever information you can.
Hesitant to make this a troubleshooting forum (I hate that myself) but here is the log file diff between working and not (.38 vs .39)
(In reply to Jeremy Olexa (darkside) from comment #3)
> Hesitant to make this a troubleshooting forum (I hate that myself) but here
> is the log file diff between working and not (.38 vs .39)
Right. I'll have a look at the log later, but I'm probably not going to be able to provide much insight. I just figured it would be a good idea to at least document it.
I'm personally not having any issues with my limited use case (a PSK L2TP VPN to a Windows server).
Yea, basically when I start XL2TPD with debugging and have openswan (ipsec) 2.6.38 running, when the client connects I'll see Xl2TPD doing stuff. With openswan-2.6.39 running, there is nothing in the XL2TPD messages (literally nothing). So, something is obviously happening in that handoff area (or even before). Unfortunately, this is one of those pieces of software that I have running and have little working knowledge of...
Hi, I am having the same bug posted by Jeremy here (openswan does not hand the connection over to xl2tpd). Wanted to be safe, so I've also tried xl2tpd 1.3.2, unfortunately without luck. Does anyone have more insights on this?
Ok, weird, same setup for server and client, needed to change "leftprotoport=17/1701" to "leftprotoport=17/%any" to make it working...
(In reply to Stefano from comment #7)
> Ok, weird, same setup for server and client, needed to change
> "leftprotoport=17/1701" to "leftprotoport=17/%any" to make it working...
Confirmed. Thanks for the tip.