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.
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.
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.
I am being honest, I have no reason to lie.
But thank you for your feedback.
It was just an expression, poorly chosen words, didn't mean to imply you weren't being honest.
I do not use PPoE on WAN links. Case ID # 05443334 created.
Thank you for the Case ID, I have left a note in your case.