Okay i understand, Yesterday i tried to set the gateway by the DHCP, with success. But what is with clients they have configured the ip manually? I think i will block all other traffic to 10.0.30.1 by simple firewall rules and set the gateway still by dhcp. Do you think this is a secure way for my networks? Later, after testing in my test environment, i want to send the dhcp information through my MS TMG (DHCP Relay) from my intern dhcp server for the dhcp discover of the wlan clients. The tagged traffic gets route trough the TMG in my intern network. The MS TMG is checking for trustworthiness (AD Membership). Do you think this is a secure way to connect the wlan clients to my intern networks? To join the wlan the clients using wpa2 with radius authentication (MS Windows Server NPS/NAP with AD integration)

Pfsense Beta1 2.1 (i386) is running on a HP Elite Book 8530p Notebook Core 2 Duo 2.53Ghz 4GB Ram with a Expresscard/Realtek 8111 being used as the WAN port, build in Intel ethernet as LAN. The switch is a Cisco SG-300-10 The AP is a Cisco AIR-AP1242-AG-A-K9 I originally had the AP plugged into a Netgear 824 router no vlans of course, getting the feel of the AP before I setup a PF box…..with no changes it's functioning on the SG-300-10 switch..... I still have to make some changes of course to the AP based on the new setup. For example, I still need to setup at less one Vlan and verify other settings etc... the same goes for the Switch and Pfsense. But it simply seem like the mac and ip isn't passing though the AP based on the current settings. For the time being I have all the ports on the switch setup as access/Vlan20. I was just assumed sense it is functioning (AP), I should be able to WOL the Pfsense box by accessing through the WIFI/AP. Keep in mind everything is powered up except for the laptop...the goal is to power up or power down the Pfsense box. The reason for this is for my GF, when I'm not there she can power it up with her laptop by connecting to the wireless AP. Would be running 2.0.2 with a single ethernet cable but was having issues with the switch. And 2.0.2 doesn't support my Expresscard/Realtek 8111 so ended up installing 2.1 Beta1 which does.   I'm confident the Vlans where setup correctly, but there must be some setting  :'( within the 3L switch mucking things up for me. Will figure it out another day. As for networking, I had no idea of the complexity until I got the Cisco SG-300-10 and started plundering deep into PF. To start off with had issues with DHCP/Gateway handout from my ISP being able to pass though the switch. Finely got a hint to turn off CDP in the switch  :-[ .......Networking is quite a mind Wack if you look at the big picture.....Guess give it another year networking wont be so daunting. Give me a couple of days to finish what I know needs to be done and will report back.

The ntp daemon changed on 2.0.2 (2.0.1 and earlier used openntpd, now we use the ntp.org daemon), so I'd say that was it.

It's more about the security fixes than the extra features. Look at the release notes to see what applies to you. As JimP said recently it looks like there will be a further update relatively soon to deal with the pppoe DNS issue. You could wait for that if it applies to you. I have upgraded with no issues. Steve

Program UPDATE –-------------- Bug fixes. Check & create sub-directories by itself, no need to create directories manually Support for db file log of daily kwH using sqlite Now requires sqlite port It has now two parts that remains resident, owl.py which write the log files and:           responder.py which responds to email query. You can send an email (ID as defined in responder.py) with subject "OWL" and from and to dates in 1st & 2nd line of the mail body in the format yyyy-mm-dd as a query. The code will reply with an attached txt file containing statement of usage within dates, total kWH and avg kWH. Version 1.0.2 Installation Steps: 1. Download and UNzip owl.rar https://dl.dropbox.com/u/2185098/generic/owl.rar 2. You may place all files in /home and rename to .py 2. Edit all .py files, check the comment areas to modify. 3. #chmod +x /home/.py 4. Add Firewall>Virtual IP>IP Alias 224.192.32.20/24 to your local interface 5. Add Firewall Rules>local interface:   Allow UDP * * 224.192.32.19 * * note   Allow IGMP * * * * * none   Allow * 224.192.32.19/24 * * * default none 6. Pfsense>Diagnostic>Backup>Download Backup config.xml   find /system, and add just below:       <shellcmd>python /home/owl.py &</shellcmd>   save the file structure and restore. 7. Pfsense>System>general Setup>NTP time server> change to "pool.ntp.org" Notes: to INSTALL python with sqlite port ---- /etc/rc.conf_mount_rw mkdir /home/tmp setenv PKG_TMPDIR /home/tmp/ pkg_add -r http://ftp-archive.freebsd.org/pub/FreeBSD-Archive/old-releases/i386/8.1-RELEASE/packages/All/py26-sqlite3-2.6.5_1.tbz /etc/rc.conf_mount_ro I would be glad to know if you have used the code or taken any help from it. EDIT: It seems to be working now, I made responder.py a subprocess of the main scrip instead of trying to start both the scrips using shellcmd.

This is great stuff, thank you very much.

The current multi-pools code doesn't support different subnets but it shouldn't be too difficult to add in the future. It would just need a couple extra statements in the dhcpd config declaring the shared network, etc, etc.

@stephenw10: Exactly. Really the question you're asking is not how many clients but how many connections and that is very dependent on the type of client. I imagine that an IP connected thermometer is not going to be opening many connections, 1 or 2. However an internet cafe full of gamers is going to create a LOT of connections, as you have found!  ;) Back in the day I first switched to a Linux based firewall (Smoothwall) when my existing solution (some software running under Win2K) crapped out every time I tried to open the server list in Counter Strike. It opened connections to every server in the list which I seem to remember was ~30K at the time. Now I imagine they have streamlines that process significantly in the last 15(?) years but even so. That was just one client. Steve Right, it was about 8 years ago that I switched away from an original WRT54G (running Linksys firmware) for similar reasons, I'd lock it up with (legitimate) torrenting and gaming, so I switched to m0n0wall.  And that was just 3 PC's and a couple Tivos in the house. Even though m0n0wall does have a finite state table, I've still never hit it.

A few things you could try: 1. Packet capture on WAN interface of office pfSense, filter on (say) port=RDP. Do you see your outgoing RDP access? to the correct IP address? (local DNS might be wrong?) 2. Do you get any response at all? 3. Packet capture on WAN interface of of home pfSense, filter on (say) port=RDP. Do you see incoming RDP access from correct IP address? Does access attempt match port forward rule? 4. Packet capture on appropriate interface of home pfSense, filter on (say) port=RDP. Do you see outgoing access attempt to correct IP address and port? Does that access attempt appear in "RDP server" log on target? Does the RDP server log give any clues on how the access attempt was handled? (some servers have their own "firewall" capability such as "forbid access from specified IP subnets")

@stephenw10: Running services on your firewall that aren't required for it's operation is just opening up possible attack vectors unnecessarily. On top of that it's far more likely any exploitable security hole will go unnoticed since you will be the only person (or among very few) who are running it. It depends how familiar you are with patching security holes. Are you confident of keeping up to date with new FreeBSD exploits because the pfSense team won't be patching CUPS? In reality it's unlikely to be exploitable as long as you have your firewall rules set correctly. It's a trade off between security and functionality. Since the purpose of pfSense is security most people see that as a risk not worth taking, however small. Steve Thanks Steve. It does make sense. In as much as pfSense is serious business application, it has many enthusiastic die hard fans like me who use it at home. And, I have recommended pfSense (with subscription) over fortigate at work last year (not that fortigate is a poor product). Perhaps some enthusiastic developer can turn this type of feature into a CUPS package. That would be fun. Best Anil

After removing the scripts everything works fine. Thank you for your support! Happy New Year! Regards. Alper

I've done a fair amount of thinking and testing various configurations for exactly this type of usage scenario. If you want to serve ~1500 concurrent Wifi users, and assuming you've solved the Wifi engineering issues, then pfsense can provide several parts of the overall solution, acting as a DHCP server, router, firewall, traffic shaping and NAT device. You should also do some thinking ahead about how to best mitigate certain possible problems, because just a few virus-infected PCs among the ~1500 ones, can bring a network to its knees.

So it's most likely a certificate issue then, Would certificate issue causes packets to not being sent or received as expected by the server application ?

You can't hack in PAM like that. Using LDAP for authentication is how nearly all our PCI-certified customers do things. Some use local accounts on the firewall instead. The local admin account will still have to exist, but you just need a policy to manage it accordingly. Basically no firewall (or router, or switch) has forced password complexity requirements nor forced password changes, it's adequate to manually manage those things via your general security practices and policies.

Perfect, this sounds fair enough…  ;D Thanks a lot

Actually, top -SH is the most accurate, since it also splits off threads for more detail.

@dhatz: @GruensFroeschli: There was very recently a thread about exactly this. The solution was basically to configure the dhcp client to decline rfc1918 ips. Check http://redmine.pfsense.org/issues/2704 http://forum.pfsense.org/index.php/topic,56330.0.html Thanks this looks great. I already have an alias on the interface to access the modem webpage whilst the connection is up and running. So rejecting the bad IP is I think the perfect solution.

Thanks!