@tlum: It may be a bug in v2. I have a working rule that was set up years ago in v1. I'm now entering a new rule in v2 and the rule does not work. I'm still troubleshooting but it looks like the rule was not instantiated correctly. Nope, rule conflict, see http://forum.pfsense.org/index.php/topic,49119.0.html

I was able to do this when I was running DD-WRT; basically needed to run the PPPoE and an IP on the same interface.  I have never been able to get this to work on pfSense; when and if I need to get on the modem I just connect a computer to it.

Also some searching might help

Port forwarding is required, but not enough in my case. Only in this way I can solve problems like 1-way audio and dropped calls. When the SIP client is in a 3G network Full Cone NAT is the only way to make a connection.

Thanks for the info. They are on different subnets, but I did have a try and played out with firewall rules etc. It did work but seemed a little unstable. I don't know if you have experience of Sonos kit, but I have a couple of CR200 controllers - only one zone would be listed on the controller, but if I connected my laptop by cable to a switch, then all zones would appear in the software/laptop controller. Phil

Hostnames are supported, but only inside aliases. Firewall > Aliases, click +, give it a name, set the type to 'host', and then click + and add each of the dnsdns hosts you want at the bottom. Then use that alias name in the firewall rule. Hostnames in aliases are periodically re-resolved and updated when new records are found.

This set-up was tested with a single WAN, I have no way of testing it with 2 WAN's. If you have the same rules for both WAN's then I would suspect the connections would have to be persistant. Try turning off Round Robin, see if it works then tweak the load balancing rules to suit.

Some things in relayd require a full reload (kill/restart), but some require only re-parsing the config. Most of the changes made in the GUI only trigger that faster refresh, to minimize downtime. You can always restart the service from Status > Services which will fully reload (stop/start) the daemon.

If all the states truly were gone, then you have a problem with filter reloads failing. It's never required to reboot to remove a port forward. That would definitely be caused by a package of some sort, one that ties into the filter reload (squid, pfblocker, countryblock, amongst others). Check Status>Filter reload, force a filter reload and see what it shows. Check the system log.

Agreed !! Enable Nat reflection! It's on by default. It's under advanced settings, then the Firewall / Nat tab

When trying to use RDP, set pfSense to log connections for the port and then try to connect while logged into the firewall and see what happens, if you cant do both at the same time then while at the location go to grc.com from any computer there and under services click shieldsup!, scroll down and click proceed and then type in the port that you want to see the status of (open,closed,stealth), in this case 3389 and click "User Specified Custom Port Probe". If it says you failed then you have succeeded, the port is open to all to see. Things that could be blocking RDP from working in addition to what CMB has stated: Snort Firewall port forward rule incorrect IP address of the system you want to RDP to has changed

it's in kernel on 2.x, no need to turn it on or do anything.

@jorbsd: Will pfSense support NAT-PMP? I still use a few things that work much better (or at all) with NAT-PMP instead of uPNP. Yes, it does: Services menu > UPnP & NAT-PMP Enable UPnP & NAT-PMP Allow UPnP Port Mapping - This protocol is often used by Microsoft-compatible systems. Allow NAT-PMP Port Mapping - This protocol is often used by Apple-compatible systems. And a few more settings.

Interface  VoIP Server                                                        Static Port WAN  192.168.111.100/31 * * * * * YES Create a rule the same as above just change your IP address to your Asterisk Box

You need a VIP for every ptpp connection. Normal House routers use NAT because they usually have a single IP and need to access everything through that single IP. If you are routing private addresses only then you can disable NAT, but if you have to go onto the internet they won't route so you have to NAT. Thinking out loud here? Don't know enough about your system. Maybe if u put a diagram we could help. What did you use before pfSense, can you use that to terminate the pptp's to, and then connect via IPSec inside? Chuck a Linux box outside and ssr each connection inside, not sure that'd work either?

Packet capture on WAN, see if the traffic gets there. Then on LAN, see if it leaves, and gets a response.

Remove the static routes, as it says you never add static routes for locally attached networks. Note that will remove the link route too so you'll have to reboot after doing so, it'll drop off the network. Your firewall rules on internal interfaces are largely redundant. For instance on PROD, the first rule matches everything so the two subsequent rules do nothing. The second rule on TEST matches everything so the rest are redundant. Port forward config is fine. Troubleshooting steps for that here: http://doc.pfsense.org/index.php/Port_Forward_Troubleshooting

Efonne, Thanks for the prompt reply. Unfortunately I did not test your command since I was able to fix the NAT issue I was having and uploaded a solution to my post as well. (iptables to pfsense command line?) I'm sure this should help someone who was trying to accomplish the same. Thank you for your time! David Cabrejos

All, So I was able to fix my issue and bypass using manually created NAT rules. Everything is now done automatically. The way I used to add NAT statements was to do the following: 1. Create a file with the NAT statements you would like to be in place.         /usr/local/etc/vpnc/custom_nat.conf         nat on tun0 from 172.23.34.0/24 to 10.0.0.0/8 -> (tun0)         nat on tun0 from 172.23.34.0/24 to 172.16.0.0/16 -> (tun0)         nat on tun0 from 10.0.0.0/8 to 172.23.34.0/24 -> (tun0)         nat on tun0 from 172.16.0.0/16 to 172.23.34.0/24 -> (tun0) 2. Append the information from the file above to the current NAT list:         pfctl -sn > /usr/local/etc/vpnc/nat.conf           cat /usr/local/etc/vpnc/custom_nat.conf >> /usr/local/etc/vpnc/nat.conf           pfctl -Nf /usr/local/etc/vpnc/nat.conf 3. Check if your NAT statements were applied to the current NAT.         pfctl -sn That's all I did. Now I am able to use VPNC and everything is done automatically without a need to do anything. Of course I wrote other scripts to make sure it's always active and all! Hope this helps everyone out there since it took me a while to figure out the locations of NAT statements within pfsense. David Cabrejos