FB7360 en VPN timeout

[Joe]

Ik ben bezig VPN op te tuigen via de Fritz 7360 (XS4all). Dat lukt
inmiddels vrij aardig maar ieder uur wordt de verbinding verbroken:

07.05.15 13:37:54 VPN connection to xxxxxxx has been cleared. Cause: 1
Lifetime expired

en dat ieder uur. Google meldt over dit probleem van alles inclusief
dat het in Fritz OS 06.20 zou zijn opgelost maar die draai ik en het
probleem blijkbaar NIET opgelost. Wie o wie geeft me wat tips. Is
die lifetime ergens op "onbeperkt" te zetten?

Hebben andere Fritzen (7390, 7490) dit probleem ook (nog)?

[Osiris]

Inderdaad, schurftirritant.. Hier ook een 7360 met dit probleem. Het
antwoord van AVM n.a.v. een ticket van me:

> Dear Mr. <Knip>,
>
> Thank you very much for the enquiry you submitted to AVM Support.
>
> There is no known "bug" concerning the lease time VPN connections via the
> FRITZ!Box in FRITZ!OS 6.06. It is the lease time for VPN connections that
> has been changed from 1h to 8h in formware 06.20.
>
> A manual adjustment is not possible, the connection will be disconnected
> after 8h of inactivity with FRITZ!OS 6.20.
>
> The following link contains detailed information regarding your support
> request:
>
> http://en.avm.de/nc/service/fritzbox/fritzbox-7340/knowledge-base/publication/sh
> ow/202_Error-message-VPN-connection-to-has-been-cleared-Cause-in-the-event-log-o
> f-the-FRITZ-Box/
>
> We do not have further recommendations on this behaviour except to test
> with another VPN client/software on the smartphone.
>
> Best regards,
>
> Michael Ellguth (AVM Support)

Nou Michael.. Leer eens le-zen. Ik heb duidelijk in mijn ticket gezegd
dat er megabytes aan data over die frikkin' tunnel gaat. Heck, ik liet
m'n server elke tig seconden de VPN-endpoint van m'n telefoon pingen (en
heb dat gemeld in m'n ticket!). Hoe krijg je de tunnel dan zónder
inactivity, zoals onze vriend Michael vermeldt als reden?

Kortom, óf de AVM-support is achterlijk óf ze wíllen het niet fixen...

[Rob]

Ik denk dat die meneer het niet begrepen heeft maar dat het niks met
idle time te maken heeft.

Dit gaat over de IPsec lifetime en die is default 1 uur max 8 uur.
Na die tijd wordt er een nieuwe onderhandeling mbt de sleutels uitgevoerd,
dat is niet specifiek Fritzbox maar gebeurt in ieder IPsec VPN.

De harde realiteit is dat deze functionaliteit heel vaak buggy is, en
de Fritzbox is daarop geen uitzondering. Maar in Racoon zijn er ook
altijd problemen mee, wellicht gebruiken ze dat ding.

Dit is inderdaad behoorlijk frustrerend en heeft als resultaat dat de
gebruikers naar andere VPN technieken dan IPsec weg vluchten.
Maar dan moet je wel de keus hebben. OpenVPN wordt in routers meestal
niet ondersteund en ik heb begrepen dat fabrikanten die dat wel inbouwen
met rechterlijke dwang achtervolgd worden door de bedenkers daarvan.
Dan is het er later ineens weer uit.

[Osiris]

't Is ongetwijfeld een brakke, buggy implementatie van 't e.e.a., maar
de reden die AVM in hun Fritz!Box plaatst bij het optreden van die
kutzooi ('Cause 1: Lifetime expired') is: "There was no data exchange
via the VPN connection for over an hour."

Dat lijkt me dus iets anders dan puur de IPSec lifetime, die inderdaadn,
naar mijn beste weten, prima (in theorie) opnieuw onderhandeld zou
moeten kunnen worden (de sleutels dan e.d.)..

Maar hey, waarom aan je klant toegeven dat er iets mis is als je 't ook
gewoon allemaal kut met peren kunt laten zijn!

[Joe]

Nou, bij mij gaat ie na 1 uur terwijl de streaming beurskosten
binnenlopen (VNC over de VPN).

Dus inderdaad niks 8 uur en niks "geen verkeer".

Maarja, wat kan ik dan nog doen? Doet het probleem zich inderdaad
alleen met Android apparaten voor of ook met andere OS'en als client?
Welke VPN client (Android) heeft het probleem niet?

Dit komt zeer amateuristisch over en het antwoord dat jij gehad hebt
getuigt van a) gebrek aan intellect of b) gebrek aan wil of kennis om
het probleem op te lossen.

Doet het probleem zich ook voor op andere routers, is het tijd om de
Fritz in te ruilen?

Ben eigenlijk ook wel benieuwd of XS4all als privacy minded provider
dit soort issues hoort en aankaart bij AVM. Als kleine man gaat het
niet werken, dat leid ik uit het AVM antwoord hierboven wel af....

[robert]

Joe <none@nowhere>:

> Maarja, wat kan ik dan nog doen? Doet het probleem zich inderdaad alleen
> met Android apparaten voor of ook met andere OS'en als client?

Ik kan alleen maar zeggen dat ik het probleem niet herken met Mac OS X en
IPSecuritas als client software, de verbinding houdt het daarmee uren
probleemloos vol, zelfs als er praktisch niks overheen gaat.

--
robert

[Rob]

Osiris <osiris@invalid> wrote:
>> Ik denk dat die meneer het niet begrepen heeft maar dat het niks met
>> idle time te maken heeft.
>>
>> Dit gaat over de IPsec lifetime en die is default 1 uur max 8 uur.
>> Na die tijd wordt er een nieuwe onderhandeling mbt de sleutels uitgevoerd,
>> dat is niet specifiek Fritzbox maar gebeurt in ieder IPsec VPN.
>>
>> De harde realiteit is dat deze functionaliteit heel vaak buggy is, en
>> de Fritzbox is daarop geen uitzondering. Maar in Racoon zijn er ook
>> altijd problemen mee, wellicht gebruiken ze dat ding.
>>
>> Dit is inderdaad behoorlijk frustrerend en heeft als resultaat dat de
>> gebruikers naar andere VPN technieken dan IPsec weg vluchten.
>> Maar dan moet je wel de keus hebben. OpenVPN wordt in routers meestal
>> niet ondersteund en ik heb begrepen dat fabrikanten die dat wel inbouwen
>> met rechterlijke dwang achtervolgd worden door de bedenkers daarvan.
>> Dan is het er later ineens weer uit.
>
> 't Is ongetwijfeld een brakke, buggy implementatie van 't e.e.a., maar
> de reden die AVM in hun Fritz!Box plaatst bij het optreden van die
> kutzooi ('Cause 1: Lifetime expired') is: "There was no data exchange
> via the VPN connection for over an hour."

Ik denk dat de meneer die het handboek geschreven heeft het OOK niet
begrepen heeft!

> Dat lijkt me dus iets anders dan puur de IPSec lifetime, die inderdaadn,
> naar mijn beste weten, prima (in theorie) opnieuw onderhandeld zou
> moeten kunnen worden (de sleutels dan e.d.)..

Uiteraard, maar dat werkt vaak niet goed. Ik ben net een tijd aan het
tobben geweest met Racoon. Black magic. De ene installatie werkt
prima, de andere identieke installatie werkt niet goed. En functies
die je kunt gebruiken in die context (zoals het aanroepen van user
scripts als er zo'n Phase 1 associatie up of down gaat) die werken ook
niet betrouwbaar.

Ik denk dat AVM deze crap in de Fritzbox ook gebruikt en dat daar nu
dezelfde ellende in zit.

[Dirk T. Verbeek]

Op 07-05-15 om 19:37 schreef robert:

Ik had dit ook al gemerkt en inderdaad de VPN kapt er elk uur mee ook
als er wel data over gaat.

Dit is met verschillende versies van Kubuntu Linux.

[robert]

robert <US3N37+{x.g}@gmail.com>:

> Joe <none@nowhere>:
>> Maarja, wat kan ik dan nog doen? Doet het probleem zich inderdaad
>> alleen met Android apparaten voor of ook met andere OS'en als client?
>
> Ik kan alleen maar zeggen dat ik het probleem niet herken met Mac OS X en

> IPSecuritas als client software...

Overigens gebruikt dat gewoon racoon onder de motorkap.

--
robert

[Dirk T. Verbeek]

Op 07-05-15 om 20:17 schreef Dirk T. Verbeek:

Net nog even geprobeerd, na een uur wordt de download afgebroken.

[Remko]

Ik kan de ervaring met de AVM helpdesk bevestigen. Weinig kennis en een
cultuur van "wij zijn slim en U snapt er niks van", wat feitelijk dus
net andersom is ;)

Dat de verschillende FB (firmware) development blijkbaar geen quality
control kent kan ik ook bevestigen. Opmerkelijk hoeveel bugs er in dat
ding zitten. Ook voor de hand liggende als vertaal fouten e.d.

Ik gebruikte OpenVPN door de FB heen naar een achterliggende Synology
NAS. De FB doet echter iets geks waardoor de authenticatie niet meer
doorkomt. Zonder FB werkt het prima. Ben maar over gestapt op een
Fortinet VPN over SSL, dus met zo min mogelijk bemoeienis van de FB,
anders dan een TCP port forward (OpenVPN werkt op een Synology alleen
met UDP wat dus niet compatible is met de behandeling door de FB).

