Update to core 185 no access to Ipfire

1

Hi all,
Update from core 184 to core 185 problem. No WUI or SSH access.
Update hangs, have left for hours (previous updates have hung, but after a reboot all was well)
Boot messages all look normal. I can ping the machine, and the network seems to be working fine. I can access WUI and SSH from openVPN.
Just no LAN access.

I have tried different browsers, clearing cache, reverted to core 184 and set SSH to port 22 with password authentification; tried cli update same results; logged in via console, restarted apache, ssh, still no joy.

Pakfire log ends with:
Generating grub configuration file …
Found background: /boot/grub/splash.png
Found linux image: /boot/vmlinuz-6.6.15-ipfire
Found initrd image: /boot/initramfs-6.6.15-ipfire.img
Adding boot menu entry for UEFI Firmware Settings …
done

Any ideas on how to proceed?

2

This indicates that the upgrade successfully completed.

The most likely thing is that the apache server was not successfully restarted as per this thread.

https://community.ipfire.org/t/core-185-killed-my-ipfire-again/11523

When this freeze happens what response do you get when you run the command for the status of the apache server.

/etc/rc.d/init.d/apache status

1 Like
3

This is stange. If the WUI is accessible via OpenVPN Apache is running and it should also be via LAN. Any clues in /var/log/messages or suricata alerts?

1 Like
4

Thanks for the input.

Apache was running fine
/etc/init.d/apache status
httpd is running with Process ID(s) 7505

Thanks for the direction; /var/log/messages contained drops from the LAN computer
May 20 18:14:45 jafx kernel: DROP_NEWNOTSYN IN=green0 OUT= MAC=02 SRC=172.25.25.100 DST=172.25.25.20 LEN=532 TOS=0x00 PREC=0x00 TTL=64 ID=29384 DF PROTO=TCP SPT=60706 DPT=444 WINDOW=501 RES=0x00 ACK PSH URGP=0
May 20 18:14:45 jafx kernel: DROP_NEWNOTSYN IN=green0 OUT= MAC=02 SRC=172.25.25.100 DST=172.25.25.20 LEN=532 TOS=0x00 PREC=0x00 TTL=64 ID=22863 DF PROTO=TCP SPT=48568 DPT=444 WINDOW=501 RES=0x00 ACK PSH URGP=0

Testing from openVPN the firewall logs did not show anything being blocked from the LAN computer.
Adding firewall rules to specifically allow the traffic did not work.

Solved the issue by removing my custom /etc/sysconfig/firewall.local rules.
I had created rules to prevent some IoT devices from circumventing the IPFire DNS. These rules worked fine before. But, evidentally something changed.

So the no access issue is solved, however, I would love to hear how to properly redirect these misbehaving IoT devices in such a way as they believe they are reaching 8.8.8.8, but are actually going through proper DNS.

Thank you very much for your attention. Great people here.

5

Give us a clue. What were your local rules?

6

Hi Nick,

Sorry for the non-specific details on that question. Was thinking that might be better served as it’s own topic.

The firewall.local rules are based on: Forcing all DNS traffic from the LAN to the firewall - #45 by jon
and are:
iptables -t nat -A CUSTOMPREROUTING -i green0 -d 172.25.25.20 -p udp -m udp --dport 53 -j RETURN
iptables -t nat -A CUSTOMPREROUTING -i green0 -d 172.25.25.20 -p tcp -m tcp --dport 53 -j RETURN
iptables -t nat -A CUSTOMPREROUTING -i green0 -d 172.25.25.20 -p tcp -m tcp --dport 853 -j RETURN
iptables -t nat -A CUSTOMPREROUTING -i green0 -p udp -m udp --dport 53 -m limit --limit 10/sec --limit-burst 20 -j LOG --log-prefix "DNSREDIRECT "
iptables -t nat -A CUSTOMPREROUTING -i green0 -p udp -m udp --dport 53 -j REDIRECT --to-ports 53
iptables -t nat -A CUSTOMPREROUTING -i green0 -p tcp -m tcp --dport 53 -m limit --limit 10/sec --limit-burst 20 -j LOG --log-prefix "DNSREDIRECT "
iptables -t nat -A CUSTOMPREROUTING -i green0 -p tcp -m tcp --dport 53 -j REDIRECT --to-ports 53
iptables -t nat -A CUSTOMPREROUTING -i green0 -p tcp -m tcp --dport 853 -m limit --limit 10/sec --limit-burst 20 -j LOG --log-prefix "DNSREDIRECT "
iptables -t nat -A CUSTOMPREROUTING -i green0 -p tcp -m tcp --dport 853 -j REDIRECT --to-ports 853
iptables -t nat -A CUSTOMPREROUTING -i blue0 -d 172.25.30.10 -p tcp -m tcp --dport 53 -j RETURN
iptables -t nat -A CUSTOMPREROUTING -i blue0 -d 172.25.30.10 -p udp -m udp --dport 53 -j RETURN
iptables -t nat -A CUSTOMPREROUTING -i blue0 -d 172.25.30.10 -p tcp -m tcp --dport 853 -j RETURN
iptables -t nat -A CUSTOMPREROUTING -i blue0 -p udp -m udp --dport 53 -m limit --limit 10/sec --limit-burst 20 -j LOG --log-prefix "DNSREDIRECT "
iptables -t nat -A CUSTOMPREROUTING -i blue0 -p udp -m udp --dport 53 -j REDIRECT --to-ports 53
iptables -t nat -A CUSTOMPREROUTING -i blue0 -p tcp -m tcp --dport 53 -m limit --limit 10/sec --limit-burst 20 -j LOG --log-prefix "DNSREDIRECT "
iptables -t nat -A CUSTOMPREROUTING -i blue0 -p tcp -m tcp --dport 53 -j REDIRECT --to-ports 53
iptables -t nat -A CUSTOMPREROUTING -i blue0 -p tcp -m tcp --dport 853 -m limit --limit 10/sec --limit-burst 20 -j LOG --log-prefix "DNSREDIRECT "
iptables -t nat -A CUSTOMPREROUTING -i blue0 -p tcp -m tcp --dport 853 -j REDIRECT --to-ports 853

7

Redirecting DNS is in the wiki.
Not always easy to find.

1 Like
8

Hi Shaun,
I’m not sure how the link provided is relative. Maybe I’m missing something.

I researched “force clients to use ipfire dns” and ended back up with the aforementioned Forcing all DNS traffic from the LAN to the firewall - #45 by jon.
I did run across this git.ipfire.org Git - ipfire-2.x.git/commit. But I do not know if this is included, or if it must be implemeted.
Thanks

9

It is implemented as per the wiki.
You can redirect DNS as the wiki describes.
No need to mess with command line text editors. Just use the WUI.

1 Like
10

Hi Shaun,

I implemented this years ago www.ipfire.org - Force clients to use IPFire DNS Server, however the IoT devices still showed connections to non-IPFire DNS servers. After the changes to firewall.local, these connections ceased.
I’ll have to revisit that.
Thank you.

11

As this seems to have skewed off topic (my bad), I’m marking this as solved.
The solution was to remove the custom rules in /etc/sysconfig/firewall.local

Thank you all!

1 Like