@dhatz:
I wonder if it's still a problem with the newer FreeBSD 8.3 kernel used by pfsense 2.1-BETA
I have since sold the small WISP business that used the virtualized pfSense system I reported on earlier. However, my new employer (an ISP) asked me to build a vSphere cluster and help them virtualize large parts of their central office. So I will soon be able to do further testing with pfSense in this virtual environment.
Looks like packets pass across the bridge from the Physical OPT at least to the QinQ member vlan.
I have to wireshark on the WAN (QinQ) link to see if packets actually make it onto the wire.
Maybe it's some weird ARP issue?
I will have to recheck that the alix boxes I used had the bridging fix applied. I'm actually not sure cuz they were used in a previous lab setup!
I would suggest the first thing is to agree on a test procedure that will give a useful result. It has to be relatively easy to test to get a good number of people producing numbers. It also has to give results that are meaningful to users (not 'I can get 800Mbps if I use jumbo frames across a 4 NIC LAGG').
Then setup a forum thread where people can post results. Finally ask for edit rights on the wiki and setup a page describing the above. ;)
A good example of some great testing is here: http://forum.pfsense.org/index.php/topic,27780.0.html
Speak to Jim (jimp) and/or Chris (cmb) who will have a better idea about this than me!
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.
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.
@ 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.
Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.