Ik zal nog even testen met IPsec door de FB, maar omdat dat ook van
meerdere UDP poorten gebruikt maakt vrees ik het ergste..

[Rob]

Remko <rcsin...@xs4all.nl> wrote:
> Ik gebruikte OpenVPN door de FB heen naar een achterliggende Synology
> NAS. De FB doet echter iets geks waardoor de authenticatie niet meer
> doorkomt. Zonder FB werkt het prima.

Is dat het probleem:
TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)

Dat zie ik namelijk ook op een andere router. Ik snap niet wat het kan
zijn, zo'n NAT router gaat toch niet in de TLS-over-UDP packets (1194)
lopen loeren hoop ik?

NTP pakketjes en hun antwoorden komen keurig door, OpenVPN antwoorden
komen soms niet door. De uitgaande packets komen wel altijd aan.

[Oscar]

In article <554b8c03$0$2864$e4fe...@news.xs4all.nl>,

Osiris <osiris@invalid> wrote:
>Inderdaad, schurftirritant.. Hier ook een 7360 met dit probleem.

<aol>me too!</aol> Ook een 7360 met versie 6.20.

In xs4all.adsl liep een draadje genaamd "VPN-timeout in FritzOS 6.20 (FB
7360)", waar ene Friso meldt dat hij met VPNCilla geen problemen heeft.

Ik heb VPNCilla inmiddels geprobeerd. Ja hoor, na een uur video streamen
loopt de verbinding net zo hopeloos vast. In de instellingen staat iets
van Dead Pear Detection die je volgens de Help bij Fritz!Boxen op 0 moet
zetten. Default staat ie op 30. Guess what, zowel op 0 als op 30 valt
de verbinding na een uur uit. Misschien is dat wel het probleem dat AVM
met 6.20 "gefixed" heeft?

Opvallend vind ik wel dat de Android kant denkt dat de verbinding nog up
is terwijl Fritz vond dat de verbinding verbroken was. En dat terwijl er
echt continue verkeer beide kanten loopt. Als het nog een UDP stream zou
zijn, kan je nog voorstellen dat Fritz time-out omdat er nooit wat terug
komt, maar dit was een TCP-stream, dus dan komt er genoeg retour om de
verbinding levend te houden, lijkt mij.
--
[J|O|R] <- .signature.gz

[Oscar]

In article <554c8ecb$0$2842$e4fe...@news2.news.xs4all.nl>,

Oscar <jornw...@xs4all.nl> wrote:
>--
>[J|O|R] <- .signature.gz
>
>--
>[J|O|R] <- .signature.gz

Bummer... ook wel erg 1970 om te denken dat Supersedes nog werkt.

<xs4all>Excuses voor het ongemak</xs4all>

[Rob]

Oscar <jornw...@xs4all.nl> wrote:
> Opvallend vind ik wel dat de Android kant denkt dat de verbinding nog up
> is terwijl Fritz vond dat de verbinding verbroken was. En dat terwijl er
> echt continue verkeer beide kanten loopt. Als het nog een UDP stream zou
> zijn, kan je nog voorstellen dat Fritz time-out omdat er nooit wat terug
> komt, maar dit was een TCP-stream, dus dan komt er genoeg retour om de
> verbinding levend te houden, lijkt mij.

Even dat idee parkeren dat het iets met activiteit te maken heeft want
dat is echt niet zo. Als dat ergens in een handleiding staat dan is
die handleiding fout. Het is LIFEtime, niet IDLEtime!

[Oscar]

In article <slrnmkp6bk...@xs8.xs4all.nl>,

Vertel jij het AVM? Volgens google speelt dit probleem al een paar jaar,
maar zo te zien heeft nog niemand bij AVM dit licht gezien.

Ik vind dit ook best lastig troubleshooten omdat beide platformen
relatief gesloten zijn en ik geen root heb op de tussenliggende
infrastructuur. Wat mist Fritz bij Android dat ie bij andere systemen
wel krijgt?

Overigens is de tijd niet een uur, maar exact 54 minuten of soms nog een
seconde eerder als ik de timestamps in de logs mag geloven.

[Dirk T. Verbeek]

Op 08-05-15 om 13:51 schreef Oscar:

Inderdaad, ik had het gisterenavond op 55 minuten geschat.
Ook de Linux network manager blijft het betreffende VPN icoontje tonen
nadat de verbinding aan de Fritz kant afgesloten is.
Gelukkig wordt er geen alternatieve (onveilige) verbinding opgezet,
tenminste niet totdat je zelf die VPN uitzet.

[robert]

robert <US3N37+{x.g}@gmail.com>:

Bij deze even een screenshot (FB 7360 met FRITZ!OS 06.05):
https://dl.dropboxusercontent.com/u/1577733/ipsec.png

Uptime inmiddels ruim 2 uur, wat overeenkomt met het moment waarop ik de
verbinding aangezet heb. Ik heb een ssh-verbinding lopen naar m'n server
thuis (via welke ik dit post) en die is ook niet weggevallen of zo. Verder
gebeurt er weinig op de lijn (maar we hebben inmiddels geleerd dat het
LIVEtime is en niet IDLEtime dus dat zou toch niks uit moeten maken).

--
robert

[Oscar]

In article <slrnmkpir4...@my.local.lan>,

robert <US3N37+{x.g}@gmail.com> wrote:
>robert <US3N37+{x.g}@gmail.com>:
>> Joe <none@nowhere>:
>>> Maarja, wat kan ik dan nog doen? Doet het probleem zich inderdaad
>>> alleen met Android apparaten voor of ook met andere OS'en als client?
>>
>> Ik kan alleen maar zeggen dat ik het probleem niet herken met Mac OS X en
>> IPSecuritas als client software, de verbinding houdt het daarmee uren
>> probleemloos vol, zelfs als er praktisch niks overheen gaat.
>
>Bij deze even een screenshot (FB 7360 met FRITZ!OS 06.05):
>https://dl.dropboxusercontent.com/u/1577733/ipsec.png

Die hoge uptime haal ik ook wel, maar kun je er nog data overheen
sturen? Wat zegt je systeemlog in je FB na ongeveer 54 minuten?

Mijn (Android) client zegt ook doodleuk dat de VPN al 2 uur up is,
alleen heeft Fritz de verbinding na 54 minuten eenzijdig stuk gemaakt.

Het kan ook zijn dat jouw Mac een betere detectie heeft van kapotte
VPN's en de verbinding gewoon even opnieuw opzet. Kun je toch eens
kijken of je daar wat van terug kan vinden in diverse logs?

[robert]

Oscar <jornw...@xs4all.nl>:

> In article <slrnmkpir4...@my.local.lan>, robert
> <US3N37+{x.g}@gmail.com> wrote:
>>>
>>> Ik kan alleen maar zeggen dat ik het probleem niet herken met Mac OS
>>> X en IPSecuritas als client software, de verbinding houdt het daarmee
>>> uren probleemloos vol, zelfs als er praktisch niks overheen gaat.
>>
>>Bij deze even een screenshot (FB 7360 met FRITZ!OS 06.05):
>>https://dl.dropboxusercontent.com/u/1577733/ipsec.png
>
> Die hoge uptime haal ik ook wel, maar kun je er nog data overheen sturen?

Yup.

> Wat zegt je systeemlog in je FB na ongeveer 54 minuten?

08.05.15 19:49:47 Login to the FRITZ!Box user interface from the IP address 192.168.23.250.
08.05.15 14:21:53 VPN connection to X...@YYY.ZZZ was established successfully.

Uptime is inmiddels 5:30 uur, wat ook overeenkomt met de log.

> Mijn (Android) client zegt ook doodleuk dat de VPN al 2 uur up is, alleen
> heeft Fritz de verbinding na 54 minuten eenzijdig stuk gemaakt.
>
> Het kan ook zijn dat jouw Mac een betere detectie heeft van kapotte VPN's
> en de verbinding gewoon even opnieuw opzet. Kun je toch eens kijken of je
> daar wat van terug kan vinden in diverse logs?

Ik zou verwachten dat m'n ssh verbinding dan in ieder geval stuk zou zijn,
wat niet het geval is:

$ lastlog
...
robert pts/0 192.168.23.250 Fri May 8 14:22:07 +0200 2015
...

--
robert

[Remko]

Ik heb zo snel ook geen verklaring. Feit is dat exact dezelfde aktie
zonder FB prima een VPN opzet, maar door de FB geeft dat deze error:

Sat May 09 20:58:00 2015 [Snake Oil CA] Peer Connection Initiated with
[AF_INET]<mijn ip>:1194
Sat May 09 20:58:03 2015 AUTH: Received control message: AUTH_FAILED
Sat May 09 20:58:03 2015 SIGUSR1[soft,auth-failure] received, process
restarting

Ik doe VPN ondertussen zonder FB, dus ik laat dit maar even voor wat het is.

[Rob]

Ok inmiddels weet ik dat het in mijn geval wat anders is.
Er zit geen Fritzbox tussen maar een Netgear, en daar zit kennelijk een
of andere instelling in om bepaald verkeer wat men verdacht vindt te
blokkeren (flooding, gaming whatever).
Als je een boel UDP packets door die router heen stuurt word je geblokkeerd.
Daardoor gaat OpenVPN uiteraard meteen de mist in. Een TCP verbinding
werkt wel.
Omdat ik niet bij die router kan en alleen de problemen kan troubleshooten
weet ik niet wat het in detail is, ik hoop dat ik na het weekend iemand
er naar kan laten kijken die enig idee heeft wat dit zou kunnen zijn.

