No, you gotta tell the box on 127.20.0.4 to use pfSense to as a gateway so that it sends back the requests coming from the port forwarding back through the machine it came from. Alternative would be to enable outbound (src) nat for all packets going towards .4 port 6540 to the firewall's IP. that way you're on the same subnet and .4 doesn't care. The downside is that everything comes from pfSense and you do not know the real IP that tries to access .4. cu

@muppet said in Error Loading Rules - Only when using an Alias in NAT rule: here I've created a bug report for it I'm getting the same in 2.4.4 p3 and 2.4.5-RC, trying to do the same as you with redirecting DNS

Ok thanks, will file a bug report :) I tried fresh installs of 2.4.4 p3, 2.4.5-RC and 2.5.0 in Virtual Box just to confirm it isn't unique to my setup

My problem was Inside DNS was pointed to the internal IP address of my router where it should have been pointed to the outside.

Delete all the rules above and create a port forwarding rule: Everything that hits the external interface's IP on port 5060 is forwarded to the PBX on 5060. This should give you the main connection. Then check the udp port range the PBX uses for actual communication (RTP). Forward those ports as well from external IP to the PBX. If the RTP ports cannot be nailed down to reside in a certain range, check if the PBX can use a STUN server and if your provider offers one. If so, the PBX connects to the STUN server, does a handshake when it comes to ports and then uses those ports on the firewall (punches holes in the state table for said udp ports) and keeps them open and alive.

Explain "Point to the same LAN network". Nat? Routing? Brouting?

Tell your AP how to reach the other subnet via routing. Or just set the default gateway of the AP to be your pfSense and everything is fixed. On the other hand you can setup some outgoing NAT on the interface where the AP is connected to like: nat on $lan from $opt1_network to $lan_network -> ($lan) So that you source nat everything going out on the lan network's interface coming from opt1's subnet to the IP of the lan_interface.

Are you testing from INSIDE the same network where the cameras are running? If so, enable the NAT-reflection option that does NAT + PROXY. I explained NAT-reflection in a different context here: https://forum.netgate.com/topic/139457/transparently-intercept-and-redirect-dns-traffic-to-an-internal-dns/14 Cu

Glad you got it sorted - you really need to state up front what your using, be it hardware (make and type) or if your running on VM, if so what virtualization your using.

I see why mine worked. I had manually set an external address, which bypasses the check. If your actual WAN address is static (or reasonably so) you could set that in the UPnP options as well. It doesn't look like the miniupnp folks are budging on it, and it isn't a recent behavior change: https://github.com/miniupnp/miniupnp/issues/298 -- Their "solution" is to let it use a STUN server to determine the external address, which is still not ideal.

Did you have to make any other changes? I have the same setup and can send a request from the private subnet, via pktcapture I can see it get through the LAN interface, out the WAN and the response back, but the client never gets the response back through the NAT.

While using pfctl to view your rule set can be a valuable tool, looking at /tmp/rules.debug can be much more straightforward. You would also have the benefits of things like comments that would immediately show you that you were looking at NAT Reflection rules.

A long shot. Have you checked that all ports are open in the local FW on the windows server? If you are on the same network when you test internally you probably ain't using NAT-T so those ports might be closed

@james416 said in Port Forwarding Multi-Wan Issue on 1 Wan: BellFibe is the default Gateway Yeah.. That would be something to post in bold in your case.. I wish ISP's would get a clue..

I take it these .2 are vips you have setup. What is the source of this traffic? Is it rfc1918 in your network - or public being forwarded to pfsense rfc1918 wan IP? Why do you think you want to do this? What do think it will accomplish exactly? But sure you could outbound nat into your lan from your lan vip.

@yanafig Do you need the mikrotik router between the ISP modem and the pfsense box? You are probably having a double NAT problem right there, and if your ISP modem supports NAT, maybe even a triple NAT problem... yikes! The best way to do this, if it's possible from your ISP, is to setup the modem in bridge mode, put the public IP address from your ISP modem on the WAN port of pfsense, then do all the port forwarding on the pfsense box. Works almost every time, unless your ISP does some funky stuff upstream on their network. Jeff