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...

The only way to do this would be with a proxy of some kind. Squid would work for HTTP transparently, but not HTTPS. If you want to do that, the clients would have to either hardcode the proxy settings or you could setup WPAD and they can use proxy autoconfigure. Even squid won't get the MAC address, though, just IP, date/time, and URL. Even if you could write some sort of DPI tool that would log URLs, it would still only work for HTTP. Another way around this is to give all your clients public IP addresses (which may not be feasible), and then just keep a record of who was assigned which public IP when (PPPoE would help you here, if you forced auth). Squid shouldn't be too bad performance-wise if you don't really have it caching, just logging.

Just add rules above that firewall rule to block access to the networks you don't want to be accessed.

Just to elaborate on the previous reply because the question didn't make the context plain. TFTP on "local" subnets (routing between source and destination but not NAT) shouldn't be any problem. TFTP through NAT (e.g. to Internet) requires a TFTP proxy as discussed earlier in this topic.

Hi, well I finally got everything working (regarding the VLANs) and I was also able to determine what went wrong. I'm now running a dedicated machine for PFS and ESX is on its own. My first mistake was that I wasn't sure what access or general port was on the switch and my second was that first I didn't set the port that contained the VLANs as trunk. So after I created VLANs on PFS and attached them to the OPT1 interface (interface is used only for vlans) and set the port this cable was connected to on the switch as trunk. I precoded to tag this port on every VLAN I needed on the switch and added access ports to the appropriate VLAN. It started working right away without any restarts or reboots of PFS or the switches. Now the ESX is a bit of a different story. For the VMs on the ESX I created a virtual switch, each with corresponding VLAN tags and connected it via trunk to the switch. Then I added the VMs to the appropriate virtual switch and changed the IPs on them and everything started to work as it should. I'm still not sure if I could have set the virtual switch to 4095 and setup VLANs on each VM separately, but since it's working it doesn't make much sense to start medaling with it now.  :) Anyway thank you all for your help and I hope that anyone with similar problems might benefit from this information here. I'm also attaching a diagram of my network topology for reference (sorry but it's not very good, but I think it illustrates the network). By the way for example if I have setup OPT2 as a second LAN and it is working what happens if I attach a few VLANs to the same interface as OPT2 and then set the port on the switch as trunk. Will OPT2 still work and fall into the default vlan on the switch 1 and all other VLANs to tagged the appropriate VLANs. Would this work? It works the ESX any non tagged traffic falls into vlan1 on the switch. Or is it a better idea to leave only VLANs on the PFS nic without the non VLAN traffic? And when you attach VLANs to a nic in PFS is that nic automatically marked as trunk? Bye [image: network_diagram.jpg] [image: network_diagram.jpg_thumb]

If you're on nanobsd, you could set the boot slice to the alternate and reboot, and it would be back to normal (but with your config, of course). That's under Diagnostics > NanoBSD Power loss normally isn't an issue with embedded, as the device is read-only most of the time. Even so, it's rare that a file gets corrupted.

The newest release version of pfSense is 1.2.3-release which is what you should be using in production. Adding something like iBlocklist is a feature coming in 2.0 which is currently in Beta.  It's not quite ready for production, but its getting very close.