Hello
I have a Max HD4 used for SRT stream
it works properly when speed fusion is not activated
As soon as I activate the speed fusion, the srt stream is blocked
I have tried with our own speed fusion (a Max HD2 in our office) ; I have put the router into the dmz, but it didn’t change.
I have tried with a speed fusion cloud, with different location, but the issue is the same.
I have no idea how to fix this ; any idea someone ?
Thanks
Loïc
Hello, we may need a few more details about your setup to help you. SRT should absolutely work (very well) through a PepVPN / SF setup - we use it all the time. 
The SRT stream coming from behind your HD4 - is that the caller (TX), or the listener (RX)?
Where is the other end of the SRT stream located, and what network infrastructure is in front of it and between your SRT endpoint behind the HD4 - a basic diagram including subnets may be useful here.
If your HD4 is where the SRT listener is and you have any port forwarding done against the HD4s WAN IPs when you enable SF bear in mind you are tunnelling your traffic to somewhere else - did you check any necessary port forwarding / firewall / routing configuration is in place?
Bear in mind also if you are using SF Cloud then as far as I know at the moment there is no way to forward ports from the public IP you get from SFC, so anything wanting to use SRT behind SFC would need to be a talker, or you may be able to get rendezvous mode to work.
Hi
Thanks for your answer. Unfortunately, I am not on the setup, and can not provide too much details
I think that the srt is the listener : they are using Haivision KB
I have a frame where I listen (MPEG TS - SRT Listener (1.3.4 / 0.0.0) port : 1111
When it works, i have a image displayed, with green
Any time I choose to send all trafic through speed fusion, I can’t display the image, and the buttons are not green but orange
I have attached two pic, one without speedfusion on, the other with speedfusion on
does it help ?
To be honest, I have no idea of what port fowarding should be in place for SRT listener
the speed fusion router is in the DMZ ; I thought that would prevent any firwall or forwading rout of the WAN router, doesn’t it ?
Hey so I am having this same issue.
My setup is kinda similar except i am running my own SRT server in AWS along with Fusion Hub in AWS.
I am running as a caller from inside the SpeedFusion tunnel and listening on the server side.
The server can be accessed outside of the tunnel but not inside. Any thoughts?
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.
First one would be do you have NAT enabled on the PepVPN profile?
When you say it works outside the VPN tunnel do you mean you have a port forwarded from the FusionHubs WAN to your SRT servers IP and you connect directly to the public IP+port of the FH?
A basic diagram and some screenshots of your PepVPN config + outbound policy would be good to see - just blur out any sensitive details like public IPs etc.
Hi WillJones
Thanks for your advise ; we have made a NAT mode + port forwarding
We had to disconnect the “send all trafic to” SF and to replace with a outboung policy for TCP port to VPN and it worked
I am not very good with configurate this, as you can see, but it worked, thanks to you !
Hi Will,
So I do not have NAT enabled on the profile. I have tried toggling back and forth and not change with it. I have also tried toggling WAN smoothing and FEC to see if they were causing issues. Nothing has worked.
I have an SRT decoder that is set for caller mode to call our server as to not need to open any ports on the client-side. The Server-side is properly configured with open ports. DNS is also working properly.
If I enforce the decoder to use a normal WAN connection I can connect to the SRT server properly and decode the video. As soon as I enforce it to use the VPN I get an input-output error in my decoder. I can confirm I can send an SRT out of the VPN to my SRT server just not bring one back in. In both cases, my SRT encoder and decoder are both in caller mode not requiring any port forwards.
Also if I force a normal computer to use the VPN everything works normally. Teamviewer, internal servers etc. I also did try a different SRT server in a completely different cloud provider and got the same results. Also checked my AWS security profile and everything looks to be in order. Even tried spinning up a second fusion hub instance and got the same results.
Not really sure what i am doing wrong here haha! Very much appreciate the help!
@loic67 and @w33bster, can I confirm the reported problem happens in 8.1.1 only? The SRT stream will be running fine if you reboot to 8.1.0?
Maybe @TK_Liew can confirm as they probably have more experience setting this up in AWS but I am wondering for @w33bster whether this may be a rouitng issue?
I do not have much experience of running the FusionHubs in AWS but my notes on the subject say that to allow traffic to enter the FH and then to reach other instances inside the VPC you need to have the WAN configured for IP forwarding, as well as the “SF Peers access internal network” button and ensuring the correct routes are present on the AWS side for the subnets connected behind the remote Peplinks?
For what it’s worth I’m currently supporting a live stream that has 3 remote contributors connecting via SRT to a central studio, but none of our setup involves AWS.
The remote contributors have a hardware SRT encoder connected to a Transit Duo, the TST is then making a SF VPN (via bonded cellular) to one of our FusionHubs (vmware environment).
The SRT decoders in the studio are connected behind a 310X which has a SF VPN to the same FusionHub. There is no NAT enabled on any of the peers so everything is end to end reachable and it is working just fine (all Peplink elements are running 8.1.1).
Ok, so I got it to work.
I was running version 8.1.1 on the Fusion Hub and 8.1.0 on my EPX.
@TK_Liew I downgraded the Fusion Hub to 8.1.0 and it worked immediately. Not sure if a version mismatch caused it or if it was an issue with 8.1.1. Currently in production on my EPX and cannot upgrade to 8.1.1 for probably another week.
@WillJones so on the AWS AMI version of Fusion Hub I don’t have access to change the Connection Method to Static. It only gives the option of DHCP since AWS handles the static IP directly. I do have the SpeedFusion Peers enabled. I did think it was a routing issue initially but did some routing tests and saw no issues.
When I upgrade to 8.1.1 I will reply here and see if the issue persists.
Thank you for the help!
@w33bster, I suspect you are hitting the known issue of 8.1.1. We will fix it in 8.1.2 which to be available in March or April. You may stay with 8.1.0 for the time being.
Ah that was a quick screengrab from another hub - not one in AWS, just had my written notes that said “tick this box too” But it sounds like TK may have an answer for why you are having issues.
@TK_Liew Are you able to share details on this known issue, I cannot see anything in the published release notes for 8.1.1 and SRT seems to work fine for us with 8.1.1 + SF VPNs across various boxes, if you need to share the deatails in private please do so as we do a lot of work with SRT and I’d like to know if we’re likely to hit the problem ourselves.
@WillJones, based on a SRT case in hand, I found that the DF bit (Don’t Fragment) is set for the SRT stream packet and the packet size around 1380 bytes. Fyi, the SpeedFusion MTU size is about 1340. Started from 8.1.1, we will follow the DF bit. Since the packet size is larger than 1340 and fragmentation is not allowed, the packet is dropped at the end. I suspect @w33bster is facing the same problem since it is working fine in 8.1.0.
It looks like 8.1.1 not affects all the SRT users. Maybe this is related to the settings of the SRT application.
Hope this helps.
@TK_Liew Thanks - that makes sense and good to know for the future.
I did notice that in @w33bster screenshots they show encryption enabled on the PepVPN configuration in IC2 - for reference we are running without encryption enabled which I believe gives us a slightly larger MTU inside the PepVPN so that may explain why we are not hitting this issue.
RE the specific SRT implementation that is a possibility, we are using products from a single vendor at both ends of our SRT system (Makito hardware encoders) so potentially there is some proprietary feature engaging between them to help them connect (fyi Haivision are the originators of the SRT protocol, their implementation as such could be considered the reference implementation).
Thanks for posting this - We ran into this issue and were able to solve it quickly by rolling back to 8.1.0. Looking forward to 8.1.2
We have found out SRT works with FW 8.1.1
Our solution is to set MTU Size 1340 for SRT stream.
