Diag > Command will always show rw because it switches to rw to run your command. Only when viewed from the shell on the console/ssh will you see ro.

Just wanted to finalize this thread out by saying I ended up swapping out both the nics. Their chipset numbers are: 88E8001-LKJ1 AJ476A.2 0714 A4P TW Marvell of some kind. Hardware version: B2 Now everything works fine except dealing with havp and squid now :)

Yes you can do that. Though I would probably stay away from doing so, or at least be very careful not to mess up the VLANs on any of your switches or you could end up with a layer 2 loop much more easily than bridging scenarios without VLANs.

You're welcome :)

@bsmither: So, just to satisfy my curiosity, is it the ICMP protocol's job to determine if a reply can be sent without a route, or is it the networking part of the OS, or the ping.exe application? The way I see it, something has to be dumb enough to permit a reply based on knowing the IP address and/or the MAC address of the sender in the request packet. It's the IP stack of the OS. It has to be able to send back to the source IP of the request, whether it's locally reachable (so it just ARPs that IP), or is reachable via some router in its routing table (in which case it ARPs the router where that IP is reachable per its routing table).

You can turn on NXDOMAIN responses in OpenDNS. Or fix your DNS so it'll resolve local hostnames correctly, which is the better solution given that's what current Windows versions expect.

@stephenw10: @Cino: You just can't try a card in the box and expect it to be 100% stable without researching the wifi card and its driver for freebsd. I think that says it all. For many people that is a reason why pfSense sucks. For a M$ based solution (and increasingly Linux) you can just try a card and have a reasonable expectation that it will work well. As pfSense becomes more popular it is inevitable that more first time users are going to be disappointed. There are probably far more satisfied users but most of those don't complain.  ;) Yeah this entire thread can be summarized as FreeBSD's wireless drivers for some cards really suck, and on the rest the guy has no idea what he's doing, things like creating MAC address conflicts and wondering why the network breaks. But Linux has much the same issues with drivers, you really have to research your cards before you buy one especially since many of the bigger manufacturers (DLink, Linksys, etc.) will change the chipset used in their cards without changing the model # at all, so even finding a working model # on some cards is no assurance you're going to get the same card they used to sell under that model. It looks like the situation with wireless will be getting a lot better with FreeBSD 9. Adrian Chadd has done quite a bit of work in FreeBSD 9 for a commercial software company that uses FreeBSD in their appliances and relies heavily on wireless. I have hopes that will be a great step forward on wireless.

I can kind of explain what's going on with the SMC gateway. Think of it as a router / firewall / modem all in one. Basically the device has several IP addresses assigned to it. IIRC there are actually two real world IPs on the device, one is only seen by comcast on the router's wan port, then there is another real world IP on the routers LAN port. The device routes traffic between these two IPs so you can get your live subnet. There is also a firwall that resides off of the router's lan port, which will do NAT. Both the router LAN and the NAT'ed firewall are live on all 4 ports of the switch. So when you put in the correct information for a static IP address, the pc will find the appropriate gateway and use that to get through the SMC router and to the internet. If you just use a DHCP lease that is handed from the SMC firewall and your traffic flows through that then into the SMC router and to the internet. So it would look something like this: COMCAST ROUTER   |   / WAN SMC ROUTER PORT   |   / LAN SMC ROUTER PORT -> FIREWALL   |                                        |   /                                      /         4 PORT SMC SWITCH It's kind of neat how it's setup because it is possible to use both static IPs and have clients behind the firewall at the same time. The networks don't really cross but if you had a packet sniffer on your lan it might be possible to see traffic from the other subnet. Obviously if this is a concern you would only use one or the other. The other thing that you get is even with having only 1 static IP address you technically get 2, because a /30 gives 4 addresses.

I am also having same problem with Pfsense 2.0. I am using multiple WAN connections and Squid + Squidgaurd. Every thing is working fine but FTP :( no luck I am tried same options as u did. Well in my case if i connect to my FTP server. MY FTP server responds and did not show any listing of folders. and disconnect me after some time without showing anything. I have also tried this VIA Filezila to connect to FTP but have Error. EcoNNREFUSED. Anyone please help us. Thanks

/boot/loader.conf and /boot/loader.conf.local are for loader variables, not sysctls. Modify sysctls through System -> Advanced, click on System Tunables then click on the "+" at the bottom of the page to add a new entry.

The DGS-3100 has a slightly more complex VLAN setup, hence, the exact steps are as follows if you want to allow all LAN ports access to the Switch configuration (in this instance, you would use a computer on Ports 2-32 or 43-47 to access the switch management): Go to L2 -> Asymmetric VLAN and enable it. Go to L2 Features > Forward & Filtering >DLF Filtering Mode: Select All (check the box), Select Forward all DLF packets. Apply. Go to L2 -> 802.1Q VLAN: Edit Default VLAN (VID 1). Select Ports 1 & 33-42 as non-members. Select Ports 2-32, 43-47 as untagged. Click Apply. Click on the Add/ Edit VLAN tab. Add a new VLAN with VID = 2, Name = LAN. Select Port 1 as Tagged. Select Ports 2-32 as Untagged. Select Ports 33-48 as Non-member. Click Apply. Click on the Add/ Edit VLAN tab. Add a new VLAN with VID = 3, Name = Freeswitch. Select Port 1 as Tagged. Select Ports 33-42 as Untagged. Select Ports 2-32, 43-48 as Non-Member. Click Apply. Click on the Add/ Edit VLAN tab. Add a new VLAN with VID = 4, Name = Wifi. Select Port 1 as Tagged. Select Port 48 as Untagged. Select Ports 2-47 as Non-Member. Click Apply.

You MUST reboot your FW and all be "recognized"  ( you will be able to choose the database in FusinPBX menu )

He means set source ports to all and set destination to 127.0.0.1. However I fail to see how that could possibly work.  ::) If you research Ultra Surf at all you will find it's very difficult to block. It's specifically designed to bypass firewalls and filters. Steve

Had a recurrence of this just now, with NAT outbound rules that all specify source addresses. Trying one variable at a time here (oh, I did change the Ethernet cable for good measure). Next is swapping the LAN interface to re2 on this card.

I use only openvpn by myself but i have configured also pptp & l2tp vpn's for testing I haven't done a thing with ipsec on these three vpn's

@wallabybob: I don't think /var/log/dmesg.boot is a general FreeBSD facility - perhaps it is specific to pfSense. It is indeed, /var/run/dmesg.boot contains the dmesg buffer just after the boot even in a FreeBSD system. There is another reason why dmesg could not be right command for finding disks: dmesg shows the kernel buffer message, so if the kernel is long lived and has outputted several messages, dmesg has scrolled and disk information is lost. Other commands that will work are: atacontrol list for ata devices and camcontrol devlist for scsi, usb devices.