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…

Any errors on the console?

Duh :-[… I thought "(assign)" was how I got into the mess in the first place - created unneeded interfaces - so I hadn't tried that menu item since then out of fear of making it worse... painless, if you don't count embarrassment. -Ted-

Found a couple solutions…easiest one is``` pkg_add -r http://filename

Yes, it looks like it was (is) a DNS problem. Mail server is trying to do a reverse lookup on the source address… which just happens to be one of my public subnets that I'm decommissioning. So the DNS query to the internal server tried to go out and back in to the public server and just kind of dies there. It seems like its just affecting my testing. -Ted-

1.3 has an option to password protect the console menu.