Sounds like that's what I want kpa - you're probably right about it being a /29 too, was just before hometime yesterday so I did it quickly instead of checking it out properly! Will give it a shot later on when I have a minute spare.

good tip…. had the book on my desk and did not look at it  :-[ thanks for the rtfm... ;)

In the web GUI of the local pfSense box, select Diagnostics -> Packet, select the LAN interface and enter as the host address the IP address of the destination system for a VOIP call and enter the destination port number for the H323 call (the people who support your phone system should be able to tell you that). Then attempt the call. You should see something in the capture. If you see only a single packet (no reply) then repeat on the WAN interface to make sure the packet goes through the pfSEnse box. If you see nothing then check the firewall logs to see if the packets is being blocked by the firewall, check the phone to make sure its routing correctly etc.

IMO everyone helping out a lot on a forum will after a while start ignoring the threads where the asked questions are selfexplaining (aka. read the description in the GUI) or explained in the howto's.

Thanks , That is what I have been doing, I edit out all the squid configurations and upload the file. After witch the system re-installs all the packages when it reboots. I find in my case that rebooting the system as soon as the packages re-install is a must. It only bothers Squid all the rest are fine. I also  deleted Squid's own configs from shell and restarted because they would not let me change the settings.

thanks. :)

leaded, I think if you follow clarknova's advice you may be able to narrow your issue down to a single point. Also a suggestion is to reset the modem when you change firewalls or even install a new os on the same firewall hardware.

Do you have pfSense set for dial-on-demand? Also, this bit: rec'd Terminate Request #38 Seems to imply the connection is being torn down deliberately for some reason, possibly from the ISP end.

They are already dropped after a period of inactivity. Under the advanced options, you can set this so there is a more aggressive timeout (the firewall optimization setting). If something is not being dropped, odds are it has some kind of keep-alive protocol happening that you don't see. Some things like IRC have constant client-server communication that is hidden from the user, so you may not see a message from a person in hours, but the connection is still technically active.

Polling doesn't buy you much on an ALIX anyhow :) That is how polling works, though, it uses all available "idle" CPU time to poll instead of waiting for interrupts.

Ok. Thank you.

Why did you remove the auto-created rule?  That wasn't what I said.

Thanks, that's exactly what it was. My static mapping wasn't setup properly. I left 192.168.2.10 in the range of the DHCP pool and it was assigned to my IPOD touch. It's all setup properly now. Thanks!

There should be some UK companies that make rackmount servers using Supermicro boards.  That would be my first choice since they tend to integrate dual Intel NIC's. A quick Google search brought these guys up on the first page: http://www.sentralsystems.com/superintel.html I have no idea how good they are.  But given the choice between a Dell or a Supermicro with Intel, I'd choose the latter.

This is "normal" DHCP traffic, where Comcast is responding to a request for a lease, which could be any computer connected to the same head end as you. Cheers.

As I said, no suggestion should go untried, so I dd'ed the pfSense nanoBSD image to my SSD. And basically it works fine! However, even if the / filesystem is mounted read-only (RO), it seems to be mounted read-write (RW) every now and then. I notice a lot of calls to conf_mount_rw() in /usr/local/www I guess this works nice with a CF card: In general RO, but when needed RW. But the root filesystem is thus not truly RO. So in "my" case it does not work as needed… I might play around a bit and try to mount /etc from a different partion etc...