Hi,

I have indeed been able to resolve this issue.
After doing some sniffing with wireshark both on the inside as on the outside interface of both the pfsense firewall and the end stations, I've seen that Pfsense was doing PAT (Port address translation) on the outgoing RTP traffic (which is actually normal for a NAT firewall to do). So Pfsense was changing souce and destination ports on outgoing RTP traffic being sent from the internal PBX to the end point (receiving call device).

After some searching I found an option in Pfsense that enables you to use static outbound ports for specific devices.

If you go to the NAT configuration of your pfsense (Firewall >> NAT). There you can go to the "Outbound" tab and enable "Manual Outbound NAT rule generation".

If you did that, you can add a specific rule for your "internal PBX IP" as source with source port "udp/" to "** (any)**" destination with destination port "udp/1024:65535" and your "WAN Address" as NAT address. The trick is to enable "Static Port" on this rule, forcing your pfsense to use the same source port your PBX is using to forward to the end point. (See attachment)

I believe this problem occurs because the end point (receiving the call) receives packages containing a different source port than those stated in the package payload (content of the packages). If the end point returns RTP packages, it will use the source ports that it can find in the package payload and ignores the source ports from the package itself. When the end point returns RTP packages to pfsense, they will be sent to  another destination port than the active socket is using, causing the firewall to block/drop the packages.

I hope this info is correct and can help you troubleshoot your problem.

Kind regards,

Francis Claessens.

2014-04-04_08h16_44.png
2014-04-04_08h16_44.png_thumb

And the source port has to be 4001??  What software is this – you normally do not require a specific source port..  I show 4001 is registered to newoak

http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.txt

Also seems odd that you would really need to NAT between local segments both using rfc1918 address space.  So what is your final solution?  Did you really need source port of 4001 and Natting?

Solved - Here is what I did and it was so simple.

For the two server, 10.10.60.10 and 10.10.70.20 I enabled NAT reflection for the 1:1 NAT.  After that, I was able to ping, ssh and everything else just fine using the public IP address.

Thank you

Rick

Well, everything is working now. Not sure what was going on, it was probably just my noobiness haha.

The alias was just to help me remember what that IP is going to.

Thanks for the help johnpoz.

Ok I figured it out for my particular setup.

In the System/General Setup I had three DNS entries.  Two from unblockus and an IPv6 one from OpenDNS.  I'm thinking that the Chromecast was being handed an IPv6 address (assuming it supports it) and it was always trying to resolve Netflix destinations with the OpenDNS server.  Obviously this would end up making me look like I was in Canada so hence only the Canadian titles would cast.

I deleted the OpenDNS entry and now I assume that my NAT rule is kicking in because I'm now able to stream U.S. Netflix videos without any issue.  I don't have any good way of proving this other than putting the IPv6 DNS entry back in but for now I'm happy with the way things are.

LoboTiger

So my issue wasn't NAT, I didn't have the correct gateways nor routes established.  Problem is now fixed, thanks for the advice, double NATing does seem like a nightmare….

You are a gentleman and scholar sir.

That was it exactly.

Thank you for your help!

-S

ptt - Good question and one that I should have provided.  For testing purposes I have opened up all traffic into VLAN100 and VLAN200 from the WAN, and I have also opened all traffic out from both VLAN100 and VLAN200.  As I mentioned, from a remote computer that is not behind the firewall I can connect to either CentOS #1 or #2 without issues.  The issue only arises when trying to go from VLAN100 to a server on VLAN200 or vis-versa.  One additional note:  If I attempt to ssh from CentOS #1 to CentOS #2, I do receive a login prompt, but entering the correct user and passwork fail.  My assumption is that I am somehow being connected to the pfSense FW and not the CentOS #2 server.  Not sure why, but I am sure it has to do with the current setup and the issues that I am having.

Thank you again in advance for your help.

Rick

Without firewall rules, a 1:1 NAT rule only redirects and does not expose the protected resource. I know it says in the book (probably near the front) that everything is blocked unless expressly allowed by a rule. This does not apply to float rules though.
Port forward rules by themselves won't expose a protected resource. The default now is to create a rules automatically when you create the port forward rule.
I use 1:1 rules all the time without any problems.

