Ok thanks, and thanks for all the great work :)

I miss his provocative avatar.  :(

Steve

@sdm12:

Then I pointed all vlan 10 traffic to the pfsense.

What is the mechanism you used to do that?

Since your Cisco firewall is on the same VLAN as the guests it will probably be fairly easy for a knowledgeable user to work out how to bypass pfSense.

Thank you for clarification.

Success!!! :D
Okay, after i just realized that WAN/PPPOE actually was on rl0 and not how I assumed the whole time on rl1.
I went looking for the now missing rl1 and could not find it in the system.  I then plugged the "rl1" nic back into the pci slot it has been in before and then it got detected again by pfsense.
So the only problems there really were, were that i am dumb :P and that something is wrong with one of my pci slots :/
WAN, LAN1 and OPT1 are now working as intended! :)

Thanks for all the help!!! <3

I think you are much more likely to have packet loss issues on the WAN side of your pfSense than the LAN side.

Any path with a substantial number of hops on the public internet is likely to include a number of hops which are substantially oversubscribed (that is the hop bandwidth is insufficient for all potential users to be able to be able to obtain their maximum bandwidth). Hence packet loss can be seen in periods of substantial demand.

pfSense keeps some graphs of link "quality" in Status -> RRD Graphs, click on Quality tab and use the pull down to select the appropriate interface. If you have your system configured correctly the graph will give you an indication of congestion on the link to the other end of the VPN. There are probably periods of low ping response times and high response times (indicating congestion). Do the periods of high response times correspond solely to the times of file transfer?

Some things you could try. Do some tests to better understand how tweaking parameters affects the outcome..

1. Do you transfer a number of files concurrently? Reduce the degree of concurrency.

2. Convert WAV files to a compressed audio format and transfer the compressed files.

3. Do the transfers outside "busy" times.

4. Reduce the TCP window size used in the file transfers.

What are your requirements/constraints? Must get all transfers (each a multi gigabyte transfer) to complete simultaneously in under 30s in network peak times and incur no additional costs? :-)

that would work in theory ….

however ... every package on the system could one day be targetted when someone writes an exploit. If this happens, the pfsense team + volunteers try to update the supported packages as soon as possible.

The samba-mount program will not be updated by the pfsense devs, you would have to update it manually if there is ever a security problem with it.

If everyone is connecting via OpenVPN then you can route all networks to the VPN users.
Then you can use the "client specific override" to force a VPN client to always get the same OpenVPN IP/subnet.
This OpenVPN subnet can be used to create firewall rules.

Every OpenVPN connection consits of 4 IPs or a /30 subnet.
This can be used as source IP on the firewall. If you install OpenVPN on pfsense then you get a new tab "OpenVPN" on the firewall GUI.
But forcing all traffic through OpenVPN with good speed will cost more CPU power than without any encryption.

But I am not sure if this will make your firewall ruleset easier/better and give your more conrol on where these hosts can connect to.

For those that are interested, I have updated the script to support the download of the RRD data. It now supports pfSense encryption too. To get the most recent version of the code, you can download it from: http://code.google.com/p/pfsense-backups/

It is firewall colleague, so For Remote Desktop Web Connection, you need port 80, TCP and port 3389, TCP allowed then you able to take remote connection of any PC. Let me know if you facing further issue.

No, once the VIP is removed, the ARP cache timeout process starts at that point.

@ jimp: I stumbled on this thread as I also encountered the DNS problem after upgrading from 2.0.1 to 2.0.2. Upgraded my system with non-signed image from your site (pfSense-2.0.2-RELEASE-4g-i386-nanobsd-upgrade-20121226-0919.img.gz), seems to work again without any other modifications done. 2 thumbs up for the fix! Thanks…

I have decided to restart the configuration of my pfsense from scratch and I find the problem.
During the initial configuration I have installed numerous package to test like HAVP etc… and theys corrupted my squid conf with options in the "custom options" field.
So I have removed it and now keep only squid and squidguard.
Thanks for your help.

My setup is:

pfSense VM with 2 adapters one bridged to physical NIC on host and another one connected to internal network "pfsense".

pfSense VM #2 with 2 adapters one bridged to physical NIC on host and another one connected to internal network "pfsense".

Win7 VM with 1 adapter connected to same internal network "pfsense".

All NIC's have promiscuous mode allowed so that I can use VLAN's for CARP between the two pfSense VM's. For virtual adapter type I use virtio-net (http://doc.pfsense.org/index.php/VirtIO_Driver_Support) for pfSense as it's supported in 2.1 and supposedly easier to virtualize than "real" network adapters.

Finally i did it.
Special thanks to kalu  :P

@mr_bobo:

I do have a browser I only use to log on to the Web GUI to check my logs, and always log out and close the browser right after I'm done, but have on occasion opened a new window to an online tools site I use to resolve IP#'s that appear in the firewall logs while logged in.

I knew there was a reason I felt uneasy when I didn't open a separate browser to check those IP#'s.  ::)

You're reasonably safe with us if you stay up to date. Other web-managed products, unfortunately not so much. There are a number of commercial security-related products with serious unpatched CSRF and XSS issues. It would be safest to assume every web-managed device has CSRF and XSS issues and act accordingly, primarily use a different browser than one you use for any general Internet usage. These recommendations from 2008 still stand true today.
http://blog.pfsense.org/?p=232

Immediately.

Thank's a lot :)

My credit card is poised for action.  ;)

Steve