Wat ik zo JAMMER vind van OpenVPN is dat je geen server kunt draaien die
zowel UDP als TCP ondersteunt zodat je clients naar behoefte UDP of TCP
kunnen gebruiken naar gelang de lokale situatie.
Dat is echt een enorme misser van OpenVPN, dat zouden ze toch simpel
moeten kunnen fixen, hij kan wel TCP of UDP maar niet beiden.

[jjge]

Hmmm... ik had een tijdje geleden een vergelijkbaar probleem met een KPN
Experia box. Dit zou best eens de reden kunnen zijn... weet iemand meer?

[Joe]

Moet ik dan misschien downgraden naar 06.05 ipv de huidige 06.20?

[robert]

Joe <none@nowhere>:

Ik durf daar geen uitspraken over te doen. De reden waarom ik (nog) op
06.05 zit is vooral luiheid (plus "het werkt").

--
robert

[Dirk T. Verbeek]

Op 07-05-15 om 17:45 schreef Joe:

Ik werd het dit weekend zat steeds weer opnieuw te moeten verbinden en
heb dus ook een ticket aangemaakt bij AVM.
Daarin heb ik ook duidelijk gezet dat het geen Idle Time probleem kan
zijn omdat de datastroom verbroken wordt.

[Paul Slootman]

Rob <nom...@example.com> wrote:
>
>Wat ik zo JAMMER vind van OpenVPN is dat je geen server kunt draaien die
>zowel UDP als TCP ondersteunt zodat je clients naar behoefte UDP of TCP
>kunnen gebruiken naar gelang de lokale situatie.

Het is natuurlijk niet moeilijk om 2 openvpn servers naast elkaar te
laten draaien.


Paul

[Rob]

Dat is WEL moeilijk!
Want dan heb je 2 subnetten, 2 interfaces, 2 statusfiles, etc.
Kortom je hele beheer wordt er moeilijker door.

Ik wil mijn subnet helemaal niet splitsen in een TCP en een UDP deel,
en een adres wijzigen als iemand van UDP naar TCP gaat.

(mijn doel om een VPN te draaien is om de clients vaste adressen te geven
hoe ze ook connecten en wat voor variabel internet adres ze ook hebben)

[Friso]

'Ene Friso' kan nog steeds bevestigen dat het bij hem met VPNCilla
goed werkt. De verbinding wordt door VPNCilla wel elk uur opnieuw
gemaakt, maar dat gebeurt op de achtergrond en daar merk ik niks van.
Ik krijg dus uren nadat de eerste verbinding is gemaakt nog steeds
data over de lijn.

[NiElS]

Om deze reden gebruik ik steeds vaker openconnect+ocserv. Verbind in
eerste instantie op TCP en schakelt vervolgens UDP bij waar mogelijk.
Beheer via bijgeleverde occtl is ook goed te doen.

NiElS

[Rob]

O dat is interessant, dat is dan wellicht nog een idee om er naast te
zetten (hoewel dat initieel net zo lastig is als een 2e OpenVPN instance)
en misschien OpenVPN uitfaseren als dit voor iedereen een oplossing is.

Puntje is nog even dat clients gebruikt worden op allerlei platformen
(Linux, Windows, Android, iOS) dus ik moet eerst kijken of er een gratis
client voor dit protocol is.

Bedankt voor de tip in ieder geval!

[Oscar]

In article <55507c66$0$2849$e4fe...@news.xs4all.nl>,
Friso <f...@xsFOURall.nl.invalid> wrote:
>
>'Ene Friso'

Oh hai, daar ben je! ;-)

>kan nog steeds bevestigen dat het bij hem met VPNCilla
>goed werkt. De verbinding wordt door VPNCilla wel elk uur opnieuw
>gemaakt, maar dat gebeurt op de achtergrond en daar merk ik niks van.
>Ik krijg dus uren nadat de eerste verbinding is gemaakt nog steeds
>data over de lijn.

Mmm.. okay, maar dat is een aardige nuancering ten opzichte van "geen
problemen". In mijn geval probeerde ik live videostreams te bekijken
vanaf mijn DVB-C ontvanger thuis. Ook met VPNCilla ging dat de mist in.

Ik had gehoopt dat met VPNCilla (of welke oplossing dan ook) de VPN niet
meer stuk zou gaan. Dat is dus niet zo..

Overigens heb ik niet ervaren dat ie automatisch opnieuw verbond, maar
dat kan ik nu niet meer proberen omdat de trialperiode voorbij was.

Overigens heb ik uiteindelijk maar een VPN-accountje genomen met een
server in Londen, waardoor ik me als Engels staatsburger kon voordoen en
via de BBC livestreams beide tafels tegelijk kon bekijken. Dat werkte
verder vrijwel probleemloos.

Maar ik zou toch wel een VPN naar huis willen kunnen opzetten zonder
workarounds aan te moeten schaffen.

[Friso]

Oscar <jornw...@xs4all.nl> wrote:
> In article <55507c66$0$2849$e4fe...@news.xs4all.nl>,
> Friso <f...@xsFOURall.nl.invalid> wrote:
>>
>>'Ene Friso'
>
> Oh hai, daar ben je! ;-)
>
>
>>kan nog steeds bevestigen dat het bij hem met VPNCilla
>>goed werkt. De verbinding wordt door VPNCilla wel elk uur opnieuw
>>gemaakt, maar dat gebeurt op de achtergrond en daar merk ik niks van.
>>Ik krijg dus uren nadat de eerste verbinding is gemaakt nog steeds
>>data over de lijn.
>
> Mmm.. okay, maar dat is een aardige nuancering ten opzichte van "geen
> problemen". In mijn geval probeerde ik live videostreams te bekijken
> vanaf mijn DVB-C ontvanger thuis. Ook met VPNCilla ging dat de mist in.
>
> Ik had gehoopt dat met VPNCilla (of welke oplossing dan ook) de VPN niet
> meer stuk zou gaan. Dat is dus niet zo..

Ik kan het wel weer wat de-nuanceren ;). Ik heb vanmiddag geprobeerd. TV
over VPN. De verbinding is opnieuw gemaakt, maar ik heb daar bij het TV
kijken niets van gemerkt. Het zou kunnen dat er een kleine hapering is
geweest (volgens mij niet) maar het is dus niet zo dat het na een uur
stopt of zo. Ik zag in de log wel dat de verbinding in die tijd opnieuw
is gemaakt of hersteld of hoe je het wil noemen.

Ik werk al een paar jaar met VPNcilla en het probleem dat er na een uur
geen verbinding meer zou zijn herken ik dus totaal niet.

>
> Overigens heb ik uiteindelijk maar een VPN-accountje genomen met een
> server in Londen, waardoor ik me als Engels staatsburger kon voordoen en
> via de BBC livestreams beide tafels tegelijk kon bekijken. Dat werkte
> verder vrijwel probleemloos.

Dat is handig inderdaad, maar ik gebruik VPN juist om ervoor te zorgen
dat ik veilig publieke (incl op mijn werk) wi-fi kan gebruiken.

[Oscar]

In article <5550ef77$0$2859$e4fe...@news.xs4all.nl>,

Friso <f...@xsFOURall.nl.invalid> wrote:
>Ik kan het wel weer wat de-nuanceren ;). Ik heb vanmiddag geprobeerd. TV
>over VPN. De verbinding is opnieuw gemaakt, maar ik heb daar bij het TV
>kijken niets van gemerkt. Het zou kunnen dat er een kleine hapering is
>geweest (volgens mij niet) maar het is dus niet zo dat het na een uur
>stopt of zo.

Welke techniek gebruik jij om te streamen?

Ik heb hier MythTV. Die werkt heel goed samen met de Linux en de Mac
versie van MythFrontend, maar iets minder met uPnP clients. Probleem is
vooral dat een lopende opname een bepaalde lengte doorgeeft en dat alle
Android clients na die lengte "bekijk het maar" zeggen. Daarbovenop
willen die clients niet vooruit of achteruit "spoelen" in de streams die
ik ze aanbood.

Dit zeg ik verkeerd. Dit gebeurt alleen als ik transcode. Direct naar de
MythTV-doos ging het wel goed, maar dan ging de volle 5Mbit upstream vol
en ook de soms wat brakke Wifi aan de ontvangende kant hield het niet
bij, dus ik moest transcoden. De MythTV bak bleek daar te traag voor,
dus daar werd mijn snellere doos voor ingezet.

Wat uiteindelijk werkte was: VLC (met de UI via remote X) op de trage
bak, met een UDP-stream als uitgang. Op mijn snelle bak had ik VLC als
relay die die UDP-stream transcode naar een H264 TCP-Stream van 1.5
Mbit. Daar richtte ik dan vanaf mijn Android VLC op. Ik kon dan via de
eerste VLC spoelen en pauzeren, de tweede zorgde dan voor een redelijke
bitrate en de derde was dan puur een monitor. Werkte prima, voor 54
minuten...

Achteraf bedenk ik me dat ik die stream ook via een portforward had
kunnen laten gaan. Maar voordat ik zover was, had ik al de BBC-route
ontdekt als een heel veel beter alternatief om Snooker te kijken. :)

TL;DR, ik had een TCP-stream waarbij de Android client connect naar een
HTTP server op mijn thuisPC. Dit werkte telkens voor 54 minuten.

>Ik zag in de log wel dat de verbinding in die tijd opnieuw
>is gemaakt of hersteld of hoe je het wil noemen.

