IMHO uploading a changed config.xml requires a reboot. I tend to believe that current sessions will be cut then.  :) Another route to go might be the centralized management interface that popped up as a bounty several times already and never was finished. I think it's withdrawn but look in the bounty section.

Try the search function ;)  This has been discussed many times and details can be found in the forum (hint, look for squid.inc).

Yes bridge is the right word. It's actually workign now. Many thanks

Oops, my crystal ball is broken too -((( It looks like epidemic… iamthed, it's not about your English. It's about the information you give us. And if when you "discard pfSense" everything works fine why do you need to use Firewall? my boss told me that's must be a firewall error because when i use sniffing from router. the IP come from firewall WAN interface not from the client IP ( he thinks it's a proxy, i have a proxy but i'm not using transparent proxy and i never setup browser to client so it's cannot be proxy) you (and may be your boss) should probably read about NAT. Don't get me wrong there is no intention to be rude to you but it's impossible to give you an advice.

Yeah, that's OpenBSD. We're using the FreeBSD port. I wouldn't hold my breath, we don't even have carpdev yet…

Thanks for information Have a nice day D

yes. See the howtos on http://doc.pfsense.com

About the same: http://doc.pfsense.org/index.php/Logs_show_%22blocked%22_for_traffic_from_a_legitimate_connection%2C_why%3F

When dealing with port forwards, the destination IP is always the "internal" IP address, never a WAN address. The rule still goes on the WAN tab though. And with traffic coming from the internet, you never need to set a "source" address, that is not rewritten anywhere, and will always be the original IP. As I mentioned in the previous message, you did not have the correct firewall rule in place to allow that traffic, which is why it was being blocked.

I fixed the problem. I reinstalled 1.2.2 and made sure my LAN ports were getting public IPs from the modems. I think double NAT was killing stuff.

@jahonix: What does the firewall log say? Activate logging for the pass and block/reject rules in question. Those are good items to try and test out.  What I had in mind was why you're having difficulty in getting port 987 to work.  One item to try, from a remote computer, is to telnet to the WAN ip address on port 987 to see if it connects.  This why you can eliminate the possibility of the ISP blocking port 987 for whatever reason and look at other issues.  Using the logging feature of the port 987 allow rule would also be good to using in combination when testing.  Then test as your normally do when you connect through Firefox to see what happens. Good luck…

We are all people, that is why we have different opinions -)))

@gollo: Yes.  I have a webserver on the inside and those NAT rules work fine. The firewall is working as advertised.  It drops traffic if the port is not open.  But since port 80,443,ftp is open it allows all traffic on those ports to the webserver.  What I want to do is block a single IP from accessing anything so I put in a deny all rule at the top of the list and it doesn't work, the user can still access everything. Thanks for the response. Could you please check: Specify the source IP as 'Single host' and give us pfctl -sr | grep <wan_interface_name>2) Specify the source IP as 'Network /24' and give us pfctl -sr | grep <wan_interface_name>3) Specify the source IP as 'Network /32', check if it works and give us pfctl -sr | grep <wan_interface_name></wan_interface_name></wan_interface_name></wan_interface_name>

is this for a nat'd web server your hosting? if so you probably need to turn on nat reflection