NAT problem with RTCP server
-
Hello.
I am sure I've catch a bug in pfsense software. I have RTCP server on tcp port 554 in my LAN with LAN IP 10.0.10.20 and gateway 10.0.10.1 which is pfsense virtual machine of version 2.4.3. I have simple pfsense config with only several nat and firewall rules which allows access to my RTCP server from WAN using port forwarding:
As you can see there is tcp port 554 is forwarded from wan and there is standard outbound nat with static port option active.
Also you can see disabled "allow all from wan" firewall rule.So the issue.
When I activate "allow all from wan" firewall rule and if I have static port option active in outbound nat rule the pfsense does NOT translate source IP address of outgoing RTP UDP streams and keep source IP 10.0.10.20 while RTP traffic flow to WAN RTCP client somewhere in the internet. I can see this if I collect traffic dump on WAN interface of pfsense.
If I activate "allow all from wan" rule in firewall and disable static port option in outbound nat rule then pfsense DOES translate source IP in RTP streams but does not keep port numbers (as it must to do without static port) and so RTP streams cannot reach RTCP client because of RTP packets have different ports from what was negotiated in signaling protocol.So I have to use static port in my case for RTP streams can reach RTCP client and if I activate "allow all from wan" rule in furewall settings I have the issue with no translating source IPs of RTP packets.
I am sure this is a bug. How can I report it if it's really a bug? if its not a bug - why I have not translated source IPs in RTP streams?
-
I am ready to send in private pcap traffic dumps with signalling and rtp packets. I don't want to upload it to public thread as they contain public IPs.
-
It looks like WAN firewall rule you have added for your port 554 port forward is incorrect. It should have destination 10.0.10.20 to match the forward. That's why you need to enable the allow all rule.
The reason you see traffic leaving the WAN un-NAT'd is usually because a state for that already exists so a new state cannot be created. If you already have traffic using the same source and destination IPs and ports that's what you'll see.
That's why source port randomisation is often required for older protocols with fixed source ports.Make sure you don't have an open state already that matches it.
Steve
-
"It looks like WAN firewall rule you have added for your port 554 port forward is incorrect. It should have destination 10.0.10.20 to match the forward. That’s why you need to enable the allow all rule."
No. The NAT redirection rule has destination 10.0.10.20 as "translation destination". It simply not visible in nat rules list.
And no - the server works fine if I DISABLE "allow all from internet" rule in firewall. If I enable this rule - I cannot see video stream in my client application."Make sure you don’t have an open state already that matches it."
I only test with one client application. And its stable situation - when I disable "allow all from inet" - I can see video stream and in traffic dump I always see that all RTP packets have translated source IPs. If I enable "allow all from inet" rule I cannot see video stream and I see untranslated source IPs in RTP streams. I repeated my tests many times and every time I have this results. -
No.
Firewall rules are processed post-NAT. So the rule passing traffic to WAN Address port 554 will NOT match traffic to the NAT port forward.
The destination on that firewall rule needs to be the real, inside address of the server, 10.0.10.20, not WAN Address.
-
Yes, you are right. However the rule which allows tcp port 554 even not needed because of I have an option "pass" in the nat redirection rule for port 554. And I have a question regarding the rule "allow all from internet", not the rule "allow tcp port 554".