Nou ben ik wel benieuwd: gebeurt dit altijd, of moet er verkeer een
bepaalde kant op lopen? Ik vind VPNCilla nog altijd wel een prettige
client, dus ik ben wel bereid om er voor te betalen om verder te
experimenteren. Mijn trial periode heb ik laten verlopen...

>Dat is handig inderdaad, maar ik gebruik VPN juist om ervoor te zorgen
>dat ik veilig publieke (incl op mijn werk) wi-fi kan gebruiken.

Dat is inderdaad een andere use case waar ik in geinteresseerd ben.
Defaultroute via de VPN en gaan...

[Friso]

Oscar <jornw...@xs4all.nl> wrote:
> In article <5550ef77$0$2859$e4fe...@news.xs4all.nl>,
> Friso <f...@xsFOURall.nl.invalid> wrote:
>>Ik kan het wel weer wat de-nuanceren ;). Ik heb vanmiddag geprobeerd. TV
>>over VPN. De verbinding is opnieuw gemaakt, maar ik heb daar bij het TV
>>kijken niets van gemerkt. Het zou kunnen dat er een kleine hapering is
>>geweest (volgens mij niet) maar het is dus niet zo dat het na een uur
>>stopt of zo.
>
> Welke techniek gebruik jij om te streamen?
>

de xs4all webtv app :) En ook Spotify.

> Ik heb hier MythTV. Die werkt heel goed samen met de Linux en de Mac
> versie van MythFrontend, maar iets minder met uPnP clients. Probleem is
> vooral dat een lopende opname een bepaalde lengte doorgeeft en dat alle
> Android clients na die lengte "bekijk het maar" zeggen. Daarbovenop
> willen die clients niet vooruit of achteruit "spoelen" in de streams die
> ik ze aanbood.
>
> Dit zeg ik verkeerd. Dit gebeurt alleen als ik transcode. Direct naar de
> MythTV-doos ging het wel goed, maar dan ging de volle 5Mbit upstream vol
> en ook de soms wat brakke Wifi aan de ontvangende kant hield het niet
> bij, dus ik moest transcoden. De MythTV bak bleek daar te traag voor,
> dus daar werd mijn snellere doos voor ingezet.
>
> Wat uiteindelijk werkte was: VLC (met de UI via remote X) op de trage
> bak, met een UDP-stream als uitgang. Op mijn snelle bak had ik VLC als
> relay die die UDP-stream transcode naar een H264 TCP-Stream van 1.5
> Mbit. Daar richtte ik dan vanaf mijn Android VLC op. Ik kon dan via de
> eerste VLC spoelen en pauzeren, de tweede zorgde dan voor een redelijke
> bitrate en de derde was dan puur een monitor. Werkte prima, voor 54
> minuten...
>
> Achteraf bedenk ik me dat ik die stream ook via een portforward had
> kunnen laten gaan. Maar voordat ik zover was, had ik al de BBC-route
> ontdekt als een heel veel beter alternatief om Snooker te kijken. :)
>
> TL;DR, ik had een TCP-stream waarbij de Android client connect naar een
> HTTP server op mijn thuisPC. Dit werkte telkens voor 54 minuten.

Mooie set-up :). Maar de vraag is natuurlijk of het eindigen na 54
minuten nou echt aan de Fritzbox + Android VPN verbinding ligt of dat
een van de systemen of applicaties ertussen iets niet lekker doet.
OT: Die WK-Snooker finale was wel wel legendarisch dit jaar!

>
>>Ik zag in de log wel dat de verbinding in die tijd opnieuw
>>is gemaakt of hersteld of hoe je het wil noemen.
>
> Nou ben ik wel benieuwd: gebeurt dit altijd, of moet er verkeer een
> bepaalde kant op lopen? Ik vind VPNCilla nog altijd wel een prettige
> client, dus ik ben wel bereid om er voor te betalen om verder te
> experimenteren. Mijn trial periode heb ik laten verlopen...

De verbinding wordt altijd hersteld, verkeer of niet. Trouwens ook
regelmatig als ik heen en weer loop, ik heb niet overal Wi-fi. Maar dat
gebeurt allemaal op de achtergrond. Bij de test hierboven heb ik er wel
voor gezorgd dat ik wel steeds wi-fi verbinding bleef houden en de
verbinding echt vanwege de tijd werd hersteld, dat bleek ook uit de log.

>
>>Dat is handig inderdaad, maar ik gebruik VPN juist om ervoor te zorgen
>>dat ik veilig publieke (incl op mijn werk) wi-fi kan gebruiken.
>
> Dat is inderdaad een andere use case waar ik in geinteresseerd ben.
> Defaultroute via de VPN en gaan...

Ik vind het erg makkelijk. 3G gaat ook via VPN. Enige nadeel is dat je
in je dataverbruik alleen nog maar 'VPNCilla' ziet en niet de apps die
ervan gebruik maken.

[Dirk T. Verbeek]

Op 11-05-15 om 02:31 schreef Dirk T. Verbeek:

Ondertussen heb ik een mail van AVM en ze hebben veel vragen waaronder
een kopie van het .cfg bestand wat ik in de Fritzbox heb gezet.

"- Please also send us the file "vpnuser[...].cfg". The file contains
the VPN configuration you created using "Configure FRITZ!VPN
Connection". You can find the file "vpnuser[...].cfg" in the following
folder:"

En dan leggen ze uit waar je dat op een Windows computer kunt vinden
terwijl ik duidelijk had aangegeven dat dit probleem met mijn Linux
machine gebeurt.

Maakt niks uit, ze krijgen dat bestand.

Verder willen ze het bekende support support bestand wat de Fritzbox
zelf kan genereren.

We zullen zien...

[Dirk T. Verbeek]

Op 13-05-15 om 20:08 schreef Friso:

> Maar de vraag is natuurlijk of het eindigen na 54
> minuten nou echt aan de Fritzbox + Android VPN verbinding ligt of dat
> een van de systemen of applicaties ertussen iets niet lekker doet.

Het gebeurt ook onder Kubuntu Linux en het zou mij verassen dat dat
eenzelfde network stack of manager heeft.

Ik heb om support gevraagd en daar wordt nu aan gewerkt.

Dus doe nou hetzelfde, volg de link in de Fritz en kaart het aan.

[Rob]

Ik weet dat in oude versies van de Fritzbox software de box zelf via
de GUI geen VPN's kon maken en dat je een apart Windows programma moest
draaien om de configuratie te doen en de file dan in de Fritzbox te
uploaden waar de VPN dan actief gemaakt werd. Die file bedoelen ze.

Maar ik had uit deze discussie het idee gekregen dat het niet meer op
die rare manier hoeft maar dat er nu in de Fritzbox GUI ook een mogelijkheid
is om een VPN te maken. Zou kunnen dat die lokaal op de box uiteindelijk
nog wel diezelfde file maakt. Het was een tekstfile met een aantal
parameters mbt IPsec, heb ik wel eens gezien.

[jjb]

On 13-05-2015 20:08, Friso wrote:
> ...

> OT: Die WK-Snooker finale was wel wel legendarisch dit jaar!

>...
Niet alleen de finale, meerdere matches waren verrassend. Mijn vrouw en
ik hebben 17 dagen van 11:00 's-morgens tot (vaak) middernacht voor de
dwangbuis gezeten... (BBC Red Button hebben we ook...)

[Dirk T. Verbeek]

Op 14-05-15 om 08:44 schreef Rob:

Dit is wat ik in m'n mail aan AVM schreef:
------------
By lack of a Linux compliant template on the AVM site I used one from a
site called:
"https://www.gadgetgoeroe.nl/handleidingen/fritzbox-vpn-installeren-en-mac-vpn-client/"

------------
Op die 54 min. time out na werkt het prima.

Nu kunnen ze gelijk even een officiele template op hun site zetten :)

[Rob]

Ik zie daar dit in staan:

mode = phase1_mode_aggressive;

Dat is een slecht plan.
Ik weet niet wat precies de mogelijkheden bij de Fritbox zijn maar
maak daar eens van mode = phase1_mode_main;

Nadeel is dan wel dat je op de remote moet matchen op het IP adres,
je kunt niet meer matchen op de "name". Maar de kans dat het fout
gaat op de manier die je beschrijft is wel kleiner.

[Dirk T. Verbeek]

Op 14-05-15 om 17:43 schreef Rob:

Dank je voor het meedenken.

Ik heb er niet veel verstand van maar begrijp ik het goed dat ik na deze
aanpassing op de remote een "name" moeten vervangen door een IP?

Ik ben veel op reis dus dat wordt geen vaste IP, die van thuis is
uiteraard bekend.

Tot dan lijkt het me dat ik dit niet wil proberen totdat ik weer in de
buurt van de Fritz ben.

[Dirk T. Verbeek]

Op 14-05-15 om 16:41 schreef Dirk T. Verbeek:

Nog wat info uit de Fritz:
---------------
15.05.15 05:04:54 VPN connection to MyFritz was established successfully.
15.05.15 05:03:57 VPN connection to MyFritz has been cleared. Cause: 3
IKE server
15.05.15 04:59:55 VPN connection to MyFritz was established successfully.
15.05.15 04:59:54 VPN connection to MyFritz has been cleared. Cause: 1
Lifetime expired
15.05.15 04:05:55 VPN connection to MyFritz was established successfully.
--------------

Dus ik heb m'n eerste verbinding opgezet om 04:05:55
De Fritz heeft hem onderbroken om 04:59:54 met Cause: 1 Lifetime expired

Maar 1 seconde later rapporteert de Fritz een nieuwe verbinding...

