"So can pfSense do port forwarding if it's dhcp service is disabled" What would dhcp have to do with port forwarding.. So yeah… As to just working - that would be pfsense..  A port forward is really clickity clickity 10 seconds to accomplish.. Have you gone over the troubleshooting guide? https://doc.pfsense.org/index.php/Port_Forward_Troubleshooting How is it you have wasted days on this??  Port forwarding even troubleshooting to find your mistakes takes all of a couple of minutes.  Does the traffic hit your wan?  Sniff, does it leave your lan headed to where you wanted to forward it?  Does it get an answer back.. Do you devices have internet through pfsense?  Or is pfsense not even their gateway?

To be honest that would be a really really bad choice for a "cheap" camera.. Passive would be a much better choice to have less problems with. Does the camera have sftp support, this would be a much better option to be honest, its only 1 port normally 22 and its SECURE..

Hi there, I just ran some test. I tried the same thing from SRV2 to SRV1 and it's working. Any idea why it is not working from SRV1 ?

Thanks, you were right. I made a mistake with picture, in the gateway and static route, the gateway for network 1.0 is 1.10 [image: nat_rule.png] [image: nat_rule.png_thumb] [image: gw.png] [image: gw.png_thumb] [image: staRoutes.png] [image: staRoutes.png_thumb]

I had to open a support ticket to get this fixed.  Here is the reply from the technician: –----- Upon my initial reading here is what I think is happening: Inbound connection arrives on pf2:WAN3 pf2 forwards the connection to the internal host The internal host replies but its default gateway should be the LAN interface's CARP VIP which is currently on pf1 pf1 does not know what to do with the traffic so it is dropped. The typical work around for this would be an outbound NAT entry on LAN so all traffic going to the inside host appears to come from the interface address on LAN. That will make the reply traffic same-subnet so the default gateway in the target host will not need to be used. The downside is you lose the ability to see the actual outside source addresses in the logs/connections on the inside host. This might or might not be important to you. This turned out to be exactly the problem.  Adding an "outbound NAT" entry solved this.

Ok, that would be if you had some kind of stateless ACL filtering in place on a routing device of some sort that isn't doing NAT. If you have the default LAN rule in place, that suffices for what they're asking for in the NAT context.

Sorry but if it does natting its not an AP… No matter what the manf might call it.. I agree they don't use the right terms.. calling shit modems that also do nat..  Its either a modem, a router or a gateway.  If its a gateway use assume its a modem/router combo. Need to understand what the OP is wanting to do..  I doubt he wants to double nat to his wifi clients..  From what it looks like that would be a triple nat to the internet.

@deucalion: the SIP SDP data layer still contains our private IP.  This will not work for our SIP trunk provider. Unfortunately, it seems that ShoreTel devices can only be assigned IP addresses inside the private IP space. From these two comments it seems that without a go between these two technologies are not compatible.

In your Port Forward definition (image 2) you must specify WAN address as the Dest. Address, not LAN address.  You need to configure it so that pfSense should forward requests from your WAN address to a LAN address inside.  The NAT rule defines where the traffic goes and the firewall rule allows it or not.

Er… dont' install the Squid package. The default firewall rules allow all LAN-to-WAN traffic out by default.

@G.D.: Quick question: can pfSense do this, and what is the best strategy for configuring something like that? Say, I have a whole public IPv4 subnet (with more than one usable IP) on the WAN interface. And I want to arbitrarily route different WAN IP and port combinations to different LAN IP and port combinations. So, a few simplified examples would be like follows (IP addresses are used for illustration only and any matches with real IP addresses are coincidental): 104.40.155.10:443  196.168.0.1:44301 104.40.155.11:443  196.168.0.1:44302 104.40.155.10:25  196.168.0.2:25 104.40.155.11:25  196.168.0.2:25 Sure. Port forwards. In this example the 196.168.0.1 runs an HTTPS web server that serves two different non-SNI websites that are accessible on the two different IP addresses on the wan, but on two different port numbers on the same IP on the LAN. At the same time SMTP traffic on any of the WAN IPs is routed to the one other server on the LAN. What is the best way to make something like this working? I was thinking Virtual IPs and Manual Outbound NAT… Is the port 25, SMTP, example possible at all with pFsense? If not, I can multihome the SMTP server; but I still want to arbitrarily send different WAN IP:Port combinations around the LAN; in other words pFsense 1:1 NAT would not fit the purpose. Thanks. VIPs and NAT Port forwards. No problem forwarding different combinations of destination addresses/ports to the same address/port on the inside. Outbound NAT is used to masquerade outbound connections. You might need something special there for the mail server, but it depends on the actual application. It all depends on the direction of the connection. For instance it would be difficult to treat outbound mail connections from 196.168.0.2 differently. You would have to do something to differentiate them like an IP alias on the host so the source address is different, etc. (If 196.168 is a typo on the inside and you mean 192.168, don't use 196.168)

NAT reflection only reflects traffic matching the configured port forward. Where there is an upstream NAT device, traffic to your real public IP doesn't meet that qualification. That's true of everything that has NAT reflection.

Do you see any errors in the system log for that? Seems like you might be hitting this: https://doc.pfsense.org/index.php/Upgrade_Guide#Microsoft_Load_Balancing_.2F_Open_Mesh_Traffic

HA! You got it…it is a NETGEAR CM600. Anyway for me to determine the IP?  I had looked around a bunch!

No idea….  That sucks.

Anybody??

Thank you all of you that pitched in! In the end the problem was in the Base Stations. Apparantly this is a bug in the upgrade process of the firmware, too much stuff gets left behind. The fix was that after upgrading a Base Station you should perform a factory reset on both the Base Station and the Handsets registered to it. Then configure them both again and all is well. For the people reading this thread that are in a similar postition these concern the XRS/RTX/Snom Base Stations and Handsets (all manufactured by RTX).