The way I can imagine this setup working is

Internet -> pfsense -> proxy in bridge mode -> lan

Using this way you create a nat from wan to lan web server and your proxy when online forwards it to proxy daemon.

You have the option to install squid on pfsense.

Internet -> pfsense -> lan

Ok, thanks!

I told the spanish user to reedit its Virtual IPs.

http://forum.pfsense.org/index.php/topic,46586.msg246820.html#msg246820

Regards,

Josep Pujadas-Jubany

no, no no…
I didn't have the Access Point in the allowed IPs for the Captitive Portal.
Sorry!

Thanks for this, I found how to have a working configuration on pfSense for my FTP server (on pfSense 2.0.1).

First, I still don't know or understand where the FTP-helper is located. Everywhere in the documentation, wiki, tutorials, the FTP-helper is mentioned under Interfaces>WAN, but I could never see it, and it doesn't appear at all in the web interface. I actually lost hours looking for this damn FTP-helper, and I don't know if it still exists in pfSense 2.0. But I guess I got it working without it anyway.

Let's say my ftp server is on 192.168.0.50 on port 21, using port 20 for ftp-data and ports 5000:5100 as the passive range.
It's Filezilla Server, and I configured it to return the public IP addresse which let's say is something like 80.2.5.42.

First what I did on pfSense was :
NAT inbound
Port forward 20:21 to 192.168.0.50, ports 20:21
Port forward 5000:5100 to 192.168.0.50, ports 5000:5100

with the corresponding firewall rules.

It worked, but not for everybody. Someone couldn't actually connect to the FTP, either in active or passive mode. It worked with the previous firewall we used, but only in active mode.

It looks like this guy was working in a place where a firewall was set up, blocking any traffic originating from port>1024 (I guess to block P2P, etc).

I dumped the packets here on both sides on pfSense (LAN & WAN) and I saw that everything originating from 192.168.0.50:21 was mapped to 80.2.5.42:21, because the TCP session originated from the FTP client on 80.2.5.42:21. But everything that came back from 192.168.0.50:20 was mapped to a random port on 80.2.5.42, and so was blocked by the remote firewall.

Thanks to this thread, I switched the NAT outbound rule generation to manual and added two rules, one to configure 192.168.0.50:20 as a static port and one to map 192.168.0.50 5000:5100 as static ports too, both rules before the default ones, and it looks to work fine now, for everyone.

i get the same, nothing changes if i select openvpn as interface.
i will try to find another solution as it seems that what i am trying to do it's not possible with load balance.
thnx for your help!

sudo,

Have you tried looking at a network trace before?  If you capture a network trace on the WAN while you're trying to connect, you should be able to see if traffic is getting to pfSense (which we expect) and if pfSense is responding to that traffic.  You can do the same on the LAN to see if pfSense is then sending traffic on to your CCTV.  If you need help reading the output, I'd be glad to help.

hello,

You`re right, I found the problem. The ISP denied DNS resolve from the subnet they routed to me, and I have disabled NAT in the pfSense and than server used its own ip address
which was in the subnet which is denied by ISP because that subnet belongs us now… and before I disabled the NAT server used pfSense WAN ip address which ISP assigned to us and than it worked because DNS resolve was allowed from that IP address because it belongs to ISP.

The reason why the Linux was ok is that linux used 127.0.0.1 for DNS lookup it used its own DNS server for resolve...

Thank You again !
Tom

Cool :D

Thanks again

Thank you SO VERY much.  I had noticed that the address wasn't in the first line, and I didn't even look at the second line.

It works great now!  I can't say enough good things about this product to do it justice!

Time to packet capture, start with the LAN on the firewall, filter on the destination host's IP. If you see it leaving there, go to the target server and capture.

Did you tried to use squid package with transparent proxy option?

A rdr rule(firewall -> nat) the way you want could be done setting:

Source: not proxy ip
source port any
destination any
destination port 80
Redirect target IP proxy ip

@cmb:

@marcelloc:

Multiple sip clients registered to same provider +rtp ports behind firewall isn't a nat trouble?

Not as long as you're rewriting the source port on port 5060, as 2.0 and newer do by default.

Is it possible to get a walk through on this? Or can I find any documentation on how to set this up? Im not that good on firewalls so a setup would be handy.
In my case I use an external provider and seven cisco phones on the LAN running through SipProxd and there is constant troubles with the setup and if I can drop the siproxd I think it would be great.

Cheers!

Hi podilarius,

Thanks for the info, I shall try it out over the next few days and let you know how I got on.

yes it's possible via a port forward entry on LAN to redirect the traffic, you'll also need manual outbound NAT configured to change the source IP to the firewall's IP on that interface to force the reply traffic back so it can be translated back.

@Efonne:

For access from outside to work, your associated firewall rule for the port forward probably needs the gateway to be specified in the advanced options.

The 'confusing' part was the non-working status.

Turns out replacement of the motherboard and its on-board Ethernet with a different motherboard now has the config work.

Wasn't amused how pfSense reset the NAT mappings, but at least it was not thick with custom fiddly bits that were reset.

You can use port forwards to redirect traffic in that fashion. One thing to keep in mind is if the traffic is being redirected back out the same interface it came in on, you must use outbound NAT to translate the source IP to the firewall's IP on that interface so the replies go back to the firewall where they can get translated back to the original port, otherwise the destination server replies back directly to the source host, which breaks everything.