@jdwilliams: @Topell: Why do you need to bounce the box every night? Just to try and keep things running smooth… Its for a user whos 300 miles away and they have some slowness issues after squid has been runing for a few days and the webcon give a 500 error at random. Do you normally work with Windows?

Oh, different problem.  If you want to be able to access OWA from the inside using the external DNS name, you're going to have to make an A record on your internal DNS server pointing to the internal IP address.  (And if you're going to do that, making a zone for the public domain name on your internal DNS server, you'll have to replicate all the other public records or your users won't be able to get to, for example, 'www.companyname.com'. Or just create an internal A record like 'mail' and get a multi-name cert that will work with both the internal and external domain names.

can you name a some torrent clients which allow you to manually enter WAN ip..?? because there are too many available and i have ti try each one indiviually..

Hi again, Just thought I would post that a solution to this issue has been discovered.  It turns out that the default ciphers used in v1.2.3+ versions do not support the 3des-cbc cipher, which is what my SSH client uses. Manually editing /etc/sshd to add this cipher to the list solves my issue : Change the line : $sshconf = "Ciphers aes128-ctr,aes256-ctr,arcfour256,arcfour,aes128-cbc,aes256-cbc\n"; … to this : $sshconf = "Ciphers 3des-cbc,aes128-ctr,aes256-ctr,arcfour256,arcfour,aes128-cbc,aes256-cbc\n"; I'll post this to the bug tracker as well. Thanks, -- Phob

You might try to get in touch with Thayner and see how the install is going… http://forum.pfsense.org/index.php/topic,23365.0.html

Well I've solved my problem. I tried another NIC and it worked! Somehow the onboard NIC didn't support PPPoE. Although all other functions work like it should. This post can be closed.

This was noticed and fixed shortly after the 1.2.3 release, but since 1.2.x likely won't see any more releases, you can apply the fix manually: https://rcs.pfsense.org/projects/pfsense/repos/mainline/commits/0535db81e8f813cea016f1c0c8562b1b0b0d7ea7

johnjces: Some access points have a feature you can enable to do that and pfSense also has a simple checkbox to do it when it acts as the access point (with a wireless network card supporting access point mode in FreeBSD).  Any further discussion of this should probably go in a different thread.

What are these cards plugged into? All into the same switch or different devices? Anything show up in the system logs when it happens? If all of the cards are going out at the same time, my first suspects would be the PSU in the box, the switch, the motherboard, or if they're all the same make/model of card, perhaps a driver bug. It would just take some good old-fashioned troubleshooting and component swapping to narrow it down.

Hi sullrich, The reseller subscription is something that I'd like to do in the future, however at the minute, a single subscription costs more than the total amount of money we are making on the project. I have just bought the book from amazon though :) As for reselling pfsense "as is", what constitutes a change? Is something like adding RADIUS support for OpenVPN a change? What about adding packages such as squid and squidguard? And if it was classed as a change, is it just as simple as removing the pfsense logo? (I'd hate to do this though, as I do have a love for the project) Thanks

In addition to that, you will likely need to leave the "Block private networks" box unchecked for WAN in this case.

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.