Bizarre, very specific multiplayer problems with Elden Ring

Howdy! Using IPFire 166, Elden Ring for PS5 1.03.2. (Also tested on IPFire 164)

Elden Ring is currently a massively popular online game so I’m hoping there are some fans here whose wisdom I might draw upon. My symptoms are that I can connect to the online services of the game and I can see the messages, blood splatters, and “ghosts” of other players. However, I cannot enable any of the “co-op” multiplayer functions (either friendly or competitive). I do not get an error, but the features never work. For example, if I try to invade, I simply get the “Attempting to invade another player” message ad infinitum. I have been on voice chats where the friend I was attempting to play co-op with was instantly able to connect to another friend, so the problem seems to be on my side (since I cannot enter friendly co-op or competitive multiplayer).

To bring it back to IPFire, I am wondering if it is possible I get some of the multiplayer features because they come from a central server, and do not get the other features because it tries to broker some kind of peer-to-peer connection that is blocked by IPFire? Is that possible? How could I diagnose what is happening and potentially come up with a solution?

I am also running a Pihole for DNS. To take that out of the equation I have the PS5 going through Google and Cloudflare for DNS resolution.

(Note that multiplayer in Elden Ring is bizarre and has many conditions on working properly to begin with. Hopefully you can take my word that everything to do with in-game settings have been exhaustively tried. That said, I am open to trying in-game settings changes.)

I know this is a goofy one, thanks in advance for any help.



I would, start the game up until problem arise. Note time on pc clock.
Open ipfire wui, verify logs for ips & kernel using time problem arise.
If none are found, check log.message as root.
If a log is found, check what rule triggered the block.
Search for info on the rule … if it is a default rule, i would not remove onless properly searched and understand why.


Thank you! I appreciate this advice. I’ll check it out and see what I can discover.

Interesting results. Here’s what I found:

17:25:23, DROP_CTINVALID, green0, TCP, x.x.x.249->, 56997->443(HTTPS)
17:25:23, DROP_CTINVALID, green0, TCP, x.x.x.249->, 53671->443(HTTPS)
17:25:25, DROP_CTINVALID, green0, TCP, x.x.x.249->, 56144->10901
17:25:26, DROP_CTINVALID, green0, TCP, x.x.x.249->, 56706->443(HTTPS)
17:25:26, DROP_CTINVALID, green0, TCP, x.x.x.249->, 60136->443(HTTPS)

Where x.x.x.249 is the private IP address of the PS5 on the internal (green) network. A google search led me to this IPFire forum post: 2.27 cu 164 Testing release - Hostile & CTInvalid logging - #6 by pmueller@pmueller, I don’t mean to impose and without asking you to solve my problem, do you think this fits the symptoms of the same problem? Most of the destination IPs are Akamai, and in your comment you mention:

a decent amount of them are FIN-ACKs sent very late by the peer (especially observed in conjunction with Cloudflare and Akamai - perhaps they run their own customised network stack?).

I don’t want to bang my head against the wall if this is a known issue; that said in the meantime I’ll see if there are any rules I can (and want to) change to hopefully fix this issue. Thanks for the help so far! I really appreciate it and it is getting me much more familiar with IPFire’s interface (which I pretty much love so far).


Ligit sites …

Agreed, then i would update to 167 testing. There is a kernel update … problem could be related to kernel bug. ( read the post about back-up before update )

If you want to dig a bit deeper, on consol verify /var/log/messages going backword from

check for: nf_conntrack table full dropping packet entry ( wording could be in a different order like drop table full nf_conntract

If you do find such entry, type : cat /proc/sys/net/nf_conntrack_max
Report output

1 Like

check for: nf_conntrack table full dropping packet entry ( wording could be in a different order like drop table full nf_conntract

I could not find anything like this phrasing in /var/log/messages. Just to be on the safe side I also ran zgrep "nf_conntrack" messages.*, no hits. I did find a ton of additional DROP_CTINVALID going from green source to red destination. Occasionally these are paired with DROP_NEWNOTSYN to the same source+destination.

When I get a chance, I’ll upgrade to 167 testing and report back. Thanks for your help!

@crw - I see lots of the same messages.

You may want to temporarily disable the first two Firewall logging options until you are able to figure out the Elden Ring issues.

For the DROP_NEWNOTSYN messages, see Firewall Options - Log dropped new not SYN packet.

For DROP_CTINVALID see Firewall Options - Log dropped packets classified as INVALID by connection tracking

1 Like

I’ve upgraded to 167 and do not see any changes. Still getting a ton of DROP_CTINVALID messages in the logs.

@jon re:

You may want to temporarily disable the first two Firewall logging options until you are able to figure out the Elden Ring issues.

If you are suggesting the DROP_CTINVALID is unrelated to the issues with the game, I think you may be right. Using grep to slice the data, I can see the DROP_CTINVALID start as soon as the PS5 is turned on, and continue until it is turned off. Plenty of other internal IPs are seeing the same DROP_CTINVALID messages as well. They do not seem to be directly related to the time when I try to start multiplayer. If they are part of the problem, they are part of a bigger problem. If you exclude DROP_CTINVALID there are no log messages at all in the firewall logs with the PS5’s IP at the time I try to start multiplayer, so I am starting to think the problem is in the game software itself.

Thanks for all of the help so far! I appreciate it.

1 Like

Final update: multiplayer seems to be working. It often takes a long time to start but is working. Compared to others in my social network, my experience seems to be very slow / delayed versus the norm, but it does eventually work. I’m not sure if it was a series of transient issues or if the router upgrade helped with the issue, but for now we can consider this closed. Thanks for all of the help!

just curious - about how long does it take to work?

Sorry for the very late reply! I did more anecdotal testing - there is no noticeable delay at this point beyond the normal matchmaking. It is a little difficult to know if the upgrade to 167 made a difference, but in any case this issue is resolved now. Thanks for the help to all who responded!

1 Like