Hello Scott,
thanks, i will start a bounty.
Greetings
Heiko

I have now done a firmware upgrade to 1.0.1-SNAPSHOT-03-08-2007 built on Thu Mar 8 22:18:35 EST 2007

and the issue is now gone :D.

Strange íf nothing was changed.
A big thanks to the new snapshot :).

hi

you are right about spoofing, but how many clients knows this? my clients arn't aware of networking, phisical security with wirless, how? mac filtering is a good option for the time being

hadi57

You probably want a bandwidthmonitoring package like bandwidthd. It's available as pfSense package. Search the forum or have a look at system>packages in the webgui.

@sai:

Allow TCP 10.5.5.9 25 (SMTP) * * *

is wrong, I think.

If you want this to allow your SMTP server to send out emails, it should be

Allow
Proto:TCP
Source Ip:  10.5.5.9 (if this is your SMTP servers IP address)
Source port: any
Destination ip: any
Dest port: 25 (SMTP)

This rule should be on the interface that is attached to the SMTP server, not the WAN

Ho works with the default LAN to any rule, so this rule is not needed. He only needs the portforward and the autocreated rule. But first he should clean up all the other rules. There was just a basic misunderstanding how pfSense firewallrules work. I hope I explained things well enough to get it going now  ;)

@mentalhemroids:

Well crap… okay, I guess I'm stuck with it.  I would assume they are a trusted site, but I'm not wanting to take any chances.

Thanks for your insight.

Well no, its not coming from a trusted site.

Parent:    NET-169-0-0-0-0
NetType:  IANA Special Use
NameServer: BLACKHOLE-1.IANA.ORG
NameServer: BLACKHOLE-2.IANA.ORG
Comment:    Please see RFC 3330 for additional information.

see http://www.faqs.org/rfcs/rfc3330.html

169.254.0.0/16 - This is the "link local" block.  It is allocated for
  communication between hosts on a single link.  Hosts obtain these
  addresses by auto-configuration, such as when a DHCP server may not
  be found.

When a PC requests a IP address using DHCP , and then does not get a response, it is supposed to be assigned a 169.254.x.x address.

So the packets are coming from someone who needs a DHCP server, not IANA,

Your probably already know this, but anything ssl over a load balanced connection gets messed up unless you tell all ssl protocols to route out only 1 of the interfaces.  Just FYI if you are load balancing

We need more details about your setup. Is the trafficshaper at interfaces>LAN enabled? Are your running a multiwan setup?

hi

i tried the method of installing squid and put the isp proxy in the upstream, and the the user name and password issud to my by the isp to access the net, started to appear to clients connected to the pfbox

thanks

hadi57

My experience with Incredimail is that it contains spyware, so that might be part of the problem.  Snort may pickup on that.  I don't recommend that people keep that program on their computer.
I would use Thunderbird from mozilla.org as your email client.

Oh got it. thanks.

But i still unable to ping the secondary pfsense LAN IP address althought is the latest snapshot - 02-21-2007. will able to ping only after i reboot the secondary pfsense again

No, if enabled, this option is active for everything.

@hoba:

This is not doable unless you have 2 public IPs and resolve each hostname to one of the IPs. You then can use a virtual IP for the second host and forward it to a different location.

Hi Hoba,

thank you for your reply. Yes, I have 4 external IPs. So that makes my live easier.

Regards,
Alexander

You must have some invalid configuration. Never seen something like this before. Try restarting from scratch and recreate your config step by step and test in between the steps.

Lots of things are similiar at the frontend though the backend handles them different (like different filter mechanisms). That's why some of the options shown when editing a firewallrule are different for example. However the "basic concept" is pretty similiar, at least when talking about basic NAT and firewallrules.

the ngX interfaces are the PPTP tunnels. Each user has it's own interface when connected. Make sure you used protocol "any" in your pptp firewallrule instead of the default "tcp".

Try upgrading to the latest releng snapshot please.

I am working on this right now for HEAD version. I'll keep posted how my progress goes and when it will be available in releng.

I would be grateful if you get some documentation together.  I'm stuck getting the rules right so packets actually get sent through the tunnel.  I would love to start over and try again.