cable modem > WAN pfsense > LAN pfsense > 3560.  I am getting a proper Comcast public IP on the WAN interface via DHCP.  There are no special DHCP scope options for the LAN.  DHCP is working properly on the LAN interface.  Currently under the NAT Outbound section, I am using "Automatic Outbound Rule Generation."  This might be were the hang up is.  I am assuming this means NAT overload in Cisco terms.  Please correct me if I am wrong.  I am using the DNS forwarder and specifically using DYNDNS's DNS servers.  My clients are getting the proper gateway via DHCP.  Like I mentioned before I can ping 8.8.8.8 and www.google.com from the pfsense WAN and LAN interface. UPDATE It was a stupid mistake.  I went back into the firewall rules and the default allow rule allowing LAN to any was disabled.  Enabled the rule and everything started to work.

Provide a quick network map.  You obviously have a multi WAN or have a block of IP's.  How are you feeding those multiple IP's to PFsense?

Thanks for your help, I was a bit aggravated last night. In order for you to replicate, you would need another DNS server behind pfsense (version 1.2.3 to be sure you have got the same exact stuff) and then try to resolve rapportive.com through that name server from your client, which is also behind pfsense (DNS forwarder should probably be on but I get the same thing when I turn it off). As far as the states, the ones that I posted are from my bind server (172.20.20.81) after getting the failure when attempting to " dig @ns1.worldwidedns.net soa rapportive.com ". I then filtered through the states for the IP address of ns1.worldwidedns.net and that is what I saw. I admit this is very strange but I am assuming that pf does some sort of DNS fixup that does validation on query responses…

Skipping right over all the steps that cost me about three days and getting to the solved-ish process: VOIP / RTP UDP media forwarding on master/backup pfsense setup: IF your setup is a primary/backup two pfsense box failover operation: AND you change a NAT port forward rule OR related filter rule AND RTP VOIP traffic isn't working (no audio) , WHERE the SIP / PBX / VOIP phones say the call is 'in progress' AND you see RTP traffic showing up as incoming properly addressed on the WAN side packet capture. AND you see RTP traffic showing up as outgoing properly addressed on the LAN side packet capture. BUT you don't see the traffic crossing pfsense and getting out the other interface, despite firewall logs saying 'pass' on the packets involved, but with packet captures showing those packets pfsense never actually sends: THEN: Delete the nat port forward rule for the UDP packets.  Delete any associated filter rule. Go to System/Advanced Firewall/NAT/ NAT Reflection mode for port forwards.  Set that to disable.  Save it. Go to the backup pfsense box.  Do the same thing.  No, pfsync doesn't seem to sync this item. Go to any other non-RTP 'port forward' rules you may have and set the reflection mode there to what you would prefer.     in English: 'Use system default' means traffic coming in over the wire to the interface named in the gui that matches the rule will have its destination re-written as you desire.  No other interface will be affected.  Due to system quirks traffic that is coming in the interface containing the forward (re-written) address that matches the rule will be lost.  You want this for RTP if you are connected to any PBX system that is programmed to deal with NAT and SIP – but wait, don't enter it at this step.   'Enable Pure NAT' -- Does the above, but also puts in a rule so that traffic coming in to ANY interface heading for the named destination in the rule gets re-written to go to the given address, with replies (hopefully) going out the interface named in the GUI for the rule.  Once again, owing to system quirks, traffic coming in the interface that holds the final rewritten destination will be lost if it's destination address matches wan/incoming rule.  Use only if you are really sure interfaces now or in the future, virtual, vpn or actual, that ever show up on this box will want those ranges forwarded to the named destination, and possibly routed magically in reply in wondrous and unexpected ways that don't lead to being able to talk on the phone.   Enable Nat+Proxy --  Does the above but under verrry special conditions that require all the forwarding when taken together using this feature to not exceed port quantity limits, will do the right thing when traffic arrives at the destination interface that matches the rule, sending it back out that interface.  This is the default.  God help you if you put in too many ports in one rule or in combination.  Add one, increase the range of one, and get out your calculator and tally them all to stay under the limit.  If you can think through how you use pfsense so as to avoid sending traffic 'in' to interfaces that are just going to send it right back out the same wire you will be better off and your pfsense implementation will scale to great traffic sizes with more ease. Using dns forwarding so internal lookups give the local destination is one idea. Back to VOIP Go to Diagnostics / States / Reset States on the primary.  Hit the reset button.  Wait. Reboot the primary and the backup.  Wait. 7)  Add the 'port forward' rule for your RTP range.  Check the 'enable static port' button.  Choose 'use system default' for 'nat reflection.  Enter one port forward rule for every ISP interface you have.  Be sure you set your SIP PBX to limit itself to the RTP range of ports you've chosen.  Basically think one port per ongoing conversation.  Configure your PBX's 'internal' configuration to send traffic that never needs to leave private address spaces to send calls directly to the pbx/soft phone never using public ip's.  PFsense will route to the various vpns and internal subnets correctly. What a ride!

