Did you setup client source port, this is a common mistake.  Your rule would be something simple lets say your clients IP address is 1.2.3.4, and your msql server listening on 3306 is on your private network 192.168.1.142 This would be your port forward, and it will auto create your firewall rule - notice that the nat is linked to firewall.  That little double arrow thing on the left of the port forward. First thing I would check is that you actually see the traffic on your wan to this port from your client.  Simple sniff on your wan interface, packet capture under diag menu on pfsense. Its quite possible that client doesn't allow this port out in the first place?  Please run through https://doc.pfsense.org/index.php/Port_Forward_Troubleshooting Common problem is pfsense is behind a nat, and the port forward is not setup on the nat device in front of pfsense.  Pfsense has public IP on its wan address?  Or does it have a rfc1918 address? [image: nat.png] [image: firewallrule.png] [image: nat.png_thumb] [image: firewallrule.png_thumb]

Jake- Were you able to get this to work?  I still can't get NTP redirection working.

Maybe they enabled dynamic routing protocols.  Doesn't make any sense that it would just work with no config. Anyway, you want to add outbound NAT rules for 192.168.0.0/16 and 172.16.0.0/12

@KOM: Don't use NAT Reflection, use Split DNS.  Create a DNS host override for your ownCloud public host and point it to the LAN IP address. Yeah I read the post c ouple down a few min ago.. I was trying to do without dns but probably alot simpler option. I have a dns server so I just put a fowarder in

Last night I built a new virtual firewall to attempt restoring the config.  I took a snapshot of the firewall in vmware and loaded one piece of config at a time, rebooting between each piece.  When I got to the traffic shaper, I experienced the issue again.  So I looked further back in my backups and noticed a change that had been made back in January on the traffic shaper.  I created the shaper from the wizard when the firewall was first setup and had set the "then current" bandwidth limits for the wan interface.  In January, I upped the bandwidth to 50Mbps from 30028 Kbps(15Mbps).  I assume that the issue just decided not to show up until I rebooted the firewall last week.  I changed the setting back to the 30028Kbps and the CLI command "pfctl -sn" started showing my nat rules again.  However, I still cannot ping from the LAN interfaces to a public IP.  Packet captures on the wan interface do not show anything related to my test pings.  I have checked my policies and Nat rules and they all seem to be in check.  I'm not sure what else to look at.

ssh into your pfsense and run tcpdump -nN -i <wan></wan> See if the traffic arrives, .. then check the firewall logs, .. If that's all ok check if it leaves the lan with tcpdump tcpdump -nN -i <lan></lan> then check the pbx or sip client, ..

Thank you Renato

Thanks for your help guys! Actually, Centurylink does block port 25, on home and business lines. If you have leased static IP, and we do, you can go into the IP tool manager and open port 25. Just did that and all is good! Here's the link: http://internethelp.centurylink.com/internethelp/email-troubleshooting-port25.html I removed those two outbound rules in pfSense.

For starters are you behind a NAT?  Did you tread the port forwarding troubleshooting guide?  Did you go through the steps there? https://doc.pfsense.org/index.php/Port_Forward_Troubleshooting Does your ISP even allow inbound traffic to 80 or 443.. Many of them may block this because your not allow to run servers on their service - check with your ISP.  Per the troubleshooting guide.. Sniff on your wan in pfsense packet capture, go to canyouseeme.org and generate traffic - do you see it in your sniff.. If not then your behind a nat that is not forwarding to you, or you isp is blocking, etc.

Ok, after writing this long post I tried to disable the tftp proxy. Don't know why I didn't do this in the first place. However now this works. Still I don't understand why the tftp proxy intercepts the udp traffic. Is this the right behavior? And is there a defect in the tftp proxy? If it is there it should be working, right? -flo-

True your forward needs to be to your actual server running owncloud not a network.

Sorry for the slow response.  I've been meaning to post a followup for a while… Because of the way pfSense stores rules in XML, scripting this would involve parsing out tags and generating matching NAT/PASS rules.  I concluded that the right way to to this is by enhancing easyrule to support generating NAT rules, which I don't think would be too difficult. It turned out to be unnecessary in my case, though.  I found out that HTcondor has a feature called "connection broker" that allows nodes to communicate with the scheduler from behind NAT just by switching it on and specifying the address of the scheduler.  It eliminates the need for the scheduler to connect to other nodes and instead routes all traffic through a connection initiated from the node to the scheduler (which I think is how it should have been done in the first place, but better late than never).  Hence, as long as the scheduler isn't behind NAT, there's no need for port forwarding. Regards, Jason

Openvpn? Give the openvpn client non-routable ip and 1:1 on that ? At least it should work in theory.

@johnpoz: So your trying to ftp working with telnet? "telnet ftp-server 21" Good catch didn't see that, usually the simplest answer is the correct one. Unless he just made a typo.

Ok, so what happens if you just type 'nslookup www.google.com', leaving out the '8.8.8.8'? Do you still get a reply? If not, then the problem is that your client doesn't have a valid DNS server defined in it's network config. If you do get a positive reply, then the issue is probably with the browser you're using - aka: it will have a proxy server set in the browser config which doesn't exist, or something like that.

Tells you right in your error Response:  227 Entering Passive Mode (192,168,1,12,26,8). Status:  Server sent passive reply with unroutable address. Using server address instead. Before the helper/proxy use to change that IP to the public - now there there is no helper/proxy your ftp server has to send the actual public IP.  Read the doc dok linked too.

I change the processor type from kvm64 to qemu64

@dotdash: Try creating an alias on the WAN like 10.215.221.1/25, then create CARP VIPs for 10.215.221.2,3,4,etc. Then use the CARP VIPs for 1-1s or port forwards. You should also be able to use 'Other' VIPs, but CARP type are more flexible. Great, it works perfectly, even if I don't create the alias on the WAN, just  with the CARP VIPs. Thank you!

I still see incoming ports randomizing. Anyone have any more ideas?