Core-Update 200 Development Build: master/ed3faee6
I upgraded to this last night, all was working fine. Tried to access my server and the port forwarding as stopped working.
Hallo @scuz
Welcome to the IPFire community.
I have a vm IPFire network with green, blue and orange networks and vm systems on each of those subnets.
I have a test web server set up on the orange network, which I used to test out access from the blue network from an issue reported in the forum a year or so ago.
I created a clone of the vm IPFire and added a port forward rule to allow access to the orange server from the red network of the vm IPFire. Confirmed that everything worked as expected with CU199 and I was able to access the index.html on the server via https from a machine on the red network of the vm IPFire. Disabling the port forward firewall rule disabled access to the server.
I then updated the vm IPFire from CU199 to CU200 master/ed3faee6. Rebooted the vm IPFire and then tried to access the web server again. The connection was successfully made to the web server. Disabled the firewall rule and acess was again blocked and then re-enabled the firewall rule and access was again available.
I have not been able to reproduce the effect described by you.
After doing the update from CU199 to CU200 did you reboot your IPFire?
1 Like
Hello!
Thanks for your descriptive test that you did on your system. I did reboot after the upgrade and it was still not working fine. It’s a weird one, It was working before I left for work (I still run a BBS) and was checking on some other things. When I got to work, I tried to connect and it was not working. I also tried to remote into my VM server and DNS servers and I could not connect to anything. I may have jumped the gun in putting this in the forum. I will check the system after work and see what is going on. “Hopefully” it’s just a hardware problem.
-mitch
No problem with raising this in the forum.
My testing just showed that an update from CU199 to CU200 on its own was not enough to reproduce the effect.
That is always worth looking at as the reboot after a core update does tend to stress the hardware more than the ongoing activity.
If that all looks okay then you are going to have to debug along the chain of the web server access.
Look in the IPFire Firewall logs to see if you see the double rule of DNAT and FORWARDFW that would show that the port forwarding is occurring in your IPFire system. If you can’t find that then something is going wrong elsewhere in IPFire or the traffic is not getting to IPFire.
If the messages are in the logs then the traffic has been port forwarded to your server and you will need to look in the logs of the server to see if it sees anything.
On the Firewall Logs page you can press the Export button and it will put the whole of the selected days logs into a browser page and you can then search in there for the IP of your server to see if the Port Forward steps are occurring or not.
I just did a small edit on your post to make the whole quote one section.
All is well, I tracked it down to ports on my switch. I rebooted the switch and it worked for a while but noticed this morning that it was off again. I’m having a new one being delivered today. But when it was working, everything was working fine with no issues on the IPfire end.
2 Likes
Regarding the switch, I recently had an unmanaged switch start failing and I replaced it. But when I disassembled the switch, I found spider webs shorting various through hole leads on the bottom of the PCB. Webs themselves are not conductive, but they can hold enough moisture to create conductivity, which would then lead to electrical shorts and malfunctioning. It’s worth a look and may lead to you now having a working spare switch.
2 Likes
That is interesting. I will have to tear it down this weekend!