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???
Likely this is caused by a broken object. Do you had an support case?
No, I don´t. I will open one! Thanks.
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.
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.