I don't have the answers to your questions, sorry.

But I have a very similar problem and my setup is almost identical, I can get SIP and RTP working without issue on one VoIP carrier but another carrier I don't get any inbound RTP, they can be seen in the pcap from the WAN interface but they never exit the LAN interface.  Checking the SIP packets and the ports used for RTP that are defined they fit within the NAT'ed and allows range of ports, there is no message of dropped packets in the firewall logs.

It seems like the inbound RTP packets just get lost in the kernel or something like that, I though it might have been just my hardware or setup, but I tried it on a fresh install on server hardware at work and had the same issue.  I did an install of OpenBSD with a similar ruleset and the problem didn't exist anymore, so it doesn't seem to be a hardware issue but something specific to pfSense or the FreeBSD kernel.

I have tried manual outbound NAT, changing many tuning parameters but nothing seems to work.

I'm not sure how I can troubleshoot this issue further but there ceratinly seems to be something wrong with pfSense in this regard.

Tnx podilarius,

i rebooted the machine.

I tried to simulate this behavior again, now I cannot reproduce this problem.
Now I hope that the client have no problems any more. If so?  I let you know.

Is the server responding with the internal address? If so, this is a redirect in the server that is causing an issue. Websites should be setup with DNS name for redirects or better, with logical redirects. You will need to determine where the response is originating from … the server, or pfsense.

And who are you?  The OP was named paulfred.. As to looking at the settngs - well if its not performing the task the OP wanted is prob because he set it up wrong, or it doesn't even do what he thinks it can do.  Some clear understanding of what he did, or thinks he did wold be helpful in trying to figure out if it would work or not even.

He mentions he followed a guide, but never even links to the what guide..

I would setup a port forward in NAT to relay inbound traffic to WAN address port 20000 to 192.168.1.9 on port 20000 (I am guessing TCP).

There is no way around a reverse http proxy.
Search the forum for "reverse http proxy".

This might be what you are looking for:
https://doc.pfsense.org/index.php/Haproxy_package

Thanks a lot

"In class we learned the limitations of windows and routing and saw that after 3 linear subnets that we need to manually modify the routing table. "

I am curious on this statement of yours – What exactly is that suppose to mean?  Why would you need to create a manual route?

@stephenw10:

Yes 'LAN subnet'. It's displayed as 'LAN net' in the rule table. Confusing.  ;)

There have been enough queries about this inconsistency, I bit the bullet and submitted a pull request to make it all say "LAN net", "WAN net" rather than using "subnet" in some places:
https://github.com/pfsense/pfsense/pull/902
Took only a few minutes to make the changes, we will all save more time than that in answering queries.

Thanks Solved for me =)

NAT > Outbound > Select Manual
Create a rule to virtual ip network =)

Er, that's what it's designed for. Read about how it works, and try it out.

So the default outbound NAT rule (when it's set to auto) catches all traffic from the LAN subnet and NATs it. If you switch to manual you can change the destination to something like '!WAN subnet' such that it will still NAT traffic for anything beyond the ASA LAN. However clients in the ASA LAN (pfSense WAN) subnet will still not have a route back to the pfSense LAN subnet.
I've not tried to setup anything like this but I would suggest that disabling NAT entirely will probably be easier to work with than having it partially enabled.

Steve

johnpoz, thanks for the reply.

I ended up resolving this issue by changing the NAT reflection from 'System Default' to 'Pure NAT'.