FWIW, "seems" is a comparatively hazardous choice when debugging networking access, and determining permissible access. Test your access, and definitely confirm what is permissible and not within your ISP terms of service, or check directly with your ISP and get some email on what is and is not allowed.
If it's permissible within your ISP service tier, probe the specific ports using telnet or the openssl s_client and (particularly for this case nc (netcat) tools, and see if the ports allow access. nc can run port probes on UDP, which is the key piece here given those other two tools target TCP and TCP SSL connections. Probably something like the nc -zu w.x.y.z udp-port command.
Or alternatively, reconfigure your firewall back to disallowing VPN passthrough, try the VPN, and see if you can provoke the firewall to log hits on the ports.
If you know that your SMTP port 25 is blocked (your phrasing around the cause of the problems isn't clear to me), then you're on some analog to a DHCP-based residential service tier, and those can have other port blocks.
If your mail is messed up and port 25 is not blocked, then it's likely your DNS that's messed up, as more than a few folks have tried setting up SMTP without having their forward and reverse DNS working for the IP address of their mail server. For SMTP to work, your forward DNS and your reverse DNS and your MX record must all match. If this is the usual setup, the dig -x w.x.y.z of your external IP address will not match, and that'll often cause remote SMTP servers to choose to avoid your server.