Request help isolating connection issue

EA’s new open beta desktop app

It has a connection issue with ipfire that I’m having trouble isolating. When I use it with the computer set up under DHCP, the friends window on the right has a “Connection Failed” message.

When I set up my connection under Windows 11 to manual and set the exact same IP and ipfire itself as the gateway and only DNS server manually, the app connects just fine.

Also, running the app through a VPN to bypass ipfire makes it work fine as well. I’ve duplicated the issue with a second PC running windows 10.

I’m not sure what else DHCP might be sending that could cause a connection issue but this is the only app that seems to have it. If I can find what the app has an issue with I might be able to submit a bug report to them.

I tried removing all additional DHCP options which just had wpad for proxy, and that didn’t work either.

This one is a little difficult to help. We really need more information.

Does this computer work A-OK otherwise?

What errors appear in the message log at less /var/log/messages?

What does the DHCP configuration WebGUI look like? (please send screen shot)

What does the Advanced web proxy configuration WebGUI look like? (please send screen shot)

is IPS enabled? any Firewall Rules enabled?

(sorry - lots of questions)

1 Like

Yes, everything else works fine.

No errors and nothing relevant shows up. Over the one minute I ran two tests, I see 4 DROP_INPUT from china being dropped, one from ireland. A DROP_NEWNOTSYN to a different client on the network. A few DHCPREQUEST and DHCPACK requests from different clients, nothing else. The Green IP I was testing from was .32 and there are no matching messages.

Jan  2 10:08:15 ipfire kernel: DROP_NEWNOTSYN IN=green0 OUT=red0 MAC=b8:ae:ed:79:62:4b:dc:54:d7:18:4f:3e:08:00 SRC=192.168.1.178 DST=35.164.126.203 LEN=83 TOS=0x00 PREC=0x00 TTL=63 ID=21266 DF PROTO=TCP SPT=48644 DPT=443 WINDOW=1595 RES=0x00 ACK PSH URGP=0
Jan  2 10:08:33 ipfire dhcpd: DHCPREQUEST for 192.168.1.4 from d8:0d:17:bf:21:db via green0
Jan  2 10:08:33 ipfire dhcpd: DHCPACK on 192.168.1.4 to d8:0d:17:bf:21:db via green0
Jan  2 10:08:34 ipfire kernel: DROP_INPUT IN=red0 OUT= MAC=00:0a:cd:2a:58:51:00:01:5c:71:40:46:08:00 SRC=183.220.145.200 DST=97.86.238.169 LEN=40 TOS=0x00 PREC=0x00 TTL=216 ID=21797 PROTO=TCP SPT=59584 DPT=2375 WINDOW=1024 RES=0x00 SYN URGP=0 MARK=0x80000000
Jan  2 10:08:35 ipfire kernel: DROP_INPUT IN=red0 OUT= MAC=00:0a:cd:2a:58:51:00:01:5c:71:40:46:08:00 SRC=183.220.145.200 DST=97.86.238.169 LEN=40 TOS=0x00 PREC=0x00 TTL=216 ID=60709 PROTO=TCP SPT=59584 DPT=2376 WINDOW=1024 RES=0x00 SYN URGP=0 MARK=0x80000000
Jan  2 10:08:36 ipfire kernel: DROP_INPUT IN=red0 OUT= MAC=00:0a:cd:2a:58:51:00:01:5c:71:40:46:08:00 SRC=159.65.206.119 DST=97.86.238.169 LEN=40 TOS=0x00 PREC=0x00 TTL=239 ID=32412 PROTO=TCP SPT=61953 DPT=8068 WINDOW=1024 RES=0x00 SYN URGP=0 MARK=0x80000000
Jan  2 10:08:38 ipfire dhcpd: DHCPREQUEST for 192.168.1.51 from 60:01:94:63:3c:3e via green0
Jan  2 10:08:38 ipfire dhcpd: DHCPACK on 192.168.1.51 to 60:01:94:63:3c:3e via green0
Jan  2 10:08:38 ipfire dhcpd: DHCPREQUEST for 192.168.1.87 from f8:54:b8:c5:6a:0c via green0
Jan  2 10:08:38 ipfire dhcpd: DHCPACK on 192.168.1.87 to f8:54:b8:c5:6a:0c via green0
Jan  2 10:08:40 ipfire kernel: DROP_INPUT IN=red0 OUT= MAC=00:0a:cd:2a:58:51:00:01:5c:71:40:46:08:00 SRC=183.220.145.200 DST=97.86.238.169 LEN=40 TOS=0x00 PREC=0x00 TTL=216 ID=45920 PROTO=TCP SPT=59584 DPT=6379 WINDOW=1024 RES=0x00 SYN URGP=0 MARK=0x80000000
Jan  2 10:08:42 ipfire kernel: DROP_INPUT IN=red0 OUT= MAC=00:0a:cd:2a:58:51:00:01:5c:71:40:46:08:00 SRC=183.220.145.200 DST=97.86.238.169 LEN=40 TOS=0x00 PREC=0x00 TTL=216 ID=51157 PROTO=TCP SPT=59584 DPT=5432 WINDOW=1024 RES=0x00 SYN URGP=0 MARK=0x80000000
Jan  2 10:08:57 ipfire dhcpd: DHCPREQUEST for 192.168.1.5 from 00:11:32:a8:96:fc via green0
Jan  2 10:08:57 ipfire dhcpd: DHCPACK on 192.168.1.5 to 00:11:32:a8:96:fc via green0

IPS is enabled. I checked the logs and no hits correspond to the time I’ve been testing. I tried turning it off and it still won’t connect. I have a load of port forwarding firewall rules but tried disabling them all. hitting apply, and it still wouldn’t connect.

shrug I sent a bug report to EA with what little I had. The Origin desktop app, which this is supposed to replace, doesn’t have this issue.

Hey James - sorry for late response. I don’t have any answers for you. All looks OK on the IPFire side.

If you have temporarily disabled IPS, Firewall Rules (and one more: Fast Flux), and there is nothing in the message logs, AND it still doesn’t work, than I am out of suggestions.

Sorry to say but EA sounds like your best bet!

Maybe someone else can add their thoughts?!?

If I understand you correctly above?
This smells to me like the way that window is coded to connect/resolve DNS might be different than the main page. Just for the heck of it you might try adding a public DNS server address as Secondary DNS and try again. (also sometimes I have found that making changes in the GUI don’t always apply until the system has rebooted) but maybe that’s just me lol.

It only doesn’t work when I use DHCP. When I manually configure the IP with IP Fire as the primary DNS with no secondary, it works fine.

:thinking: I wonder for what purpose you have the following option enabled?

What “Additional DHCP options” are you using?

1 Like

I was using two wpad options for proxy Auto detection (code 252=text, url to proxy.pac) but deleted them while troubleshooting this issue to rule them out and found that it still wasn’t working, even after a reboot. I added them back later.