@defiantmofo: Is there a way an admin could run a script from the local network to enable/disable a firewall rule?  I wouldn't need to do this remotely, only at home on the same network.  I've searched around a bit, but couldn't find any solid info. Thanks! Not sure about disabling a rule… but here is what I have implemented... Via a web page I update the file pointed to by a URL alias (see Aliases->URLs tab, then select URL Table when creating the alias). The web page then calls some PHP code to tell pfSense to update the URL table. In order to implement this approach you'd have to run a web server (see vHosts package). Why am I doing this? I've got a list of addresses that are used by a rule. The web page updates the list of addresses - which changes the function of the rule. I know this doesn't do exactly what you are asking. However, with a little digging and creativity, I'm sure you could find the code that disables a rule and call it from a web page.

Well that looks right – you have a public on your wan and then private on lan..  So 213.64 is inetnum:        213.64.0.0 - 213.64.255.255 netname:        TELIANET So what is your vpn IP, that 10.8.0 you see is PRIVATE rfc1918 addressing -- that is not traceble or routable on the public net..

Hi Jimp @jimp: Having such NAT on each WAN works fine, provided your firewall rules and WAN config are proper. #1 - Make sure you do NOT use an interface group for WAN firewall rules - Rules on interface groups won't get the reply-to tag to ensure the return traffic exits the proper WAN. Make the rules on the actual WAN/WAN2 tab. #2- Make sure the firewall rule(s) do not have the box checked to disable reply-to. #3- Make sure the master reply-to disable switch is not checked, under System > Advanced, on the Firewall/NAT tab. #4- Make sure your WAN and WAN2 interfaces have a gateway selected on Interfaces > WAN/WAN2, not having a gateway selected on the Interface page will also make the system omit reply-to on the rules. Great post, thank you for this. It provided me with the needed pointer to make this work for us. The only thing I had to do different to make this work, is not select a gateway for the individual rules. With a gateway for the individual rules, it created route-to rules (pfctl -sr), without it creates reply-to rules. We are running 2.1-BETA1 snapshot from 1 April. I do have a gateway selected on the interfaces pages. Thanks again McGlenn

It's only possible for HTTP, but yes you can. You can use Squid3 for this as a Reverse Proxy.

What?  I think you might get better help in forum section with your native language.. That does not seem to be english. What do you mean by balancing and returns with 1241??  Yes it will have a source port – all tcp connections will have a source port and a destination port.  So pfsense send the traffic to 1420 with what source port?? So your taking inbound dst port to 9090 and forwarding to server on 1420, that is all good..  But the server would then answer to the source port that communication came from. So the return traffic would be from source port 1420 to whatever the source port that traffic came from.

Problem Solved, it was wrong IPs in Nat

Thanks so much! The option to put my external address fixed the issue.

Thanks for your reply. no i successfully added a manul NAT rule and its working fine

Nevermind.. it started working. I suppose it was an issue from my "wan" that is actually a nat to someone else.

Any chance this is on a residential connection? I.e., are you sure your ISP isn't filtering inbound port 80?