I opened all the doors, and it worked.

I got it solved  :) For anyone else in this situation: the port forwarding must be done by the VPN server as well as by pfSense. I was missing the part about the VPN server needing to forward the ports also. My tunnel was configured to use NAT instead of a direct connection, and it was not forwarding any ports. Once I changed this to use a direct connection and forward port 51413 through the tunnel, the problem was solved  :). [image: vpnprovider_tunnel_config.PNG] [image: transmission_port_open.PNG]

Not unless you also do manual outbound NAT to mask the source of the traffic so it appears to come from your firewall. The problem with doing that is that the remote client will hit pfSense, pfSense will forward to the server, but the server will not send the reply back through pfSense, so the connection will fail. If you use NAT to make it look like the connection between pfSense and the server came from pfSense, it would work, but the server wouldn't know where the traffic really originated.

Hey, Just giving this a bump – any thoughts from anyone on what to do next in terms of debugging/diagnosing this? thanks!

Thank you very much, that was the issue :)

@georgeman: Try setting Outbound NAT to Manual, and setting the option for "static ports", on all involved interfaces. If it works, then you can narrow it down to exactly what port/protocol/interface/destination you actually need static ports on Thank you georgeman, unfortunately this didn't work, after further problem investigation i finally able to pinpoint the problem, the remote server doesn't reply to openvpn client in pfsense (10.0.0.1 => 10.0.0.6) but instead it reply to LAN IP (10.0.0.1 => 192.168.1.12) why is this happening? after researching online i found this issue called masquerading,  any one can help me resolve it please. [image: YnRI.png]

You cannot use Automatic Outbound NAT with a proper/correct CARP configuration. You must be on Manual Outbound NAT and have the CARP VIP specified in the translation address of the rules. The only downside to that vs automatic is that if you add a new subnet, you'll need to add NAT rules for it. That's really all Automatic Outbound NAT does, is to add basic NAT rules for all "local" subnets.

I'm not sure how but everything is now working. and just for the record the 27777 port is still on my LAN and WAN rules. thanks for the support. Can close this now.

pfSense is up and running fine now. The /32 setting on the OPT interfaces was the issue!!! A simple balls up that had me completely lost until I had a brain wave last night. I should have guessed this earlier really. When the outbound NAT rules were autogenerated I kept changing them to NAT the whole subnet rather than just the interface address!!! This is the issue when you use a forum to ask for help you know you will ultimately look like a numpty when your error is found! Thanks for your assistance anyway it helped me think things through until I realised what the problem was.

Tks for your reply so far. The connection speed and stability through public internet is quite bad from Asia to Europe, while it is far better using the internal way through our MPLS (leased line). Your answer convers the part with the virtual address, which seems to be fine with pfSense. In the linked tutorial under "NAT IP" the description says one can only enter an INTERNAL ip as the destination IP, but in our case the destination IP should be the EXTERNAL ip of our hoster. Do I understand it right that way? regards, janosh

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!