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 initiator (client) and not a responder
(server), sorry.
> Strongswan is serving clients ok. It is working for a long time until a
> first DENIAL. It looks like it is somehow related to reauthentication of
> xauth iOS client, but I can't reproduce it. Sometimes client can reauth
> ok, as I can see at logs, but sometimes right after successful reauth I
> see this error. There are about 5 active clients right now with 20-30
> connections per/day, and server gives me an error once/twice per day. I
> would not even note it, if it'd not break accounting at radius.
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.
> $ sudo cat /etc/ipsec.conf
> # ipsec.conf - strongSwan IPsec configuration file
>
> # basic configuration
>
> config setup
> strictcrlpolicy=yes
> # uniqueids = no
>
> # default options
>
> conn %default
> ikelifetime=60m
> keylife=20m
> rekeymargin=3m
> keyingtries=1
> inactivity = 60s
> dpdaction = clear
> dpdtimeout = 5s
> dpddelay = 5s
Not related to the problem at hand but you generally don't want
dpdtimeout to be equal to dpddelay. Having them equal means that loosing
a single DPD packet will kill the tunnel and have the client reconnect.
With mobile client, occasional packet loss shouldn’t force the
connection to be re-established. You usually want to redial only after
loosing say 3 DPD packets. This better detects peers going offline or
being affected by more severe connectivity problems.
As such, I'd recommend something like this:
dpdtimeout=15s
dpddelay=5s
Also, keep in mind that a low dpddelay drains the clients' battery as it
keeps the radio transmitter active more often.
> # Add connections here.
>
> conn ikev1-psk-xauth
> leftsubnet=0.0.0.0/0
> leftfirewall=yes
> leftid=@vpn.server.name
> leftauth=psk
> right=%any
> rightsourceip=10.0.0.0/9
> rightauth=psk
> rightauth2=xauth-eap
> auto=add
>
> conn ikev2-with-eap
> keyexchange=ikev2
> leftsubnet=0.0.0.0/0
> leftfirewall=yes
> leftid="C=US, O=Server.name.co, OU=VPN Dept, CN=vpn.server.name,
> E=ad...@server.name"
> leftauth=pubkey
> leftcert=vpn.server.name.pem
> right=%any
> rightsourceip=10.0.0.0/16
> rightsendcert=never
> rightauth=eap-radius
> eap_identity=%identity
> auto=add
Again, not related but aren't the 2 rightsourceip= overlapping?
> $ sudo cat /etc/strongswan.conf
> # strongswan.conf - strongSwan configuration file
>
> charon {
> load_modular = yes
> plugins {
> include strongswan.d/charon/*.conf
> }
> dns1 = 8.8.8.8
> }
>
> include strongswan.d/*.conf
>
>
> $ sudo cat /etc/strongswan.d/charon.conf | grep -v '^[[:space:]]*#'| grep .
> charon {
> crypto_test {
> }
> host_resolver {
> }
> leak_detective {
> }
> processor {
> priority_threads {
> }
> }
> tls {
> }
> x509 {
> }
> }
>
>
> $ sudo cat /etc/strongswan.d/charon/xauth-eap.conf | grep -v
> '^[[:space:]]*#'| grep .
> xauth-eap {
> backend = radius
> load = yes
> }
>
> $ sudo cat /etc/strongswan.d/charon/eap-radius.conf | grep -v
> '^[[:space:]]*#'| grep .
> eap-radius {
> accounting = yes
> load = yes
> port = 1812
> secret = secret
> server = 127.0.0.1
> sockets = 1000
> dae {
> enable = yes
> listen = 0.0.0.0
> port = 3799
> secret = dae_secret
> }
> forward {
> }
> servers {
> }
> xauth {
> }
> }
>
I honestly don't know why charon tries to access /dev/tty. Are you able
to see that message on the console or the upstart log when the Apparmor
profile is disabled?
--
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 'charon'
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/strongswan/+bug/1549436/+subscriptions
--
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