Aan mijn kant toont de network manager nog steeds het slotje voor VPN
maar verkeer is niet meer mogelijk.
Dan verbreek ik handmatig de VPN verbinding en om 05:03:57 rapporteert
de Fritz dat met Cause: 3 IKE server

Handmatig vraag ik een nieuwe VPN verbinding aan en de Fritz meldt dat
met 'established successfully'.

Dit kan ik elk uur herhalen.

Aan de ene kant zou de Fritz de verbinding niet na 54 minuten moeten
verbreken, aan de andere kant lijkt hij gelijk een nieuwe verbinding op
te zetten maar die laat volgens deze computer geen verkeer toe.

[Rob]

Dirk T. Verbeek <dver...@xs4all.nl> wrote:
> Op 14-05-15 om 17:43 schreef Rob:
>> Dirk T. Verbeek <dver...@xs4all.nl> wrote:
>>> By lack of a Linux compliant template on the AVM site I used one from a
>>> site called:
>>> "https://www.gadgetgoeroe.nl/handleidingen/fritzbox-vpn-installeren-en-mac-vpn-client/"
>>>
>>> ------------
>>> Op die 54 min. time out na werkt het prima.
>>>
>>> Nu kunnen ze gelijk even een officiele template op hun site zetten :)
>>
>> Ik zie daar dit in staan:
>>
>> mode = phase1_mode_aggressive;
>>
>> Dat is een slecht plan.
>> Ik weet niet wat precies de mogelijkheden bij de Fritbox zijn maar
>> maak daar eens van mode = phase1_mode_main;
>>
>> Nadeel is dan wel dat je op de remote moet matchen op het IP adres,
>> je kunt niet meer matchen op de "name". Maar de kans dat het fout
>> gaat op de manier die je beschrijft is wel kleiner.
>>
> Dank je voor het meedenken.
>
> Ik heb er niet veel verstand van maar begrijp ik het goed dat ik na deze
> aanpassing op de remote een "name" moeten vervangen door een IP?
>
> Ik ben veel op reis dus dat wordt geen vaste IP, die van thuis is
> uiteraard bekend.

In dat geval gaat dat niet werken. IPsec is dan niet echt een geschikt
protocol. Je kunt dan beter OpenVPN of OpenConnect ofzo gebruiken.

De Fritzbox is daar niet geschikt voor.

[robert]

Rob <nom...@example.com>:

Toch werkt het voor mij op die manier (connecten met mijn thuisnetwerk via
IPSec op de FB vanaf verschillende IP-nummers) probleemloos.

Config hier: https://gist.github.com/robertklep/c84b0e90c3952e2e524c

--
robert

[Friso]

Dirk T. Verbeek <dver...@xs4all.nl> wrote:

Wat moet ik aankaarten? Ik schrijf in de vorige post juist dat ik
geen probleem heb.

Het verschil lijkt te zijn dat mijn client zelf een nieuwe verbinding
maakt voor de lifetime verstreken is.

[Oscar]

In article <5553932c$0$2914$e4fe...@news.xs4all.nl>,

Friso <f...@xsFOURall.nl.invalid> wrote:
>> TL;DR, ik had een TCP-stream waarbij de Android client connect naar een
>> HTTP server op mijn thuisPC. Dit werkte telkens voor 54 minuten.
>Mooie set-up :). Maar de vraag is natuurlijk of het eindigen na 54
>minuten nou echt aan de Fritzbox + Android VPN verbinding ligt of dat
>een van de systemen of applicaties ertussen iets niet lekker doet.

Al googelend vond ik ook draadjes in het duits uit 2012 waar ook die 54
minuten genoemd werd. Ik denk niet dat het aan 1 van mijn applicaties
ligt. Ik heb het overigens met een Samsung Tab S 10.5 (Lolipop 5.0.2) en
een vrij oude Asus Transformer TF201 (4.nogwat.kanikwelopzoekenstraks)
geprobeerd. Androidversie *lijkt* dus niet veel uit te maken.

OS/X doet het blijkbaar wel goed. Waren er niet nog linux-clients die
hetzelfde probleem toonden?

>OT: Die WK-Snooker finale was wel wel legendarisch dit jaar!

Ik had nog even de hoop dat het richting een 17-17 zou gaan om het
helemaal spannend te maken, maar ben wel blij met deze uitkomt. ;-)

>De verbinding wordt altijd hersteld, verkeer of niet.

Ik heb inmiddels VPNCilla maar gekocht omdat het toch wel een lekkerdere
client is dan de default. Daar staat inderdaad een vinkje om automatisch
te herstellen. Ik denk dus dat hij dat toen ook wel deed, maar dat de
TCP-socket zelf toch stuk raakte en mijn client kan daar absoluut niet
mee overweg. Opnieuw connecten betekende kijken vanaf 0:00:00 en spoelen
ging niet of omslachtig.

Mogelijk dat die WebTV App een iets robustere afhandeling heeft van
verbrekende verbindingen. Van Spotify weet ik dat die het heel goed
doet. Maar die streamt ook niet echt, dat is denk ik meer een Just In
Time sync wat die doet. Dat kan wel tegen een stootje.

Ik ga dit nog een keertje testen als ik er tijd voor heb. Gewoon
telneten of netcatten naar iets dat iedere 10 seconden de tijd echo't of
zoiets en kijken of ie langer dan 54 minuten blijft leven.

>Ik vind het erg makkelijk. 3G gaat ook via VPN. Enige nadeel is dat je
>in je dataverbruik alleen nog maar 'VPNCilla' ziet en niet de apps die
>ervan gebruik maken.

Wat is jouw idee van de snelheid die je haalt? Ik heb het gevoel dat het
allemaal net wat meer latency heeft.

[Oscar]

In article <5553fd23$0$2859$e4fe...@news2.news.xs4all.nl>,

Dirk T. Verbeek <dver...@xs4all.nl> wrote:

>Op 13-05-15 om 20:08 schreef Friso:
>> Maar de vraag is natuurlijk of het eindigen na 54
>> minuten nou echt aan de Fritzbox + Android VPN verbinding ligt of dat
>> een van de systemen of applicaties ertussen iets niet lekker doet.
>
>Het gebeurt ook onder Kubuntu Linux en het zou mij verassen dat dat
>eenzelfde network stack of manager heeft.

Je weet dat Android op Linux gebouwd is he? Het zou mij niets verbazen.

>Dus doe nou hetzelfde, volg de link in de Fritz en kaart het aan.

Zeker! Maar iedere keer als ik thuis ben, vergeet ik het hele VPN
gebeuren en als ik elders ben, kan ik niet onderop mijn box kijken voor
het serienummer.

Mmm.. even een xmessage op mijn TV thuis zetten. Als reminder.. ;-)

[Dirk T. Verbeek]

Op 15-05-15 om 10:24 schreef robert:

Aha, en dat levert geen breuk op na 54 minuten?

Dan vanwege mijn onbekendheid nog een paar vragen;
Email adres als 'name', ik vermoed dat elke naam daar toepasbaar is?

user_fqdn = "...", ik neem aan dat daar een username in gaat en:
key = "..." dat daar een leuk password ingaat?

strongSwan is denk ik de Linux IPsec client?

[robert]

Dirk T. Verbeek <dver...@xs4all.nl>:

> Op 15-05-15 om 10:24 schreef robert:
>

>> Config hier: https://gist.github.com/robertklep/c84b0e90c3952e2e524c
>
> Aha, en dat levert geen breuk op na 54 minuten?

Nee, ik zie ook geen timeouts verschijnen in de FB logs. Ik zit nog wel op
FB firmware versie 06.05.

> Dan vanwege mijn onbekendheid nog een paar vragen;
> Email adres als 'name', ik vermoed dat elke naam daar toepasbaar is?

Ik vermoed het, ja. Ik heb die configfile jaren geleden een keer aangemaakt
op basis van de Windows-tool (wat destijds de enige 'simpele' manier was om
een VPN config aan te maken), wellicht dat toen werd aangeraden om er een
e-mail adres van te maken maar dat kan ik me niet herinneren.

> user_fqdn = "...", ik neem aan dat daar een username in gaat en:

Ik heb het even moeten nazoeken, want in mijn geëxporteerde config file is
dat veld versleuteld. Bij mij is de waarde daar hetzelfde als het "name"
veld.

> key = "..." dat daar een leuk password ingaat?

Correct.

Ik heb de gist even aangepast met de config file die ik ooit geïmporteerd
heb (en niet de geëxporteerde versie).

Zie https://gist.github.com/robertklep/c84b0e90c3952e2e524c#file-vpn2-cfg

> strongSwan is denk ik de Linux IPsec client?

Geen idee, ik ben een Mac-gebruiker ;) Ik gebruik IPSecuritas als client,
en dat gebruikt racoon onder de motorkap.

--
robert

[Dirk T. Verbeek]

Op 16-05-15 om 09:36 schreef robert:

Dank je, ik denk dat als ik weer thuis ben dit eens ga proberen.

[.: Hans :.]

On 7-5-2015 17:45, Joe wrote:
> Ik ben bezig VPN op te tuigen via de Fritz 7360 (XS4all). Dat lukt
> inmiddels vrij aardig maar ieder uur wordt de verbinding verbroken:
>
> 07.05.15 13:37:54 VPN connection to xxxxxxx has been cleared. Cause: 1
> Lifetime expired
>
> en dat ieder uur. Google meldt over dit probleem van alles inclusief
> dat het in Fritz OS 06.20 zou zijn opgelost maar die draai ik en het
> probleem blijkbaar NIET opgelost. Wie o wie geeft me wat tips. Is
> die lifetime ergens op "onbeperkt" te zetten?
>
> Hebben andere Fritzen (7390, 7490) dit probleem ook (nog)?
>

