I am having the same trouble with scp/rsync but only when rsync between two pfsense box via IPSEC. When I run the rsync from to WAN it works just fine, when I run rsync via IPSEC it stalls.

PFSENSE 1.2.3

Sorry, in this way I cannot help you. :(

This is great! Browsing works fine. 
Three additional questions are remaining for me:
1)  within the firewall logs the vpntunnel seems trying to acess bogon networks:

Last 50 firewall log entries. Max(50) Act Time If Source Destination Proto block Jul 15 12:44:07 ovpnc1 178.73.217.134:60704 224.0.0.252:5355 UDP block Jul 15 12:44:07 ovpnc1 178.73.217.164:63766 239.255.255.250:3702 UDP block Jul 15 12:44:07 ovpnc1 178.73.217.174:6771 239.192.152.143:6771 UDP block Jul 15 12:44:07 ovpnc1 178.73.217.174:6771 239.192.152.143:6771 UDP block Jul 15 12:44:07 ovpnc1 178.73.217.174:52375 239.192.152.143:6771 UDP block Jul 15 12:44:07 ovpnc1 178.73.217.164:63766 239.255.255.250:3702 UDP block Jul 15 12:44:06 ovpnc1 178.73.217.113:51097 224.0.0.252:5355 UDP

Why does the ovpnc do so? Would it be a good idea to allow ovpnc1 to talk to bogons?

Within Rules -> OpenVPN I allowed the following: ID Proto Source Port Destination Port Gateway Queue Schedule Description   UDP 178.73.216.0/20 * 178.73.216.0/20 * * none   Schwedenserver 

Otherwise there are lots of firewall logs blocking transfer between two different IP's both within the vpntunnel network.

Is it possible to connect some special IP's, i.e. my SIP-Phone directly to the Internet, not using the VPN-tunnel to avoid latency? How could I do that?

Thank You in advance.

I did, I tried under WLAN, now I have blocking rule under floating assigned with WLAN.
Traffic is still going through.

Sweet that fixed it. The console ran through a LOT more text this reboot, most of it about reinstalling packages (VMTools is all I have installed). Everything looks good now, thanks for the help.

It actually started working after I enabled IP forward on OpenVPN server or maybe addition of CCD folder in OpenVPN server helped. I hate it when I can't pinpoint the issue. Anyhow, even without the other side network showing in ARP table my VPN tunnel works fine. I guess I was wrong with my theory. But it would be nice to see them in ARP table anyhow.

Thanks,

@ermal:

By any chance you have sticky connections active?

Indeed, i do!  I spend a whole day in it and well…fallback/failover is working right now!
Only the problem for my fixed ip's still excists

You assumed that the project mentioned is 2.0. It is not.

First of all remove your public ip-addresses
Have you taken packet capture if you try to ping or browse to that one location, via wiline.
You can create a route to use another gateway if nothing else works

It would be useful to have more information about what is happening. A packet capture on the WAN interface and running pftop on the pfSense console or a SSH session should give more information about the apparent superfluous traffic. pftop displays summary information of firewall states. Typing h to pftop displays a help page including options to sort the display. Sorting on bytes or packets should show the busiest connections.

jimp, the old behavior would just stop any new connections that matched the rule, so it would just stop them from making new smtp connections after they hit the limit.  So the user could keep playing farmville, checking their aol account, etc, but keeping the location from being listed on spam blacklists.

In this situation I have no control over the equipment that connects to the wireless network, and I need the connection to just work, without staff having to have any interaction with the users.

The problem with having on site staff instructing the users, is that there is no way for on site staff to know that in this instance, the user cannot connect to the network because they have a spambot.  The symptom(to the user) is the same as when the captive portal randomly stops working, or when the user doesn't turn on their wireless card, or when they have a helpful friend statically set their dns, or when they don't have dhcp enabled at all, or when they have a socks proxy set, etc.  I guess I just don't want this feature to increase my workload with more reports of wireless problems.

Also, if a user did want to try and download tools to fix their computer, it would be difficult to do with no way to connect to the sites that have such tools.

If the virusprot feature included it's own captive portal setup I could see it working.  It  would redirect the user to a page that explains why they are being limited, and  still allow access to certain sites such as virus updates, majorgeeks malware removal guide, etc.

But going back to my orig question.  How about just having a checkbox "Block all on trigger" under the advanced rule.  If it is checked then add an ip to the virusprot table.  If it isn't checked use the old behavior.  Do you think this would be considered for 2.1?  It seems like without this feature the only use case for the rate limiting rules is to catch infected machines.  What if someone wanted to use the feature to limit the number of web requests a web spider was making to their servers, or … some other made up example I cannot think of right now. :)
Thanks
Josh

Ok. It is done now. I also did an update to latest build. I can confirm that the loader.conf is overwritten. My editations in that file are now gone. The newly created loader.conf.local is still there with the two lines.

After this modification the one box in production has crashed no more. As of writing there is 5 days of uptime compared to aprox a crash a day before. So hardware for 1.2.3 can easily run the new pfsense 2.0 with this small modification.

Case is closed. Hardware is running pfsense 2.0.

BR. Anders

Are you still having issues with your boxes?

I have 4 boxes. Two of them crashes. They are the same hardware and there should be a fix to them to get them going.

See thread: http://forum.pfsense.org/index.php/topic,38660.0.html

Maybe try to contact Soekris about hardware support for 2.0. It may be a minor fix to get your boxes running again. As what I have read in the forum crashes are most likely to be related to hardware at this stage of the development of 2.0

BR. Anders

Oh if you're set to gitsync to mainline after upgrade, mainline is now 2.1 so you don't want that, 2.0 is RELENG_2_0.

Tried your suggestion (ajax/javascript etc..) but still can't get it to work correctly… oh well.

If you can make a patch that makes it work better in a proper way, feel free to submit the patch and someone can commit it to the package.