@dhoffman98 said in Defining restricted dynamic ports for outbound NAT?: Then when the remote site responds back to the firewall, it sends its traffic on 5060, and then Snort intercepts it because it's on the SIP port and the pre-proc tests it for SIP rules Not sure if that is really the case, but yes, you can add an outbound NAT rule to translates the source port in case of 5060 to another one out of a given range. That is one of the things outbound NAT rules usually can do.

Seems to only affect things with ALGs, and pfSense doesn't really have any ALGs except for the FTP proxy and siproxd but those are more like proxies than ALGs. Too soon to tell 100% but likely irrelevant to pfSense. If you're worried, remove the FTP Proxy/siproxd which you probably don't need anyhow.

So you have a server say 10.130.101.42/23, what is it using for its gateway? Using 10.130.50/29 as a transit network is fine.. But how are you setting up gateway? You wouldn't put it on the interface.. You would create a gateway under routing, and then setup any routes to downstream networks. Here is a logical diagram.. with a downstream router.. So its easier to read [image: 1604152476500-logical.png] Lets assume you have all the VM stuff setup correctly for the different L2 networks and how things are connected.. So what IPs your using on the VM host have nothing to do with how this traffic would flow. Keep in mind that once you create gateway pointing to your downstream router this .3 that is on say the lan interface of pfsense. You have to adjust the lan rules to allow these downstream networks. Since I assume your downstream router is not natting. Once you create the route for the downstream network 10.130.101/24, pfsense if using the default automatic outbound nat would add this downstream network(s) to your outbound nat.. Did I draw this correctly? Lets just deal with 1 downstream network, this 10.130.101/24 for now.. On a side note - I personally don't like using a transit network that could get confused with your actual networks... If you are going to use 10/8 for your networks, then use say the 172.16/12 or 192.168/16 space for your transits So vs using this 10.130.50.0/29 as transit, say use 172.16.0.0/29 Hope that helps.

@viragomann said in Outbound NAT with IP pool: @stebbo said in Outbound NAT with IP pool: Do I need to add the .97 as a virtual IP? Exactly. You have to add this address as type "IP alias" to the MGT interface. Otherwise there will be no communication possible with that IP. Hi viragomann, thanks for the response. I have since discovered my problem, it seems the IP address I picked was in use elsewhere on the network (undocumented of course). Once I picked a free IP address it's all working as I had expected. Many thanks, Chris.

@uz890ed said in NAT virtual LAN IP -> LAN-IP on different Port: I know this is possible using HAproxy but I want a direct connection if possible. That not possible. You cannot access the destination host directly this way. You're calling the pfSense's virtual IP, so that's not directly. pfSense may forward the packets to the destination host, but responses will go back directly to the requesting host, so will you have an asymmetric routing. You can use NAT reflection instead. However, that will also be not directly, access will come from pfSense, same as with HAProxy. Best pactice is accessing the services by host names and set up host overrides for it.

Thank you, now its working

Thanks for the reply. This same issue is actually seen on another post of mine. https://forum.netgate.com/topic/156619/how-to-restrict-openvpn-traffic Never did find a cause but will likely end up rebuilding which hopefully will solve the issues. Cheers!

@viragomann said in NATing when the destination address is in my subnet/IP space: @sparkman123 said in NATing when the destination address is in my subnet/IP space: So if I were to make the dest address be something like 172.16.1.10, the NAT rule fails. You have to add that IP to VLAN20 interface as type "IP alias" if you want to use it in the NAT rule. If it is not assigned to pfSense nothing will happen. Thanks. Using a virtual IP made this work.

@vacquah said in Understanding port forward 80 and 443: Is there any risk to opening 80 and point it to the freepbx server or kubernetes cluster ? You are relying on the security of whatever is listening on port 80 on the freepbx and kubernetes cluster in that case.

@helper @kiokoman Thanks for the help guys, i really appreciate it.

@edicastro said in Nat reflection dont work with squid: pfsense + squid is much problematic Yeah,.... basically pfSense is well configurable, Squid is just an option Squid is hard to configure everywhere these days, just think of evolving HTTPS

In what interface is it comming in ? Wan or local ? Do you only need to direct it to a specific service (PORT) , Ie. like HTTP/HTTPS ??

@SimpleTechGuy said in How to route rfc1918 private ip on WAN net to IP on LAN net: pfsense is actually a virtual machine on the kvm. Got it set this way so I still have internet to kvm and can reboot remotely the pfsense if something goes wrong. Mine runs on KVM as well. It gets the public IP via PPPoE and does the whole routing stuff here. It does its job for almost three years now this way without any trouble.

@jmcdiarmid_uk said in Passive FTP Server: What is the easiest way to do this with pfsense? The FTP server should be part of the 'network above' pfSense, somewhere in the WAN address range. Typically, by using a ISP modem, as these expose the WAN IP on device behind it. Check out the how a passive FTP is set up behind a NAT : it's a FTP server settings option. Nothing special has to be done the NAT (pfSense) device, except the port range NATting. If your passive FTP server does not have this option, it is completely useless behind a NAT, and can be accessed only from it's 'LAN' .

@Derelict Thank you. When I replied, I didn't have access to the device, but looking at it now, if I'm understanding everything correctly, I changed the Interface setting of the Pfsense Packet Capture from WAN to OPT, which is the the port the server is plugged into (as labeled on the device and afaik I have not changed the label anywhere in software). This yielded no traffic. However, when I check the LAN interface, I can see the expected traffic. So I guess that means it's making it past the firewall successfully but may or may not have a route to the right place. As I noted in my OP, I did move the OPT interface to be on the same VLAN as the LAN interface (so I can access the server by direct local IP from my internal network - works fine). I am in the process of double checking those settings. Also still going over the Troubleshooting guide linked above.