That's policy NAT, you can do that in 2.0.

I thought about this, but I'm not sure wether it'll work. But since the firewall part also works with bridging, I see no reason why it wouldn't work. Apart from it being theoretically possible, why would you want to perform NAT on public IP's?

Hey you didn't waste my time. I appreciate the help!

@cvantassle: I have an ftp client that is on my lan. I have to connect to a remote ftp-server that only will accept active ftp transfer. I was wondering if there was a way I could setup PFSense to operate a transparent Active FTP proxy? The FTP helper is an FTP proxy. If you have the FTP helper enabled on LAN, it should work. You can do a packet capture on WAN and LAN to see if the port is being translated correctly, and check the output pf ps from the console to see if pftpx is running.

Hi @ll I was able to reproduce this too meanwhile. I agree that both features should be working at the same time as the CP is a really brilliant feature Does anybody know if the developers are working on this ? cheers thafener

Sorry, but this is a little too vague and confusingly worded.  Can you clarify?

Sorry - I misspoke - you may need virtual IPs, if you're doing the equivalent of "1:1 NAT" on your modemrouter - and have multiple virtual IPs in that same private address space on your pfSense box WAN.

Thank you, it works. Operations : Go to Firewall –> NAT --> Outbound Check Manual Outbound NAT rule generation (Advanced Outbound NAT (AON)) and Save A new line appears with LAN Subnet, click on the edit button and Check the first box to disable NAT : Enabling this option will disable NATing for the item and stop processing outgoing NAT rules. Click on Save and Apply Changes.

Ok, thanks. I did it through NAT, but this copies across to the firewall rules anyway. I have deleted the NAT entry which should have left the firewall rule?  I can no longer access the GUI remotely now, so can't alter anything else until I am back on site!  Whoops!

Problem solved. I didn't mention that the server running Filezilla is Win2003 DC with RRAS enabled. It seems that RRAS has some kind of FTP helper/filter too, and it must be playing with IP addresses. I tried a few different FTP softwares, and the result on this particular machine was the same. I didn't want to waste any more time on this, so I just moved FTP server to another machine without RRAS. No more problems, passive works as it should.

Here's what I have so far based on the advice you have all given: LAN is configured as vlan0 (192.168.0.1) (VLAN ID: 1) OPT1 is configured as vlan1 (192.168.1.1) (VLAN ID: 2) Server is assigned 192.168.1.2 and has 1:1 NAT to a public ip address. OPT1 Firewall rule:  DENY OPT1 -> LAN OPT1 Firewall rule:  ALLOW OPT1 -> any Does that sound right?  This allows my private LAN to connect to my server (using it's internal network address [192.168.1.2]), but denies connections from the server to my LAN.  I'm not sure how safe this is but seems like the correct method for what I want? (NOTE: I don't need to connect to my server using it's public ip address.  I only need to be able to connect to it from my LAN).

OK, thanks jimp.  Will stay with conservative.

cpanel outsite from LAN. i try to using bypase from firewall and i can't login just using normal router modem.

Thanks overrand, If I am going to setup 1:1 NAT do I have to remove the Port Forward that I was previously setup for this specific External IP ? Also how do I setup a firewall rules on 1:1 NAT?

Actually, it sounds like cyanatide means that the web server cannot be accessed by the WAN IP from internal hosts.  The usual behavior for this would be that it would end up at the web server on the pfSense system rather than the web server the port forward would redirect to.  NAT reflection probably has not been enabled yet. cyanatide:  Do not enable NAT reflection without changing the external address field on your port forwards to something other than "any" or you will lose access to the web GUI on the pfSense box and to any external systems on those ports, as it will end up forwarding all connections on those ports to your web server (on 1.2.3 or earlier).

i figured it out the qwest people told me the wrong ip range 67.40.148.249-253 its supposed to be 67.40.184.249-253 i noticed it when i was looking in the interfaces wan section lol. thanks for your help

Thanks so Much guys! I appreciate it. I will take your advise and well appreciated for your opinions.

It's a limitation in the underlying firewall software, but it's also considered a best practice to keep such a server in a separate trusted subnet away from untrusted clients.