Ok, it's IMspector which blocks my msn connexion… but how? with the previous setup, imspector was running fine... now as soon as i activate it, impossible to login to msn, neither to log the conversations on msn... is the package still working? How do i reset totally the Imspector config?

Well if there are any rules below it that would allow it out, then they would apply first. (Like the default LAN allow rule.) A quick way to test would be to put a block right beneath it with the same source IP and turn on logging to see if it is blocking. p.s. if you are limiting the clients to the same number of connections, one rule would cover that. simultaneous client connection is per source IP. So a rule with a 50 simultaneous limit from any source would allow 50 connections from each client.

RST packets have no payload and hence no port. I am far from an expert but based on my reading of the Snort documentation Snort is able to detect the RST flag and alert, you may be able to configure a combined rule in Snort to achieve your goals. I don't know enough yet to tell anyone how to do it though …. but I am working on it. You may want to check out page 129 of the Snort user guide. http://www.snort.org/assets/82/snort_manual.pdf My guess is that you could let Snort deal with the RST packets and let pFSense handle the rest, I can't think of a valid reason to accept an RST incoming anyway.

What is it really you wanna do to the Rules? jigp Davao City

Is it okay now ? jigp Davao City

Hows it working mabbus? Be sure your NAT is doing okay. Also try restarting firewall. jigp Davao City

http://forum.pfsense.org/index.php/topic,15689.0.html

thanks

I know this post is pretty old now, but it sounds like the computers in your various LAN's do not have the correct IP configured for their gateway.  Each computers needs the interface IP's it's connect to as it's gateway.  Listing anything else for the gateway would yield the results you're stating.  It works with NAT because the ping get's NAT'd to the interface IP first, then sent out so the reply only needs to come to the interface IP, not route through it to the other LAN segment. Using NAT like this can actually be useful for reaching devices on other LAN subnets when you can't specify a gateway.  Some wireless AP's for example permit you to specify an IP, but no gateway.  Setting up a NAT temporarily lets you manage them from another LAN subnet. -Rich

Thanks, now it works!

How much of this info is safe to put here and how much is of use to potential hackers .. ?? There is no 'X' by the notifications … using pfctl I have identified that rule 73 reports this @73 pass out quick on re2 all flags S/SA keep state label "let out anything from firewall host itself"   [ Evaluations: 0        Packets: 0        Bytes: 0          States: 0    ]   [ Inserted: uid 0 pid 58951 ] pass out ?? - re2: ??  so where is block on lo0 (that I now know to be loopback) related to this ??????? The interface identified in the rule 're2' currently has NOTHING connected or defined,  plus the rule says pass - not block. Since lo0 is loopback the only machine that can be looping back is pfSense itself (127.0.0.1 is assume) and yet the IP address in the block is one on the local LAN. loopback = "{ lo0 }" lan = "{ re1 }" ng0 = "{ re0 ng0 }" wan = "{ re0 ng0 }" enc0 = "{ enc0 }" OPT1 = "{ re2 }" OPT2 = "{ em0 }" User Aliases I appreciate the pointers though because I identified one other issue too in that the system has decided (and don't ask me how) that one of my internal subnet IP's is on the WAN so it is refusing any packet from it even on the local LAN nic re1:, when I try to resolve the affected machines name the pfSense fails, ping fails because pfSense blocks itself (bit stupid). I found out why though - it is the manner in which pFSense is resolving names. pfSense seems unable to resolve using the private DNS server that I run, ther eis no way to tell pfSense that it should use LAN for DNS resolution. If I put my DNS server IP address in the system > general setup > dns servers box the internet access is broken, pFSense tries to use it to resolve only on the WAN re0:, if I leave the DNS boxes empty my internet connection is broken even with DNS forwarder disabled. My private dns server has root hints for openDNS but I don't WANT or need the pfSense to get involved with ANY kind of DNS resolution but the only way I can get internet working though is to put the public (openDNS addresses) in the boxes in pFSense. My private DNS is configured OK because if I turn off packet filtering (turn pFSense into a bridge) I can resolve anything perfectly fine so why can't I force pFSense stay out of DNS resolutions and keep my internet working.