either way if that is a /24 routed to you - why are you natting it?  Just put it behind…  The only reason to do what your doing is its not actually routed to you via a transit - but your just handing off their connection.  Which is pretty shitty way to do it..

i think better test first the public ip address its route you wthiout pfsense.on laptop set public ip address and test it.

You need to port forward not just setup a rule.  The port forward will automatically setup the firewall rule automatically unless you tell it not to. Also Teamspeak uses the following inbound ports: Default voice port (UDP in): 9987 Default file transfer port (TCP in): 30033 Default serverquery port (TCP in): 10011 Default tsdns port (TCP in): 41144

Why do you need to call the ISP to see if they are blocking.. A 2 second test of packet capture on wan - and then going to something like can you see me . org tells you right away if 80 is allowed inbound to your IP.. You can call your ISP all you want, but until you do this simple test your not going to have proof one way or the other..

You have to use a /32 on the CIDR mask to limit the match to a single address. Like so: allow 1024-65535 192.168.0.101/32 1024-65535 192.168.1.4/24 is the same as 192.168.1.0/24 for all intents and purposes.

It was necessary to force the trunks to use a static SIP server port. The phones can be dynamic but the trunks need to be static. Then I just used an alias for the providers IP blocks - they have 10 C-blocks - and an alias for VoIP port ranges (5060 and 10000-20000). Then set up symmetric NAT, meaning, equivalent inbound and outbound mapping rules, except the outbound is 5060 only where as the inbound uses the alias. A lot of the problem was actually the provider. They replied to the dynamic port during call setup, but for tear down they were sending the BYE to 5060.

Check out the Gaming forum where they have quite a bit of information about NAT and various games.

What's the up-side? Isolation from your LAN.  If you have a proper DMZ and someone cracks one of your forwarded servers, they will have a very hard time making the jump to your LAN systems.  A 1:1 NAT to LAN is not a DMZ.

OK, Now the third interface is working partly. I can reach the server by ssh, but not by dns or ping. Besides the 1:1 NAT I also made a port forwarding rule for udp/53 and now dns is also reachable  :P Maybe the different subnets are a problem. The firewall has ip's on these subnets: 185.110.174.x (2 ips of which one is WAN interface), 185.110.174.x, 213.187.240.x, 185.110.172.x, 185.110.175.x and offcourse 192.168.0/24 Can these subnets be a problem? Thanks, Roger

"If you don't need NAT, how to the devices talk? NAT is a hack to allow sharing a single address or, in some cases, for combining networks that happen to have the same address range. I have IPv6 available with a /56 prefix.  That means I have 2^72 addresses available in 256 blocks of 2^64 addresses.  The main purpose of NAT was to stretch the IPv4 address space, breaking a few specs in the process.  All my IPv6 capable devices have their own global IPv6 address, with no need for NAT to share a single address. How do my devices talk?  Every one, that's IPv6 capable, including all computers, tablet & smart phone have their own IPv6 address that's reachable from outside my network, as I allow with my firewall configuration. NAT is a hack, which is used to get around the IPv4 address shortage.  Even with it, there are simply not enough IPv4 addresses to go around.  Those 2^72 IPv6 addresses I have are  2^40 times the entire IPv4 address space.  That's about a million, million addresses, so there's no need to use hacks like NAT to extend the life of the IPv4 address space. As I said, NAT is a hack and it breaks some things.  Using it has blinded people to how the 'net is supposed to work.

UDP (72 bytes) from 207.136.236.70:45347 to 172.17.19.54:53 on eth1   UDP (72 bytes) from 172.17.19.54:53 to 207.136.236.70:45347 on eth1 Look at the source MAC addresses of the inbound traffic and the dest MAC address of the reply traffic there. I would create a transit network between the two routers instead of putting the other router on LAN.

Hello, Thanks for your answer. I'll be sticking with Split DNS then. It works, so no worries. The only issue is that I need to make multiple A records on my Dynamic DNS service and I can only create 2 for freeDNS.

What PBX software are you using.  they are not all the same.

https://doc.pfsense.org/index.php/Why_can%27t_I_access_forwarded_ports_on_my_WAN_IP_from_my_LAN/OPTx_networks Getting 5 threads about the same thing per day gets rather annoying.

And now they learn. Still- no support here for outdated versions.  You can lead with that. ;)

I can't find it in the pf docs at the moment but IIRC it uses the source and destination when checking overloaded ports on outbound NAT so it can use the same source port more than once so long as the destination is different so it can discern where to send replies. Using a pool is better as it reduces contention but it's not as critical as it could be. It also makes the kind of statistic you're interested in very hard to calculate.

Ah i figured it out. It's the stupid ISP modem. Packets coming in from a port forwarding rule are stamped with the WAN IP of the modem as the client. Packets returning from a request initiated from within the network are as they should be. The real client IP is visiable as the source. So it's the way the ISp router performs port forwarding (Inteno FG500 if anyone is interested.).

Is their a solution to this? uPnP?

Source nat would be done on pfsense.