Jimp, The first time I upgraded to 2.2, I did not turn off xmlrpc sync so the outbound NAT config got messed up. After that I tried to restore an old config and it did not seem to convert as the outbound NAT config was still messed up. Do I need to restore the config and reboot for the config conversion to take place? Thank you, Rhongomiant

I found the problem.  It had nothing to do with the router.  The VPN server I was connected to did not allow port forwarding.  I rerouted that particular device to a different vpn server that allowed port forwarding.

This is a NAT reflection thing. The easy way is for internal LAN clients to use the actual LAN IP of the server - 192.168.100.2:8006 - whatever is the DNS name on the public internet that resolves to XXX.XXX.162.220, say server.mycompany.example.com Add a Host Override on pfSense for server.mycompany.example.com to 192.168.100.2 Then internal LAN clients can use that name and go directly to 192.168.100.2, thus avoiding the whole NAT reflection thing.

It can be possible with IPsec but you have to force all traffic to/from the target box over IPsec. For example, on the side receiving the Internet traffic, you'd have a P2 for 0.0.0.0/0 to the NAT target (e.g. 10.0.0.5) and then on the other side you'd have a P2 for 10.0.0.5 to 0.0.0.0/0. So all traffic to/from the Internet on 10.0.0.5 must go over IPsec, which is not ideal. OpenVPN can do this in a much more flexible way without that requirement.

By time you check it might have been resolved, but the client did not get a answer and neg cached it, so doesn't even ask for it again. Clients all have their own dns cache, browsers have their own cache as well, etc. If you having an issue from a client with sites (fqdn) do a query from the client for that fqdn, does it resolve?  look in the clients local cache with windows you can do it with. /displaydns      Display the contents of the DNS Resolver Cache. Restart you browser. To the settings that should be enabled until 2.2.1 makes them default you can check out https://redmine.pfsense.org/issues/4402 If your having issue with the resolver and speed, etc.  Try changing over to the old forwarder(dnsmasq) vs resolver (unbound), enable the forwarder mode in resolver, etc.  Possible your isp is doing something underhanded with dns queries and that could cause your resolver problems.

I've never know that to be much of an issue, and for the odd client that might have it, ipconfig /flushdns fixes it.

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.