When i look at your post-history you kind of wrote this "help me please" without giving infos already twice.

So i write it here for you again:
http://forum.pfsense.org/index.php/topic,7001.0.html
**If you are looking for help on the forum because you have a problem:
provide as much information as possible.
(log-outputs, screenshots of config/rules, etc.)
Often a Diagram (ASCII ART ?) can help more than pages of descriptions how your network is set up.

Before you ask on the Forum:
USE THE SEARCH-FUNCTION OF THE FORUM!**

Send an email to wikiadmin@pfsense.org requesting an account.

CC coreteam@pfsense.org as well, thanks.

What do you mean by no filtering active on the bridge?

What i want to be sure of is that the bridge is forwarding packets to the recipients. In a setup like this it is most likely that some of the devices might not have completed the multicast registration properly. Is this traffic passing across tcp/udp/igmp?!

Well, VLAN'ing is essentially tagging all packets with VLAN information at the concentrator (in this case pfSense). So, it can reduce compatibility, especially with "dumb" network devices like PDAs, printers, legacy OSes, older routers/switches, certain content filters which act as a bridge, etc. It also adds a touch of complexity to the network as a whole, so if you're novice at networking you might want to think consider a few different scenarios. For instance, if you already have switching that will do layer 3, that would be preferable in terms of simplicity. Then the switch would provide routes to each network and to pfSense, and the pfSense would just have to worry about firewalling.

You'll get a lot more throughput switch to switch than through pfSense… unless you threw some monster hardware at it, that is. pfSense uses the PF firewall from OpenBSD, which is really anything but lightweight. It has a lot of sweet features, but they come at the cost of relatively high overhead compared to other packet filters.

Thank You for your help.
Fred

ahh ! thanks

If you are allowed to specify ip adresse it could work with curl.
http://www.dyndns.com/developers/specs/syntax.html
http://forum.pfsense.org/index.php/topic,9729.msg55580.html#msg55580

@ermal:

Are you allowing icmp otherwise you break path mtu discovery?!

Yes, I have tried to let all icmp traffic thru on the interfaces.

Can you monitor if RST packets are being sent by pfsense to the .140 network?

How can I monitor them? I know for sure that nothing is reaching the www or ftp servers.

Are you sure that ssh on pfSense is not running on that port(ssh:22)?

I have tied ftp, ssh and http, and always with the same results.

I swapped hardware as well, I am know using a HP DL145 server with a 4 port Intel Server NIC (we are going to put server to other use in a week or so, I just want to verify that pfsense will work in our environment before I splash the cash on some new hardware). Should be no issues with the hardware this time…

I also decided to go with the stable 1.2 build at this point, there shouldnt be a lot of changes is basic FW rules and NATing from 1.2 to 1.2.1, right?

/jussi

You could just swap the use of the interfaces, however:

Create a rule for LAN2 allowing access to the Interface IP on port 8445/TCP form the LAN2 subnet Under the Advanced Options select "Disable webGUI anti-lockout rule" and save

I ended up uninstalling bandwidthD and it drops back down to about 35. I did ps-A and there were just hundreds of bandwidthd threads going.

Search the forum.
I posted somewhere screenshots of exactly this.

To access test instead of test.test you have to leve the field host empty.

ie:

Host    Domain    IP            Description
              test          1.2.3.4        test

I haven't heard anything yet. You can repost it in another category if you want.

It's a lot easier to maintain one set of filtering policies rather that one for each site.

This is in 1.3.
Well the other way around this is installing pfSense adn doing customization from the shell.
It still IS a FreeBSD system :)

You must have the IP of the VoIP server defined as a VIP in pfSense for that to happen. Don't do that.

Oh! If you are running embedded you will first need to make you os read/write with the following command

# /etc/rc.conf_mount_rw # ...make changes... # /etc/rc.conf_mount_ro

"Gateway" was the key.  Silly of me to forget…

I changed the two hosts' default gateway from the Linksys to the pfSense - for the WinXP I added the Linksys as a second gateway, for the Brother there isn't room.  Both hosts were apparently receiving pings/print requests/whatever, but didn't know how to reach the sender with a response.

And yes, I added rules up the wazoo: my network can talk to those two addresses but nothing else on their network, and only those two hosts can talk to my network.
It could be defeated by unplugging either host from their network and replacing it with a rogue machine with the same address; for the moment, however, I'm satisfied.

SOLVED: I got MSN working again after I allowed traffic from LAN to 1863 TCP port.

Thanks…