@doktornotor: @pfguy: @doktornotor: Dude, you are connecting to where the server does NOT exist (your WAN). It's not about allowed or not. It's about pointing to WRONG place. What do you mean by pointing to the WRONG PLACE ? Nonsense! Its an internet address Ugh… You just don't get it. It's NOT running on your pfSense box. Don't point clients there on LAN, simple. Point them to LAN. Stop playing ping-ping with packet headers. There's no need for the traffic to ever hit the firewall box, at all. (BTW, most "other firewall" just don't have any NAT reflection at all...) ok, fair enough.. argument accepted ;) thanks

That worked!  Thank you so much for the help.

So if all users are using such programs then all users would bypass the port 80/443 then all users can bypass the proxy, this is not a good option. Like I said, your rule would only allow 80/433 out from particular users to specified destination addresses, like the update, authentication or control servers that these apps want to talk to.

Because the underlying OS (FreeBSD) doesn't support routed IPsec at the moment, I don't expect pfSense to perform miracles.  (the irony is JUNOS is based on FreeBSD, but they obviously have other things under the hood) Routed IPsec is what connects all of our branches, corporate main, admin centers, and colo together.  Without it, we're dead in the water. I have been wanting to experiment with pfSense for quite a while but didn't have the opportunity.  While I couldn't use it for new offices (due to no routed IPsec), this office was different because I had the old Juniper to open a tunnel to the rest of the company from inside the LAN.  Unfortunately it didn't work out because the tunnel would not stand up behind NAT, no matter what I did. Even if it did work, it would be limited to this one location.  New locations will still need a Juniper for routed IPsec. Although my time with it was cut short, pfSense seemed like a really nice product.  If FreeBSD bakes in routed IPsec support, or if the pfSense developers can build it in themselves, I'll definitely have another look.  I like the idea of running on an open source platform, not locked in to a specific vendor. I also like that the pfSense folks sell commercial appliances with custom images, as well as commercial support.  We keep all of our devices under vendor support contracts.  For this test, I was using a new HP ProLiant server– one of our hot-spare chassis we keep on hand for emergency swapouts-- so we'd spend money either way.  Whether we buy another Juniper, or a server chassis + pfSense, or a pfSense appliance, it's still not free.  I would never run a commercial environment on freeware without paid support.

Found the answer here: https://www.raspberrypi.org/forums/viewtopic.php?t=83119&p=589426 "I figured out the issue. Its related to a "bug" within pfsense (or maybe freeBSD). In order for the firewall its self to use services from the other end of a vpn tunnel you need to put a static route into its routing table I had a static route in it for 10.1.2.0/24 gateway 192.168.131.254 on the lan interface. I had this route in there because I was testing ldap auth and also for snmp on the internal interface from the other end of the tunnel. Once I disabled this route, I was able to ping to the other end without the redirect." I added a static route and now the Linux machines are happy.

Should be fine.

I did get this working now in version 2.2.4 after doing a lot of packet captures and troubleshooting.  I have another different virtual IP address setup for IPsec and L2TP (both enabled) on the pfSense box itself.  When I disabled those it started to work. This leads me to believe that there might be a bug is IPsec & L2TP services on pfSense.  When enabled they will not forward udp port 500 traffic on other virtual IP's.  Once disabled they do pass the traffic.

Access the system BIOS (F2 during boot, after POST) and inside the Power menu there's an option "After Power Failure". Set it to "Power On" to keep in on all the time from the moment it's plugged into a power source. Or "Last State", so the system returns to the state it had before the power failure, that could be on or off.

I'm thinking it may be a KVM issue

Glad you got it sorted.  When looking for help always talk about the network connected to the WAN as a WAN. People around here cannot read minds! (No matter what they tell you)  :)

Huh??  Why do you have the same lan network on pfsense as your production network?? You have 30.0/16 on your production network and then you show 30.0.0/?  This would overlap.

i was about to post a conclusion to this thread to thank @johnpoz for his valuable help !! Anyway, all the experience in this thread was already stated in the post above by the original problem solver @johnpoz. thank you so much @johnpoz and everyone else who have replied in this thread.

Did you go through the port forwarding troubleshooter.. Just logged into a guy to help him out and he had captive portal enabled.. Yeah that keeps stuff from answering ;) https://doc.pfsense.org/index.php/Port_Forward_Troubleshooting What concerns me is you would even attempt to swap the ports - that tells me not really understanding the process at a basic level.

That's all there is? Nothing being NATed there, which means your port forward isn't matching the traffic. Given the source and destination is fine, maybe it's on the wrong NIC? Needs to be on the source interface of the traffic.

Oh, I thought you were testing externally like your friend.  If you're on the same network then you can't access it using it's public name or IP unless you have NAT Reflection enabled, or are using internal DNS that resolves the host to its LAN IP address.

The only way that sort of setup will work is if there is an additional firewall on each leg doing the extra NAT. As the others said, you can't have the same subnet on multiple interfaces in that way. Not only does it require NAT like you show, but that NAT has to be performed by something on the other end of the lines. If each of those additional sites had their own firewall and the "main" pfSense unit only saw your 172 subnets that would work fine, but something has to be in place to ensure that no one device sees the same subnet on multiple interfaces.

tanks for your answer i will try and let you know :)

removing the limiters is worth a try to confirm or deny whether that's the issue. The bug in question is https://redmine.pfsense.org/issues/4326 In most configurations, that only applies to using limiters on WAN rules. Where you're using reflection that's more complicated as you're doing NAT on LAN and there are more possibilities for that to apply.