yeah i know, I too suffer the exact same consequences. started looking for good modem routers… never found any.

Yeah, I think fstab customizations are carried over even on the nanobsd images, since it appears to just copy it over and modify it with sed.

Upgrade there was a commit that broke the communication and is fixed on latest snaps.

I sent a copy of the states to Ermal and now with the snap from the 18th of November I got both active and passive mode working with our FTP-server. I doesn´t work if the FTP-server answers passive requests with the external IP of the WAN I/F as I originally thought it should be setup, then it transfers 6-10 files and then stops and time out. I´m still a little fuzzy about what´s the proper configuration to get this going from the start, but now it works and I´m happy. I transfered a few thousand small jpegs in both passive and active mode without any problems. Thanks for the help Ermal!

Search the forum before posting. Upgrade to latest snapshot since the issue has been fixed.

Thanks for that, had been trying outbound nat as had seen it in use for other vpn's but couldn't get it to work. i am going to run with fixed ip and mac control for know and try again next week. if i have any joy i will post it here Thanks Ron

Try again on newer snapshots. I recompiled the OpenVPN client to have the option that allows you to read the username and password from a file.

Since your squid install issue seems OK, you will get a better response for the snort issue by starting a fresh thread for that. The snort maintainer would be more likely to notice the thread if it had snort in the title.

This was one of many errors when I attempted to update to the current release - only solution I found was to back to 20101116-1840 and clean install then relaod a backup config and let the system rebuild all needed plackages and 30 mins later all back to working - on a slightly older release. Regards Andrew

I'm so stupid…... Had to SET GATEWAY to pfSense IP on machine, which want to FORWARD, becouse it tried to use different box as out.. ;) resoulting in connection closed flag. So if pfSense have LAN IP, let's say 192.168.0.1 use this IP as gateway and DNS on test box. You can close this thread. It's solved. Tested on pfSense-2.0-BETA4-20101116-1840-i386.iso [image: pfsense_forward_WORKing.png] [image: pfsense_forward_WORKing.png_thumb]

@David: It's possible to get issue one resolved so it works properly in version 2 beta right now. If you go to System->Routing, add a gateway on the LAN Interface with a Gateway and Monitor IP of the LAN IP address of pfSense. Then, go to the Routes tab, and add a new route where the Destination network is the subnet of the remote network that you are trying to access pfSense from over IPsec, and the Gateway is the LAN gateway you just created. Once you save this, you should be able to access services on pfSense itself from over the IPsec tunnel, assuming firewall rules on the IPsec interface allow it. I have this working myself. It's a slight modification of the steps given at the link you provided to the Wiki with the description of the problem, since the UI changed a bit in pfSense 2. David, I can access the resources just fine from the remote PFSense router (or at least as well as I want to), the issue lies with Apple Remote Desktop and not being able to remotely administer machines.  With a PFSense->SG300 IPSec tunnel I can administer them just fine, with a PFSense->PFSense tunnel I cannot.  I did get an OpenVPN tunnel setup at one point and that works well, but that doesn't work with some of our clients' firewalls.

You can test yourself. The wizards match based on ports. The layer7 matching cannot be made to be the same for 2 installations so you can do it yourself. AFAIK layer7 shaping works!

This is indeed working in the latest snapshot for amd64.

If you select the snapshot server from the drop-down menu, that will enter a custom update URL, which also disables the signature checks.

Between aliases and interface groups in 2.0, you shouldn't need a giant ruleset in most cases.

The default rule which allows all outbound traffic from the LAN subnet will also let you ping, resolve DNS, etc, against the router's IP. If you altered that rule, restricted local traffic in any way, you may have cut that access off. Access to your local LAN is not restricted by the firewall, but access to the firewall's IP and beyond may be.

This particular system was never 1.2.3. The original install was a 2.0 snapshot and it's been through a few updates since. In my case the dhcp address range seems to have stayed in the config file when I deleted an OPT interface. when I created a new OPT interface later, the legacy dhcp information for that interface stuck to it, and the address range was at that point invalid. You may want to check the dhcpd section of your config file for errors that might be causing an issue. You can download just this section ("dhcp server") in the Diagnostics: Backup/Restore section. Mine looks something like this and is working fine at the moment (interfaces omitted for brevity): <dhcpd><lan><range><from>192.168.85.51</from> <to>192.168.85.60</to></range> <defaultleasetime><maxleasetime><netmask><failover_peerip><gateway><domain><domainsearchlist><ddnsdomain><tftp><ldap><next-server><filename><rootpath><numberoptions><staticmap><mac>00:1e:8c:83:9b:93</mac> <ipaddr>192.168.85.2</ipaddr> <hostname>ren</hostname></staticmap></numberoptions></rootpath></filename></next-server></ldap></tftp></ddnsdomain></domainsearchlist></domain></gateway></failover_peerip></netmask></maxleasetime></defaultleasetime></lan></dhcpd> If you find errors in yours, correct them, save the corrected file, then upload it again. You may have to restart your dhcp server at that point, or just reboot to test.

Yes, 802.11n doesn't work yet.  I don't know of any devices in particular that have a working driver with working 802.11n support. By the way, I did notice earlier the existence of one of the 802.11n-specific fields in your screenshots; minimum wireless standard replaces the 802.11g-only setting when the driver lists 802.11n in the available modes. The web gui is basically ready for 802.11n.  It is the drivers that are not.