Clear the browsers cache.

The reason is probably that you try to reach your internal servers by their public host names, which could not work. Cause you've forwarded the public IPs only on the WAN interface, not on the internal ones. Tow ways to resolve: Set up an internal DNS (split DNS) if you haven't already one and override the public host names with the internal host IPs. Use NAT reflection. That "reflects" the forwarding rules to the internal interfaces. NAT reflection can be activated in each particular NAT rule or globally in System > Advanced > Firewall & NAT. For the global set up, at "NAT Reflection mode for port forwards" select "pure NAT" and check "Enable automatic outbound NAT for Reflection". If you want to use the global settings the "NAT reflection" option in the forwarding rule has to be set to "system defaults", which is the default option.

Nevermind…I solved it. Forgot to enable NAT Reflection from System > Advanced, Firewall/NAT. Seems stable so far.

Wouldn't you be better doing it over an IPsec Tunnel ? SNMP isn't NAT friendly :- https://www.ietf.org/rfc/rfc3027.txt 4.8 SNMP SNMP is a network management protocol based on UDP.  SNMP payload may   contain IP addresses or may refer IP addresses through an index into   a table.  As a result, when devices within a private network are   managed by an external node, SNMP packets transiting a NAT device may   contain information that is not relevant in external domain.  In some   cases, as described in [SNMP-ALG], an SNMP ALG may be used to   transparently convert realm-specific addresses into globally unique   addresses.  Such an ALG assumes static address mapping and bi-   directional NAT.  It can only work for the set of data types (textual   conventions) understood by the SNMP-ALG implementation and for a   given set of MIB modules.  Furthermore, replacing IP addresses in the   SNMP payload may lead to communication failures due to changes in   message size or changes in the lexicographic ordering. Making SNMP ALGs completely transparent to all management   applications is not an achievable task.  The ALGs will run into   problems with SNMPv3 security features, when authentication (and   optionally privacy) is enabled, unless the ALG has access to security   keys.  [NAT-ARCH] also hints at potential issues with SNMP management   via NAT. Alternately,  SNMP proxies, as defined in [SNMP-APPL], may be used in   conjunction with NAT to forward SNMP messages to external SNMP   engines (and vice versa).  SNMP proxies are tailored to the private   domain context and can hence operate independent of the specific   managed object types being accessed.  The proxy solution will require   the external management application to be aware of the proxy   forwarder and the individual nodes being managed will need to be   configured to direct their SNMP traffic (notifications and requests)   to the proxy forwarder. Also SNMP data isn't encrypted.

That is not how a normal port forward would work, so you must of setup some sort of source nat. Post up your forwards..

ah now i see where the complication starts… i have a dns server on the network, its a web hosting platform for lots of domains and uses IIS which uses port 80 and 443. http://myurl.com is on an apache box. anyways, since i only need to access http://myurl.com:8080 from the host itself every three months (letencrypt ssl renews every 3 months), i just temporarily pointed port 80 to the this ip, and accessed http://myurl.com instead. Then i  generated the ssl certificates and changed it back again. its working now but quite weird... now i can access both http://myurl.com:8080 and https://myurl.com:8443 from within the host. thank you for your time i really appreciated it.

Figured it out. Really stupid mistake. Typo's in configuration.

What exactly are you picking for the option when you set it? If you choose "Add unassociated filter rule" it will make a rule but not maintain the association, so the NAT rule will say "None" the next time you load the rule. Also if the associated rule was made on an earlier version a long time ago before the association code was working properly, it's possible it didn't maintain the association. If all else fails, delete the NAT rule, firewall rule(s), and make a fresh NAT rule using the default associated rule option (leave it as-is), and that should work.

Thank you so much for replying guys. In the end I removed the Load Balancer router from the setup. Now I'm just using one of my VMs for IIS and one for SQL. I had everything set correctly in my opinion. Port redirection etc turned off.  Port was also running on a nonstandard port (444). I do believe browser caching was a problem, because even when I had completely fixed it I still had customers complaining they were not able to login to the website. When I asked them to send the URL to me I could clearly see it was redirecting to port 444. I've now completely blocked port 444 as the first WAN rule in the firewall. But how can I fix everyone's browser cache for that redirection problem?  If pfSense has set clients to bounce from 80>444, everyone will now be getting a 404 error (not good for business!) Thanks Matt

I received an email about Spectrum the other day. It was auto-corrected to Rectum. Glad you managed to complete the nearly-impossible task of getting an ISP to fix something.

I wonder if TP-Link engineers really don't understand VLANs.  I also have a TP-Link TL-WA901ND access point.  It supports multiple SSIDs and VLANs, but the native LAN/SSID leaks into the VLAN/2nd SSID, which makes it useless, as devices on the 2nd SSID often get the wrong config info.  When I complained to their support, the guy I was working with insisted that's the way it's supposed to work.  It was only when I reached 2nd level that they agreed it was a fault.  However, I haven't seen any update to fix the problem. I currently have my eye on a Cisco 8 port switch that's not fully managed, but does support port mirroring.  I may get it to replace my current Cisco 16 port 100 Mb un-managed switch. http://www.canadacomputers.com/product_info.php?cPath=27_1045_349&item_id=037370 http://www.cisco.com/c/en/us/products/collateral/switches/small-business-200-series-smart-switches/data_sheet_c78-634369.html I bet Cisco VLANs work right!  ;)

Hallo, NAT is is working as I described but the pure firewall rule is the problem. I can’t block incoming traffic and at the same time allow this traffic. In both cases I filter the source ip-address. I want to masquerade the source ip-address with NAT rules at the incoming interface. So I could build a firewall rule by the the ip-adress for the firewall (incoming interface) to the destination ip-address. I know cisco asa and for example a genua firewall could do those rules and genua is also a BSD with pf in the background. My ruleset is for example: NAT Forward: rdr on vmx1 inet proto tcp from 1.1.1.2 to (self) port = http -> 2.2.2.2 FW Rule: pass in quick on vmx1 inet proto tcp from 1.1.1.2 to 2.2.2.2 port = http flags S/SA keep state label "USER_RULE: NAT " NAT Outbound: nat on vmx2 inet proto tcp from 1.1.1.2 to 2.2.2.2 port = http -> 2.2.2.1 port 1024:65535 Thanks

Thanks Ace, never knew about these settings. I added 'allowedNetworks' to the xml file to include all of the subnets and boom!!!  Connected….

That's an answer I can work with. The reason for my configuration is what it is, is because I was searching for VPN on server 2012 R2 which was my old configuration and my old router was a home d-link with DD-WRT (wich is my AP now) could not work as a VPN server. So I hade to make it on my server box. So back to my search that time.. I ended up on YouTube whit a video on how to set it up on my server from start to end. And that was on PPTP. An every search I have done afterward have directed me to PPTP. And as a newbie in all this whit now knowledge to other to ask and getting turned away from forums is it hard to work with all this and be better and help others. But now I have some to read up on. Right now I can sort out SSTS because of I use port 443 as HTTPS for my web server. And I just discovered I did the port 47 wrong (new folks you know)