Wat er mis gaat is dat de ipsec SA (security association) lifetime
(phase 2) bij de meeste clients op 3600s (1uur) staat en bij de FB
kennelijk op 3240s (54min). Gevolg is dus een time-out.

Aanpassen in de FB gaat niet, dus de oplossing is om deze parameter in
de client korter dan 3240s te zetten. Ik heb het met de Shrewsoft client
onder Windows 7 getest (3000s) en het werkt.

Voor een beschrijving hoe e.e.a. precies zit zie o.a.:
http://forums.juniper.net/t5/SRX-Services-Gateway/IKE-life-time-VS-IPSEC-life-time/td-p/140937

http://www.vpncasestudy.com/sa.html

Of en hoe dit in andere clients ingesteld kan worden weet ik niet, maar
dat zal iedereen zelf wel kunnen vinden. (IpSec phase 2)

--
Hans

“Everybody is ignorant, only on different subjects."
Will Rogers, New York Times Aug. 31 1924

[Osiris]

Ben erg benieuwd of dit (mits aanpasbaar somehow in Android) het
probleem écht oplost.. Want je zou denken dat 't niet uitmaakt welke
kant van de verbinding als eerste de time-out 'haalt': het resultaat zou
hetzelfde moeten zijn, renegotiation van keys e.d.?

[Dirk T. Verbeek]

Op 16-05-15 om 16:00 schreef Osiris:

Dit zou er ook sterk op duiden at Android en Linux in elk geval dat
stukje code delen, ik had verwacht dat Google voor Android wel een eigen
network stack zou gebruiken.

De afgelopen twee dagen observeer ik in de Fritz dat de connectie
afgebroken wordt en vrijwel dezelfde seconde weer opgebouwd, althans,
dat is wat in de log van de FB staat:
------------------
16.05.15 18:11:48 VPN connection to Fritz was established successfully.
16.05.15 18:11:24 VPN connection to Fritz has been cleared. Cause: 3 IKE
server
16.05.15 18:08:14 VPN connection to Fritz was established successfully.
16.05.15 18:08:13 VPN connection to Fritz has been cleared. Cause: 1
Lifetime expired
16.05.15 17:14:14 VPN connection to Fritz was established successfully.
-------------------

M'n eerste connectie was dus om 17:14:14 en die viel om 18:08:013 weg.
1 seconde later om 18:06:14 was de verbinding volgens de Fritz weer gemaakt.

In die periode werd mijn Skype verbinding verbroken en kwam niet meer
terug, alle netwerkverbindingen waren nu onmogelijk totdat ik in de
Linux netwerkmanager de VPN verbinding handmatig verbrak wat door de
Fritz om 18:11:24 als Cause: 3 IKE server werd gelogd.

Daarna om 18:11:48 kon ik weer (handmatig) een nieuwe VPN verbinding
initiëren.

Met andere woorden, ja het lijkt erop de Fritz kan de verbinding
automatisch herstellen maar de Linux client neemt het niet over.
En gek genoeg blijft het VPN icoontje aan de Linux kant gewoon aanwezig,
alleen het wegvallen van de verbinding is een indicatie dat er wat fout
is. Als ik verder niks doe duurt het zo'n vijf minuten voordat aan de
Linux kant een popup komt met de mededeling dat de VPN verbinding is
weggevallen, waarmee een gewone (niet VPN) verbinding mogelijk wordt.

[Dirk T. Verbeek]

Op 16-05-15 om 16:00 schreef Osiris:

Ja dat had ik ook verwacht maar de Linux client ziet niet wat er aan de
Fritz kant gebeurt.

Ik heb dit (Hans z'n observaties) nu ook aangekaart op het Kubuntu forum
waar een echte security expert meeleest.

[NiElS]

On 16/05/15 09:36, robert wrote:
> Dirk T. Verbeek <dver...@xs4all.nl>:

>> strongSwan is denk ik de Linux IPsec client?
>
> Geen idee, ik ben een Mac-gebruiker ;) Ik gebruik IPSecuritas als client,
> en dat gebruikt racoon onder de motorkap.

strongSwan is er ook voor de Mac en voor Android, maar daar beperkt het
zich tot het IKEv2 protocol. Op Linux doet het zowel IPSec als IKEv2.

NiElS

[.: Hans :.]

Ik heb verder geen verstand van Linux, maar in de racoon.conf file kun
je deze time-out instellen.

voorbeeld:

sainfo anonymous address <RemoteTargetIP> any {
#pfs_group none;
lifetime time 3600 seconds; <======= verander in 3000 seconds
encryption_algorithm des;
authentication_algorithm hmac_sha1;
compression_algorithm deflate;

[Jerry]

On 07-05-15 17:45, Joe wrote:
> Ik ben bezig VPN op te tuigen via de Fritz 7360 (XS4all). Dat lukt
> inmiddels vrij aardig maar ieder uur wordt de verbinding verbroken:
>
> 07.05.15 13:37:54 VPN connection to xxxxxxx has been cleared. Cause: 1
> Lifetime expired
>
> en dat ieder uur. Google meldt over dit probleem van alles inclusief
> dat het in Fritz OS 06.20 zou zijn opgelost maar die draai ik en het
> probleem blijkbaar NIET opgelost. Wie o wie geeft me wat tips. Is
> die lifetime ergens op "onbeperkt" te zetten?
>
> Hebben andere Fritzen (7390, 7490) dit probleem ook (nog)?
>

Ik heb navraag gedaan bij AVM. Volgens mijn contactpersoon is er slechts
een complete supportcase terug te vinden. Helaas is het op basis van n=1
wat lastig om hier veel aandacht voor te krijgen.

Zouden jullie, voor zover nog niet gedaan, per een melding kunnen maken
bij AVM support. Voorzie de melding van zoveel mogelijk details (Modem
type, fw .06.20, client en OS, supportfile en eventueel traces)

Post je casenummer hier zodat we er wat aandacht voor kunnen vragen.

Tnx,

Jerry

[Osiris]

Ik heb hier sowieso maanden geleden al eens contact over gehad met AVM.
Alleen toentertijd had ik een F!B 7340, terwijl ik nu een F!B 7360 heb
staan.. Dus mijn reply n.a.v. deze thread richting AVM met "jullie zijn
stom en lezen m'n case niet eens goed" werd gepareerd met "Je device is
EOL sukkel, koop een fatsoenlijk modem die wél 6.20 draait (en nog wat
geneuzel over een veranderde lease-time blabla)".

Ik zal t.z.t. eventjes een nieuw ticket aanmaken ;)

[.: Hans :.]

Aangemeld en tevens mijn 'oplossing' met de kortere SA lifetime in de
client vermeld.

** Ticket-ID CID4173325 **

[Dirk T. Verbeek]

Op 19-05-15 om 12:38 schreef Jerry:

Ticket-ID CID4162985

Vannacht (mijn tijd) kreeg ik een reactie dat hoewel ze geen officiële
support kunnen geven op 3rd. party VPN applicaties ze graag wat meer
info willen.
Normaal leveren ze alleen support op hun eigen spullen, maw, een VPN
verbinding tussen twee Fritzen.

De verdere info zal ik proberen te geven en ook de observaties dat het
erop lijkt dat de Fritz wel een nieuwe lease opzet maar dat die niet
erkend wordt door Android en Linux.

[.: Hans :.]

On 19-5-2015 12:38, Jerry wrote:>

> Ik heb navraag gedaan bij AVM. Volgens mijn contactpersoon is er slechts
> een complete supportcase terug te vinden. Helaas is het op basis van n=1
> wat lastig om hier veel aandacht voor te krijgen.
>
> Zouden jullie, voor zover nog niet gedaan, per een melding kunnen maken
> bij AVM support. Voorzie de melding van zoveel mogelijk details (Modem
> type, fw .06.20, client en OS, supportfile en eventueel traces)
>
> Post je casenummer hier zodat we er wat aandacht voor kunnen vragen.
>
> Tnx,
>
> Jerry

Ik heb inmiddels enige malen antwoord gekregen van AVM. Helaas de
bekende riedel van eerst meer informatie vragen en dan het bekende
verhaal dat na een uur geen data de verbinding stopt.

> Thank you very much for the enquiry you submitted to AVM Support.
>
> At this stage we are unable to fully classify your reported issue.
> The cause of your reported issue is not known to us.
> In order to provide a solution for you, please provide the following
> information:

Alles netjes verteld en nogmaals uitgelegd met als resultaat.

> The message "VPN connection to [...] has been cleared. Cause: 1 Lifetime
> expired" is known here and we recommend these measures:
>
>
http://service.avm.de/support/en/SKB/FRITZ-Box-7360-int/202:Error-message-VPN-connection-to-has-been-cleared-Cause-in-the-event-log-of-the-FRITZ-Box

Ik vrees dat we hier niet veel van hoeven te verwachten.
Misschien kan Jerry ze nog eens aansporen?

[Dirk T. Verbeek]

Op 22-05-15 om 23:36 schreef .: Hans :.:

Ik hoop ze komende week de info te geven waarom ze gevraagd hebben.

[Osiris]

En wat als je *ALLEEN* terugstuurt dat er kneiterveel data over je VPN gaat?

[.: Hans :.]

