Session lost after refreshing - server switches between ip4 and ip6

[v.]

Hi,

I was wondering if anyone else is having this problem and knows a solution.

I have this on multiple hosting accounts: when I perform a hard reset of a page (ctrl+f5) the connection to the server may switch from ip4 to ip6 or the other way around.

This will cause my session variables to be lost. If it set up the DNS to only use ip4 or only ip6 the problem will not occur.

I am wondering if this is a php problem or an f3 problem. I have never seen this in a pure PHP site though. 

Why is this happening and how can I solve this without disabling ip4 or ip6?

v.

[PJH]

I'd expect any site seeing requests coming from different IP addresses (where it ties IP address to the session) to treat them as, well, different sessions.

I'd guess you'd need to something with the `onsuspect` event handler to not destroy the session if you're sure you don't want the session destroyed. See https://fatfreeframework.com/3.6/session

[ved]

Hi,

AFAIK, regular php sessions are IP agnostic, but the F3 session handlers take ip changes into account and mark the session as "suspicious" if it changes. The default is to reply with an http 403 - forbidden on these cases, unless you're using the onsuspect callback and override it as stated by @PJH

Also, your webserver is probably configured to serve on both ipv4 and ipv6 interfaces so if you make your webserver only serve requests on one of them that shouldn't happen (i think)

Not really sure if there's other ways to fix it without disabling listening on one of those interfaces but maybe somebody else will chip in with some more hints.

Good luck

[PJH]

> AFAIK, regular php sessions are IP agnostic,

It's simply a cookie passed between client and server.

Duplicating that cookie to another client with a different IP address would 'fool' a server to believe it's the same client.

F3, by default, discards those coming from anything appearing to be a different client than the original; the heuristics being the IP address and the User Agent.

The problem here appears to be the client being multi-homed, thus coming from different IP addresses.

The solution being either
1) stop the client doing that (not yet mentioned)
2) relax the heuristic on the server somehow (my previous post)
3) make IPv4/6 transition impossible (your suggestion)

None are entirely satisfactory, but security-wise the first is probably the best solution.

[v.]

Thanks for your answers PJH and ved.

I was wondering how you would be able to "stop the client doing that"? How is that even possible? AFAIK the webserver does not have any influence over the connection from the client to it, no?

As I stated in my original post, the easy solution would be to not publish AAAA records (or only them and no A records) but this is not officially  recommended I think.

Are there still clients not able to connect to ip6 nowadays? Are there any that have dropped ip4 already?

Maybe I am just overcomplicating :)

[PJH]

On Monday, May 6, 2019 at 8:19:43 PM UTC+1, v. wrote:

I was wondering how you would be able to "stop the client doing that"? How is that even possible?

Disable ipv4 or ipv6 on the client.

Or have a read up on Happy Eyeballs to better understand what's going on and fix whatever is making it, er, unhappy:

- https://en.m.wikipedia.org/wiki/Happy_Eyeballs

- https://tools.ietf.org/html/rfc8305

Either way, this is really a client problem and should really be dealt with there - since most clients won't actually see the problem to begin with.

[v.]

Hi PJH,

You say "disable ip4/6 on the client", but you can not do that from the server, or am I not understanding you?

How is this a client problem? Every client has the same issue...

Peter

[PJH]

On Tuesday, May 7, 2019 at 2:41:27 PM UTC+1, v. wrote:

Hi PJH,

You say "disable ip4/6 on the client", but you can not do that from the server, or am I not understanding you?

You appear to be misunderstanding me.

This isn't a server problem - it's a client problem.

The client should be re-using the same communications channel (IP address) for each request to the server. Not changing it between refreshes of the same page.

Yours isn't for some reason.

 

How is this a client problem? Every client has the same issue...

I'm sure the ipv4-only and ipv6-only clients don't.

Did you bother reading the Happy Eyeballs documentation?

 

[v.]

To be clear, it happens after a hard page refresh.

I also have it on this website: https://www.whatismyip.com/ip-address-lookup/

This will return either ip4 or ip6. After a standard refresh it will give the same result, after a ctrl+f5 refresh it may change from ip4 to ip6 or the other way around.

I am pretty sure it is not just my PC

[ved]

Hey,

I'll be honest, I have pretty much zero experience running ipv6 enabled services and usually always disable ipv6 on my computers and servers.

But browsers apparently implement the Happy Eyeballs algorithm as hinted by @PJH in order to pick which stack it will use. The tl;dr is that it basically uses whichever connection is faster/replies first.

And since a hard refresh is pretty much the same as if you were accessing the website directly (and for the first time) it will then switch between those depending on network conditions and (i assume) some other parameters.

If you go into your website, and navigate around without doing a hard refresh that shouldn't happen, correct? I'm guessing browsers are smart enough to make the current browser session sticky to the initial ip version it chose.

So I'm guessing there's really no issue here and it's just the way things work when running both versions.

Also I'm pretty sure it's not just your setup and any systems with both v4 and v6 configured will probably behave in mostly the same way.

If your only problem with this setup is with losing the sessions on your app and you want to keep both ip versions on your system then I'd suggest that you just disable F3's suspect sessions which is what's probably getting triggered on this case.

Good luck.

[v.]

Hi Ved,

I have seen it happen after a regular pageload, although that happens rarely.

I guess there is not much to do except disabling the AAAA records. I may go that way,

Thanks for your always much appreciated help