Indeed, it worked.

Starting with tutorial's rules, remote pfSense had OVN net access (10.4.0.0/24). While not for source machine which IP became non-masqueraded by NAT.

Adding source net 192.168.5.0/24 rule made everything working, which makes sense.

Time to clean up the rules and get rid of manual Outbound NAT. Especially, since pfSense 2.2 aliases made things way cleaner.

Thanks a lot!

No idea what OpenWRT even looks like.  This isn't an OpenWRT forum.

@Supermule:

What model is it?

SMCD3G

EDIT: I do not have static IPs, but I am capable of modifying any rules that break if they change, which it hasn't in over a year.

EDIT2: I found this post http://forums.businesshelp.comcast.com/t5/Equipment-Modems-Gateways/SMCD3G-CCR-Modem-Need-to-change-to-bridge-mode/td-p/8943 and decided to call on it. They escalated me to T2 which will be abel to enter the modem into full bridge mode within 24 hours :)

@Thilroy:

Hi!

Just to know if you have solved that problem. I'm on v2.2 and having quite the same problem : I've defined a specific rule for specific hosts to use another GW, but the rule is not working : all the traffic is routed through the default GW, as I can verify with a trace route…

Have a nice day,

Thilroy

Thilroy, make sure that you set custom LAN out rules before the default LAN rule (assuming not floating) also are you using a custom monitor ip?

Thanks viragomann!

That solution worked perfectly.

@Derelict:

Why not just set the limiter on the port forward rule?  That's generally what people do.  You have to have the rule anyway.

Floating rules are processed first.  If it is a match rule without quick, all it should do is set the limiter.

Maybe someone who knows more about the internals will chime in.

https://doc.pfsense.org/index.php/Firewall_Rule_Processing_Order

Indeed that is the "fix" but then it requires that each of our rules be duplicated multiple times so we can apply different speed tiers with the limiters. This really isn't an outage causing issue, but it does appear to be a break of user-land functionality.

Do you have an upstream router operating as the next hop to the internet? If so, do you have administrative access to it? Assumedly you can telnet successfully from an unaffected host to a remote site (eg: "telnet www.google.com 80"). What happens when you do the same from a non-functioning host?

Might be helpful if you could post a map/outline of your network configuration, showing the path from local LAN to DMZ to outside. Also, can you specify what server(s) are handling your DNS and - if any - your DHCP allocation? A screenshot of your NAT and firewall rules might be useful also.

Look at the diagram in my sig.  So you want to have connections into pfSense A 172.27.0.5 port forwarded to Host B1?

I know the OpenVPN instance on pfSense B will need an assigned interface or reply-to will be broken. And rules on pfSense B's OpenVPN tab cannot match the inbound traffic or reply-to will be broken.  Other than that, you just have to make sure the firewall rules on pfSense B's OVPNC1 pass traffic from any (or at least the hosts hitting the port forward) to 172.26.2.100.

https://forum.pfsense.org/index.php?topic=82732.msg453269#msg453269

@Derelict:

You know, telling everyone you were running it virtualized in your opening post would have been helpful.

Not to mention that this has nothing in common with the OP's issue apparently.

A port forward has to have a rule bound to a corresponding NAT entry. And you can schedule a rule (see 'Schedule' button under 'Advanced' section).

Thanks for all your replies, I finally bought from another VPN provider and so far it's working pretty well.

Got it!

Wow, well you were right on money cmb, the gateway and IP had changed when we switched over to PFsense. Got the right info into the NAT entry and we were off and running.

Thanks KOM and cmb, I really appreciate the help! :)

Thank you for the answers, got it working as suggested.

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?

nat.png
firewallrule.png
nat.png_thumb
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

See if the traffic arrives, .. then check the firewall logs, .. If that's all ok check if it leaves the lan with tcpdump

then check the pbx or sip client, ..