N.a.v. hun laatste antwoord heb ik dat nogmaals gezegd. Hierop heb ik
nog geen reactie. Het lijkt er vooralsnog op dat ze niet goed lezen en
ook niet inhoudelijk reageren, maar nog in de ontkennende fase zitten.

PS: heb jij al een nieuwe case geopend?

[Rob]

.: Hans :. <hh....@xs4all.nederland.invalid> wrote:
> N.a.v. hun laatste antwoord heb ik dat nogmaals gezegd. Hierop heb ik
> nog geen reactie. Het lijkt er vooralsnog op dat ze niet goed lezen en
> ook niet inhoudelijk reageren, maar nog in de ontkennende fase zitten.

Het lijkt er op dat er een documentatiefout is en dat de 1e lijns
helpdesk de inkomende cases alleen afcheckt tegen de documentatie en
niet tegen de werkelijkheid. Iedereen krijgt het antwoord wat in de
documentatie staat, en dan valt het stil.

Je moet nu hopen dat als er heel veel van dit soort cases is, er nog een
keer iemand denkt "hee wellicht klopt het helemaal niet wat we al die
mensen vertellen". Dat gebeurt natuurlijk alleen als er een beperkt
aantal medewerkers daar op die helpdesk zit, en die zelf wel eens
nadenken. Dan moet je dus geluk hebben.

[A. Dumas]

Joe schreef op 07-05-15 om 17:45:

> Ik ben bezig VPN op te tuigen via de Fritz 7360 (XS4all). Dat lukt
> inmiddels vrij aardig maar ieder uur wordt de verbinding verbroken:
>

> 07.05.15 13:37:54 VPN connection to xxxxxxx has been cleared. Cause: 1
> Lifetime expired
>

> en dat ieder uur. Google meldt over dit probleem van alles inclusief
> dat het in Fritz OS 06.20 zou zijn opgelost maar die draai ik en het
> probleem blijkbaar NIET opgelost. Wie o wie geeft me wat tips. Is
> die lifetime ergens op "onbeperkt" te zetten?
>
> Hebben andere Fritzen (7390, 7490) dit probleem ook (nog)?

Geen probleem, of ongemerkt verbindingsherstel, met OS X 10.10 via UPC
naar Fritz 7360 met 6.20.

[robert]

A. Dumas <alex...@dumas.fr.invalid>:

> Geen probleem, of ongemerkt verbindingsherstel, met OS X 10.10 via UPC
> naar Fritz 7360 met 6.20.

Welke client gebruik je?

--
robert

[A. Dumas]

robert schreef op 28-05-15 om 17:11:

Geen aparte, de ingebouwde in Systeemvoorkeuren > Netwerk > toevoegen >
VPN, type "Cisco IPsec", etc.

[Dirk T. Verbeek]

Op 28-05-15 om 17:53 schreef A. Dumas:

Interessant.

Kijk eens in de logs van die Fritzbox, het elke 54 minuten afsluiten en
direct weer opnieuw opzetten van de verbinding hoort daarin te staan.
(System/Event Log)

[robert]

Dirk T. Verbeek <dver...@xs4all.nl>:

Dat gebeurt bij mij dus niet, met IPSecuritas als client (op de Mac). Daar
worden "lifetime expired" (o.i.d.) dingen gelogd.

--
robert

[A. Dumas]

Dirk T. Verbeek schreef op 28-05-15 om 18:06:

> Kijk eens in de logs van die Fritzbox, het elke 54 minuten afsluiten en
> direct weer opnieuw opzetten van de verbinding hoort daarin te staan.
> (System/Event Log)

Hm, kennelijk een paar uur terug een reboot geweest, er staat nu in elk
geval niets meer in de log van vóór de reconnect (reboot was toen ik
niet meer verbonden was).

[A. Dumas]

Dirk T. Verbeek schreef op 28-05-15 om 18:06:

Uurtje geleden nieuwe verbinding opgezet. Niks in de logs na 1:01:18. En
nu ga ik naar bed :)

[Siert Wolters]

A. Dumas schreef op 28-05-15 om 23:58 uur:

>
> Uurtje geleden nieuwe verbinding opgezet. Niks in de logs na 1:01:18. En
> nu ga ik naar bed :)

Truste ...

[Timo]

On 2015-05-16, .: Hans :. <hh....@xs4all.nederland.invalid> wrote:
> On 7-5-2015 17:45, Joe wrote:
>> Ik ben bezig VPN op te tuigen via de Fritz 7360 (XS4all). Dat lukt
>> inmiddels vrij aardig maar ieder uur wordt de verbinding verbroken:
>>
>> 07.05.15 13:37:54 VPN connection to xxxxxxx has been cleared. Cause: 1
>> Lifetime expired
>>
>> en dat ieder uur. Google meldt over dit probleem van alles inclusief
>> dat het in Fritz OS 06.20 zou zijn opgelost maar die draai ik en het
>> probleem blijkbaar NIET opgelost. Wie o wie geeft me wat tips. Is
>> die lifetime ergens op "onbeperkt" te zetten?
>>
>> Hebben andere Fritzen (7390, 7490) dit probleem ook (nog)?
>>
>
> Wat er mis gaat is dat de ipsec SA (security association) lifetime
> (phase 2) bij de meeste clients op 3600s (1uur) staat en bij de FB
> kennelijk op 3240s (54min). Gevolg is dus een time-out.

De FB hanteert een re-initialisatie op 90% van de lifetime. Veel VPN clients
ondersteunen re-initialisate vanaf de server kant niet, en dan gaat het dus
fout, en moet je de verbdinding vanuit de client oppnieuw opbouwen.

> Aanpassen in de FB gaat niet, dus de oplossing is om deze parameter in
> de client korter dan 3240s te zetten. Ik heb het met de Shrewsoft client
> onder Windows 7 getest (3000s) en het werkt.

Dat is inderdaad de beste oplossing om te voorkomen dat de server gaat
re-initialiseren voordat de client dat doet, ander alternatief is om de VPN
config op de FB aan te passen:

phase1ss = "LT8h/all/all/all"
phase2ss = "LT8h/esp-all-all/ah-none/comp-all/no-pfs"

Maar dat kan uiteraard niet in de GUI


--

Timo

[.: Hans :.]

Dat klinkt aannemelijk en ik geloof je op je woord. Maar ik neem aan dat
AVM dat ook weet en aangezien de meeste clients default op 1 uur staan
is het vragen om problemen als de FB ook op 1 uur staat. Android
bijvoorbeeld, niet de minst gebruikte, kan je als gebruiker niet
aanpassen. Jammer dat AVM dit hardnekkig blijft ontkennen.

Stukje uit hun laatste antwoord:
> After the initial investigation of your data, we unfortunately are not able
> to determine the cause for your reported issue. Therefore at this stage, we
> are unable to conclude whether the cause can be solved on behalf of our
> support. If, for instance, external factors as the cause must be taken into
> consideration, a solution on our side may not be possible.

In de config file die het AVM programma genereert staat geen lifetime.
Dus de default van 1h.

phase1ss = "all/all/all";
phase2ss = "esp-all-all/ah-none/comp-all/pfs";

Ik gebruik dat niet, want ik gebruik de Android config ook voor Windows.

Maar eens kijken hoe ik die configuratie op de FB kan aanpassen.

[Osiris]

Het 't nu met `nvi /var/flash/vpn.cfg` aangepast via telnet, hopelijk is
dat afdoende :o

[.: Hans :.]

Werkt dat bij jou? Ik kan geen verbinding meer maken met deze instelling
(alleen phase2 aangepast) vanaf Android.

Ik lees op onderstaande Blog dat AVM hier ook nog volop mee aan het
martelen is. FritzOS 6.23

http://blog.webernetz.net/2015/03/11/fritzos-ab-06-23-ipsec-p2-proposals-erweitert/

[Osiris]

Hm, nee, heeft *uiteindelijk* toch niet gewerkt. De eerste Always-On
VPN-sessie duurde gek genoeg exact 1 uur en 45 minuten (op de seconde)
en alle volgende sessies (reconnect van Android na enkele minuten nadat
de F!B de alom bekende foutmelding gaf in de logs) weer de welbekende 54
minuten.. Alsof íets "gereset" is..

[.: Hans :.]

Nogmaals geprobeerd en nu al 3:10 uuur verbinding.

[Dirk T. Verbeek]

Op 03-06-15 om 12:32 schreef .: Hans :.:

Klinkt al een stuk beter!

[.: Hans :.]

Ja, ik heb de verbinding uiteindelijk zelf na 4:20 uur gestopt. Nu ook
al weer ruim 3 uur bezig zonder noemenswaardig verkeer. De telefoon
staat alleen aan met de VPN open. Het lijkt dus te werken.

[Dirk T. Verbeek]

Op 03-06-15 om 21:42 schreef .: Hans :.:

Hmmm, morgen maar eens #96*7* bellen :)

[Osiris]

Ja, hier werkt het nu ook! :D Ik had tóch eventjes 't modem moeten
resetten.. Werd alleen verward doordat die éérste sessie eergisteren wél
langer duurde dan 54 minuten..

Na de reboot bleef vpn.cfg gewoon de wijzigingen houden en nu is m'n
meest recente sessie 9 uur en 19 minuten zonder enige problemen up.. :)

*BLIJ* :D Timo, je bent een held! W.m.b. verdien je een biertje :P

[Dirk T. Verbeek]

Op 04-06-15 om 21:07 schreef Osiris:

Appeltaart :)

