After updating from SFOS 18.5.3 MR-3-Build408 to SFOS 19.0.0 GA-Build317 I started getting complaints of services not working, they depend either on outbound firewall rules or inbound DNAT rules.
The first failure to be reported was VoIP, oddly enough running a VoIP client from my own machine would work just fine, but a specific VoIP gateway device which had it's own rule was not working at all after the upgrade.
Another example is an internal web server that only accepts connections from specific FQDN, also stopped being reachable from the outside after the upgrade.
I have seen people reporting other types of issues but none similar to this. And yes, regressing to SFOS 18.5.3 MR-3 fixed every issue both times that I tried the upgrade.
A couple concrete examples below of simple rules that stopped working after v19.0GA upgrade:
- Source zones: LAN
- Source network and devices: (IP for local VoIP gateway)
- Destination zones: WAN
- Destination networks: Any
- Services: SIP (UDP/1:65535 - UDP/5060)
Another FW rule, created with DNAT wizard:
- Source zones: WAN
- Source network and devices: FQDN (mydomain.com)
- Destination zones: LAN
- Destination networks: #Port2 (Public IP)
- Services: HTTPS
Resulting NAT rule from above:
- Original source: FQDN (mydomain.com)
- Original destination: #Port2 (Public IP)
- Original services: HTTPS
- SNAT: Original
- DNAT: (IP for LAN web server)
- PAT: Original
- Inbound interface: Port2 (Public IP)
- Outbound interface: Any
Thanks for the suggestion.
I do not have PPPoE on Port2, no, standard IP WAN.
I don't really know if there is any point in trying to troubleshoot this, simply because if I manually recreate the exact same…
Any update on this? I´m facing the same problem. Firewall rules do not match, VPN rules do not match... Sometimes if you recreate the rule it works, sometimes it does not. Sometimes the rule works, most of time it does not. Is this a known bug???
We have no internal reports of this in v19 or any case currently being worked by GES/DEV related to this, to make this a known issue, if you’re able to replicate it, please open a case with support and share the Case ID.
Might as well be honest, nobody cared enough. As for myself, as OP, I'm not a beta tester so in conclusion I take it that GES/DEV can't really be of help regardless, QA also on life support it seems.
Likely this is caused by a broken object. Do you had an support case?
No, I don´t. I will open one! Thanks.
I will open a support case. But righ now the portal is down for maintenance. As soon as I get a case ID i will post it here.
I do have a support case, but we ended up closing it (05261586) because I wasn't thrilled about the suggestion to spend hours on the phone trying to debug a non-issue in v18. If I was asked for some logs that they could analyze, that would've been fine, but by that point I had upgraded and reverted about 4 times, so I was quite frustrated with it all.
Once you have the Case ID please share it with me so I can follow up.
I would recommend you to follow the steps I provided in the post above as well.
Checking on your case I don't see any troubleshooting done, as you decided to close it after your own troubleshooting process, next time when you have a case open please share it, so I can leave a note on the case, for steps to follow.
I am being honest, I have no reason to lie.
But thank you for your feedback.