I just got my internal company's SMTP email flow working again. It has been stuck for several hours. I was able to start working on it late tonight. I identified that inbound SMTP packets (TCP port 25) and inbound HTTPS (TCP port 443) forwarded to our Exchange server were NOT making it through the firewall (Untangle NG 10.2).
After turning off all apps, cleaning up/removing some old disabled port forward rules that shouldn't have mattered anyway, reviewing the packet filter rules and inspecting my Port Forward rules multiple times, the result was the same.
Outside attempts to establish TCP sessions with these 2 ports/services on the Exchange server were being immediately reset by UT NG.
I opened wireshark on my laptop from home to watch what was happening on the wire when these sessions immediately failed. A TCP RST (Reset) flag was set in an immediate response from the firewall.
I googled & found this thread: http://forums.untangle.com/networkin...n-refused.html
It didn't seem like the right solution. He was getting the RST for a different reason.
As a last ditch effort, I opted to simply reboot UT NG via the web GUI. THIS FIXED EVERYTHING.
Other relevant details:
So why would rebooting have fixed this problem? Does anyone else out there see cases like this where you simply have to treat UT NG like an old PC and reboot it to get it running properly again?
After turning off all apps, cleaning up/removing some old disabled port forward rules that shouldn't have mattered anyway, reviewing the packet filter rules and inspecting my Port Forward rules multiple times, the result was the same.
Outside attempts to establish TCP sessions with these 2 ports/services on the Exchange server were being immediately reset by UT NG.
I opened wireshark on my laptop from home to watch what was happening on the wire when these sessions immediately failed. A TCP RST (Reset) flag was set in an immediate response from the firewall.
I googled & found this thread: http://forums.untangle.com/networkin...n-refused.html
It didn't seem like the right solution. He was getting the RST for a different reason.
As a last ditch effort, I opted to simply reboot UT NG via the web GUI. THIS FIXED EVERYTHING.
Other relevant details:
- OpenVPN server on UT NG was working just fine throughout the problem. I connected & disconnected & reconnected to OpenVPN several times from my laptop. This is how I was administering UT NG and troubleshooting the entire time (it was the only remote access I had into my network, since the port forward rules weren't working).
- The Exchange server had internet access throughout. I could get out to search engines and query new strings. The Exchange server does use UT NG as its default gateway.
- The UT NG hardware is running on a new SuperMicro 1U system we purchased & installed in the past 9 months.
So why would rebooting have fixed this problem? Does anyone else out there see cases like this where you simply have to treat UT NG like an old PC and reboot it to get it running properly again?