Ik heb hem een kwartiertje geleden aangepast en met de berichten hier
heb ik goede moed dat de verbinding ook op Linux langer dan 54 minuten
zal leven.

Afgelopen weekend was ik even in een land waar b.v. Skype en VOIP
afgesloten zijn, dan is zo'n VPN toch wel erg fijn!

[.: Hans :.]

De verbinding is exact 8 uur open gebleven.

04.06.15 02:37:39 VPN connection to MyPhone has been cleared. Cause: 1
Lifetime expired
03.06.15 18:37:40 VPN connection to MyPhone was established successfully.

Voor mij is dat lang genoeg, bovendien kan ik bij een windows client de
lifetime ook nog aanpassen. Dus probleem opgelost.

[Osiris]

Welke client en versie is dat?

M'n Android 4.2.2's VPN is ondertussen alweer 10 uur en 35 minuten up :P

Als de client de rekeying niet voor z'n rekening neemt, dán loop je
natuurlijk uiteindelijk alsnog tegen de Fritz!Box z'n limiet aan..

[.: Hans :.]

Dat is ook Android 4.2.2

[Dirk T. Verbeek]

Op 04-06-15 om 21:07 schreef Osiris:

Gisterenavond heb ik de laptop en VPN na drie uur uitgezet, dat ziet er
heeeel goed uit!

Een klein minpuntje, doordat ik vergeten was dat een bepaalde
installatie de VPN secrets nog niet kende dacht ik een probleem met de
aanpassingen in vpn.cfg te hebben en zette de oude waarden terug.

Ik moest in totaal dus drie keer de FB resetten en alleen de eerste keer
werkte het reboot commando, de laatste twee keer moest ik de stekker er
even uittrekken.

Pas dus op met onderhoud op afstand!

[.: Hans :.]

On 2-6-2015 14:58, Timo wrote:

Ik heb inmiddels een antwoord van AVM ontvangen waarin ze exact deze
uitleg geven. Kennelijk lezen ze hier mee.

Ze zeggen verder o.a. ook:
> The VPN client of Android does only allow a manual re-establishing of the
> connection/lifetime.
> AVM will offer an Android VPN app in the future which will keep the VPN
> connection alive automatically via the automatic SA negotiation as
> described above.

Android kan dus nooit langer dan 8 uur in leven blijven. Dat was ook
mijn bevinding.

[Osiris]

Mijn "Always-On VPN" in Android 4.2.2 anders toch echt wel :) Die doet
blijkbaar wel rekeying vanuit de client.

Heb het nog niet geprobeerd via een "handmatige" VPN-verbinding. Zal die
vanavond eens aanzetten i.p.v. de "Always-on"-feature als ik ga tukken..
En kijken of 'ie morgenochtend nog aan is.

[Osiris]

23:35 aangezet en om 08:52 knalde 'ie er uit met "Cause: 12 SA loss"
omdat m'n complete internetverbinding foetsie was.. :P (Tegelijkertijd
de melding "Internet connection cleared". Met de vriendelijke groet van
XS4ALL of KPN gok ik ;)

Maar dus sowieso langer up dan 8 uur met de standaard build-in VPN-client.

[.: Hans :.]

Ik heb toen de lifetime nog op 1 uur stond ook wel eens langer gehaald.
wat Android precies doet weet ik niet. AVM zegt in mijn beleving dat het
niet zou werken, maar ze zeggen wel meer.

Hoe dan ook is 8 uur voor mij al meer dan genoeg. Met windows kan ik de
client aanpassen en is er al helemaal geen probleem.

--
Hans

[Joe]

On Fri, 15 May 2015 05:19:05 +0200, "Dirk T. Verbeek"
<dver...@xs4all.nl> wrote:

>Op 14-05-15 om 16:41 schreef Dirk T. Verbeek:
>
>Nog wat info uit de Fritz:
>---------------
>15.05.15 05:04:54 VPN connection to MyFritz was established successfully.
>15.05.15 05:03:57 VPN connection to MyFritz has been cleared. Cause: 3
>IKE server
>15.05.15 04:59:55 VPN connection to MyFritz was established successfully.
>15.05.15 04:59:54 VPN connection to MyFritz has been cleared. Cause: 1
>Lifetime expired
>15.05.15 04:05:55 VPN connection to MyFritz was established successfully.
>--------------
>
>Dus ik heb m'n eerste verbinding opgezet om 04:05:55
>De Fritz heeft hem onderbroken om 04:59:54 met Cause: 1 Lifetime expired
>
>Maar 1 seconde later rapporteert de Fritz een nieuwe verbinding...
>
>Aan mijn kant toont de network manager nog steeds het slotje voor VPN
>maar verkeer is niet meer mogelijk.
>Dan verbreek ik handmatig de VPN verbinding en om 05:03:57 rapporteert
>de Fritz dat met Cause: 3 IKE server
>
>Handmatig vraag ik een nieuwe VPN verbinding aan en de Fritz meldt dat
>met 'established successfully'.
>
>Dit kan ik elk uur herhalen.
>
>Aan de ene kant zou de Fritz de verbinding niet na 54 minuten moeten
>verbreken, aan de andere kant lijkt hij gelijk een nieuwe verbinding op
>te zetten maar die laat volgens deze computer geen verkeer toe.

Zelde situatie doet zich hier voor. Zat in buitenland heb er verder
niks mee kunnen doen omdat medebewonder al bijna meteen het netwerk
(bekabeling) verkloot had en VPN naar de interne machine niet meer
mogelijk was. Deze week ook maar eens een ticket aanmaken denk ik.

[Joe]

On 02 Jun 2015 12:58:00 GMT, Timo <ti...@xs4all.nl> wrote:

>Dat is inderdaad de beste oplossing om te voorkomen dat de server gaat
>re-initialiseren voordat de client dat doet, ander alternatief is om de VPN
>config op de FB aan te passen:
>
>phase1ss = "LT8h/all/all/all"
>phase2ss = "LT8h/esp-all-all/ah-none/comp-all/no-pfs"
>
>Maar dat kan uiteraard niet in de GUI

Goeie tip! Wijziging aangebracht, Fritz opnieuw gestart en deze week
(dinsdag of woensdag) eens testen of dit werkt. En als dit werkt zou
het voor AVM makkelijk moeten zijn om ofwel de leasetijd standaard te
verlengen ofwel om dit een instelbaar veld in het VPN menu te maken...

[Oscar]

In article <556da858$0$2854$e4fe...@news2.news.xs4all.nl>,

Timo <ti...@xs4all.nl> wrote:
>Dat is inderdaad de beste oplossing om te voorkomen dat de server gaat
>re-initialiseren voordat de client dat doet, ander alternatief is om de VPN
>config op de FB aan te passen:
>
>phase1ss = "LT8h/all/all/all"
>phase2ss = "LT8h/esp-all-all/ah-none/comp-all/no-pfs"
>
>Maar dat kan uiteraard niet in de GUI

Ehm, ik voel me even heel dom, maar waar dan wel? Moet ik dan zo'n
geheime "void your warranty" code bellen om telnet te enabelen of kan ik
de config downloaden, editten en weer uploaden?

--
[J|O|R] <- .signature.gz

[Osiris]

- Telnet aanzetten;
- `nvi /var/flash/vpn.cfg`
- Bovengenoemde variabelen aanpassen bij de gewenste gebruiker(s);
- als je vim niet kent: door de 'i' in te drukken kom je in
'insert'-mode en kun je dingen aanpassen. Daarna op escape drukken en
':wq' typen (zonder de '' uiteraard) om vim af te sluiten;
- Je F!B rebooten;
- Enjoy.

[Oscar]

In article <55753e05$0$2952$e4fe...@news.xs4all.nl>,

Osiris <osiris@invalid> wrote:
>- Telnet aanzetten;
>- `nvi /var/flash/vpn.cfg`

Thanks, dit zocht ik. Gewoon 'vi' werkt niet omdat die cfg een of andere
character device blijkt te zijn. 'nvi' is zo te zien een wrapper die de
boel even heen en weer cat.

>- Bovengenoemde variabelen aanpassen bij de gewenste gebruiker(s);
> - als je vim niet kent: door de 'i' in te drukken kom je in
>'insert'-mode en kun je dingen aanpassen. Daarna op escape drukken en
>':wq' typen (zonder de '' uiteraard) om vim af te sluiten;

Omslachtig hoor. Ik doe gewoon "ZZ". Werkt ook in deze vi. ;-)


>- Enjoy.

Dat gaat wel lukken als ik de commentaren zo lees. Dank allen!

[Dirk T. Verbeek]

Op 08-06-15 om 09:23 schreef Oscar:

't is misschien wat lastiger voor emacs gebruikers :)

[Osiris]

On 08-06-15 09:23, Oscar wrote:
> In article <55753e05$0$2952$e4fe...@news.xs4all.nl>,
> Osiris <osiris@invalid> wrote:
>
>> - Bovengenoemde variabelen aanpassen bij de gewenste gebruiker(s);
>> - als je vim niet kent: door de 'i' in te drukken kom je in
>> 'insert'-mode en kun je dingen aanpassen. Daarna op escape drukken en
>> ':wq' typen (zonder de '' uiteraard) om vim af te sluiten;
>
> Omslachtig hoor. Ik doe gewoon "ZZ". Werkt ook in deze vi. ;-)

Meh, ik typ liever dingen waarvan ik kan 'controleren' wat ze doen dan
obscure snelkoppelingen gebruiken die niet voor echt veel tijdswinst
zorgen :P

(That said, ik kende 'em nog niet :+)