Simon, thank you.
Looks like lowering the amount of socket helps.
BR,
Ruslan.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to strongswan in Ubuntu.
https://bugs.launchpad.net/bugs/1549436
Title:
AppArmor kills StronSwan daemon
Ruslan, upstream mentions that lowering the amount of socket used for
RADIUS a possible workaround:
https://wiki.strongswan.org/issues/757#note-7
Also, you might want to give a try to Ubuntu Xenial that ships
Strongswan 5.3.5 which has the fix included.
--
You received this bug notification
The crash signature looks a lot like this one:
https://wiki.strongswan.org/issues/757
** Changed in: strongswan (Ubuntu)
Status: Incomplete => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to strongswan in Ubuntu.
Hello Simon,
I'm not really sure should I post it here, report a new bug, or report a
bug to strongswan project directly.
I can reproduce this buffer overflow with 100% probability. It is a
resource independent and strongswan fail as on t1.micro or at any
instance with more resources.
Buffer
On 2016-02-26 01:11 PM, ruslan_ka wrote:
>> I have no idea what can cause this access to /dev/tty. I never ran into
>> this problem on my own server which is similar minus the EAP/RADIUS
>> part, I use xauth-generic only.
> xauth-eap works in a different way. It takes clear text password from
Looks like I've found the reason why charon want to open /dev/tty - just
to say about buffer overflow error:
01[IKE] CHILD_SA ikev2-with-eap-loadtest{221} established with SPIs c26fb333_i
c1ac3989_o and TS 172.31.59.95/32 === 10.0.0.221/32
16[IKE] CHILD_SA ikev2-with-eap-loadtest{222}
> I have no idea what can cause this access to /dev/tty. I never ran into
> this problem on my own server which is similar minus the EAP/RADIUS
> part, I use xauth-generic only.
xauth-eap works in a different way. It takes clear text password from client
and makes EAP request to a radius server
On 2016-02-25 10:50 AM, ruslan_ka wrote:
> The server serves only incoming VPN requests, it is for mobile road-
> warriors. And the error does not occur right after starting a
> strongswan or bringing tunnels up. So it makes no sense to run it with
> auto=add or not.
I somehow assumed it was an
The server serves only incoming VPN requests, it is for mobile road-
warriors. And the error does not occur right after starting a
strongswan or bringing tunnels up. So it makes no sense to run it with
auto=add or not.
Strongswan is serving clients ok. It is working for a long time until a
first
If you re-enable the Apparmor profile and set your connection to not
auto start (use "auto=add") when do you get the access denial on
/dev/tty? Is it after restarting the strongswan service or when you call
"ipsec up $conn"?
Lastly, would you mind providing an obfuscated version of your
Hello Simon,
No, I do not have encrypted certs and StrongSwan works well as a service
without user interaction:
# sudo ipsec start --nofork
Starting strongSwan 5.1.2 IPsec [starter]...
00[DMN] Starting IKE charon daemon (strongSwan 5.1.2, Linux 3.13.0-48-generic,
x86_64)
00[CFG] loading ca
@ruslan_ka, after disabling the Apparmor profiles, did you receive a
prompt for a user/password or something when starting Strongswan?
** Changed in: strongswan (Ubuntu)
Status: New => Incomplete
--
You received this bug notification because you are a member of Ubuntu
Server Team, which
12 matches
Mail list logo
