Again, a basic diagram showing your network topology and what WAN / VPNs are involved would be useful for both sides of the SRT stream as this means we need to make some assumptions as to why things may be not working.
You could for instance have the SRT listener behind the HD4 in your studio, an HD2 at a remote site creating a VPN back to the studio and carry all your SRT inside that VPN.
Or you could be trying to make this work across the public internet with SFC used on the caller side only.
SRT is typically a point to point relationship between two devices, one is a listener and the other a caller.
The roles are arbitary, although common practice would be for the listener to be at the studio / MCR side of a link with a known IP and port waiting for an incoming connection, and the caller would be the device connecting into the studio which is configured to connct to the known IP and port.
The exception to this is SRT in rendezvous mode which can be used as a firewall / NAT traversial method where both sides will try and establish a connection and in most cases all you do is tell each side the others public IP and choose a port for them to try and connect via - personally I use this as a last resort and prefer explicitly configured IPs and ports as it makes faul tfinding much easier.
In the case of Haivision they also have some cloud based management services that can help negotiate these connections (we use Haivision Makitos, but without their hub service) although that is a very different topic.
Not necessarily, the term “DMZ” is horribly ambigious in a lot of instances - especially where various ISP CPE routers are concerend - some forward all ports to the IP you tell them, some do not, some forward but may still need a firewall rule configuring and so on.
However, if we assume it is opening and forwarding all ports to the IP you have assigned as your HD4s WAN, and assuming you have the HD4 doing NAT too you should have some config in the HD4 to forward the incomig port to the SRT listener… perhaps you could check?
In your screenshots the listener (which I assume is your device behind your HD4?) is waiting for incoming connections on port 1111, the caller is likely setup to connect to a specific public IP on port 1111.
If we assume that the caller is trying to connect to the public IP of your HD4s WAN that would likely explain why when you enable SF things break as if you are then tunnelling your traffic via SF your public IP will change to that of the exit hub, whether that is SFC or the HD2 in your office but again without details of your routing / outbound policies on the HD4 I am taking a bit of a guess here.
If you are trying to use SF Cloud and tunneling traffic via it this creates an additional problem for you where you cannot have ports forwarded from the public IP of the SFC hubs to devices on your network so port 1111 would not be forwarded to the SRT listner, again this would break your setup. You could use SFC though for an SRT caller where it is making the outbond connection just fine.