:(
….

....

It was Windows Firewall's fault. epic facepalm

All is well now. A quick disabling of the Win Firewall allowed RDP sessions and pings in and out, and PFSense's automatic outbound NAT took over admirably. :D

And you sure your https server doesn't have a firewall blocking your access from outside its own network?  This is quite often the case.

You sure your isp allows the ports your trying to forward?  Why would you not be forwarding 443 to 443?  You just list [port]

Simple 2 second test, sniff on your wan – do you see the traffic come inbound say from your scan or someone outside your network trying to access?  If you see the traffic, do you see it leave the lan interface to your https server?

https://doc.pfsense.org/index.php/Port_Forward_Troubleshooting

"Trying to telnet from 192.168.0.5 > 192.168.0.25"

And why would pfsense be involved in this traffic??  Are you bridging interfaces?  WHY would be my first question ;)

Traffic on the same segment doesn't go through pfsense in a normal setup.  Only if you were bridging interfaces could this happen.

As requested already - give us something to work with any be happy to help you. Lets see your firewall rules for starters..

I really want to help the guy - so I have been TV'd in and accessed his modem before, but now it seems pfsense is messing with the password so it doesn't work? :rolleyes:

I have been remote to his system like 5 times now and every single time is something else that prevents me from doing the most basic things.  He can not ssh to his server, he can not login to virtualmin, mouse doesn't work so I can not control.  It did work until he reset his modem again.

This is like 2 minutes

Set modem to DMZ (since he does not want to bridge?? or can not?) to his pfsense wan - setup forward on pfsense (click) = done..  It is frustrating to say the least..  He clearly should not be hosting anything off his own connection.  Be it dns or some site be it even for his own access

;D
Problem solved. Windows VPN behind NAT how to do it? Don't connect to public ip.

You need "NAT Reflection" turned on. Even then, I would not use it. I would instead use split or internal only DNS resolution. It is much faster and less prone to problems.

Phil,

In a way, I have to say that this is excellent news, at least from the standpoint that it explains the situation. And honestly, my intention wasn't for NAT rules to be automatically generated. I really just wanted to understand why it automatically made the rules in manual mode and not in automatic mode. In the end, if the rules have to manually entered, then so be it. At least it would be consistent.

So thank you again for your time and for starting a bug report. I'll keep an eye on the progress.

Best regards,

Mike

Thanks all.  I'm not sure what been going on, but going back to the old method of manually creating the rules after making the NAT seems to work.

We're still seeing issues with the CARP and it's only occasionally.

Mar 13 02:36:37    kernel: lan_vip4: link state changed to UP Mar 13 02:36:34    kernel: lan_vip4: link state changed to DOWN Mar 13 02:36:34    kernel: lan_vip4: MASTER -> BACKUP (more frequent advertisement received) Mar 13 01:23:17    kernel: lan_vip4: link state changed to UP Mar 13 01:23:14    kernel: lan_vip4: link state changed to DOWN Mar 13 01:23:14    kernel: lan_vip4: MASTER -> BACKUP (more frequent advertisement received)

I'm starting a new topic relating to that.

Sounds as if you are having a port routing issue with the DVR / CCTV setup itself , these ports can be found by accessing the unit locally in the network settings. Many units have different port settings, so please check with your specific unit before adding any port forwards.

Make sure though you have a static DHCP reservation to the DVR

Insure proper ports are forwarded on the WAN to the static IP reservation

There will be at least three ports - that will need forwarded

Mobile - many times :15961

Server - many times :10000

HTTP - generally :80

By the looks of your screenshots, you should not be natting these ports to  :80 - they should simply be forwarded to the DVR on the same port the unit is setup to accept.

Just forward the ports from WAN, to the DVR

Solved:  Turns out that sometimes if you go through the setup too fast you can end up setting the LAN interface as the default gateway …  Fix is deleting it from System: Gateways.