Gilrod, Just a word of caution. I've run into the same problem on 512 MB images and 1GB images as well. Depending on your uptime and how much as been written to logs, etc, the 1GB image is not a guaranteed safe workaround to this problem.

http://forum.pfsense.org/index.php/topic,29660.msg163436.html#msg163436 If you create a /conf/mpd_wan.conf file according to gnhb's instructions then you don't need the dummy interface and your ppp log file won't fill up.

I am very sorry but this may caused by my computer hardware. I have successfully install pfSense on another computer with the same hardware. I will do something more to determine which hardware is broken. However, that computer can run pfSense 1.2.3 perfectly.

@ermal: There is a advanced setting controlling that behavior now. Could I find the answer from any documents like http://doc.pfsense.org/index.php/Category:FAQ ? I have also tried the floating rule with the following setting: action=block disabled=false quick=true interface=did not select any options direction=any protocol=any source=192.168.13.3(the target) destination=any All the settings that do not listed are default.However, the result is fail. Thank you. ;)

now on 2.0-RC3 (amd64) built on Thu Sep 8 15:43:15 EDT 2011 - problem solved!

Hi Steve, thanks for that hint. I didn't see this before. I'll give it a try. Great, thanks. Tim

What was the problem? you could also edit first post subject with [SOLVED]

Hi, I've encountered the same issue. I'm trying to get all site-to-site site vpn traffic (the return traffic as well) to route via an interface group (two simultaneous tunnels) and not the routing table. I assigned each tunnel an interface and set a rule on the lan to use the gateway group for all traffic destined to the opposing site. The problem is that if one tunnel goes down, and its the one in the routing table, the return traffic gets lost. Any pointers on how I can get it working? Thanks, E

Today I installed version 1.2.3 which behaves the same way as the 2.0 version does. Except that it does not allow the creation of a transport policy and I had to use a tunnel policy. I think it's related to how freebsd's / racoon's implementation of ipsec is. I will try figuring it out if this can be fixed. I'm not very experienced with freebsd/racoon (yet… ;D) Once I managed to get it working, I will post an update.

Thank you for the response. I did try it with policy routing and without, however. Another google search of the forums have found that setting 'Bypass firewall rules for traffic on the same interface' will (and has) corrected this behaviour.

Its a precaution taken to not break the config. Special characters are removed as part of this. It will be improved on later versions but for now this was the safest solution found.

I will lock this thread now because it is going off-topic. You need the latest snapshot to have the options described in this thread.

Sorry can you be more specific?

Hi, Traffic from your openvpn server to your other hosts on the network do not pass your pfsense appliance since the vpn server has an direct route to the "internal" network. However, traffic originated from your hosts on the network towards the openvpn client subnet, routes via your pfsense appliance, since the hosts on the internal network does not have a specific route to the openvpn client subnet. Therefore traffic arrives and goes out on the LAN interfaces of your pfsense box. I think you need a rule for that, or enable the option you mention. I have no experience with this kind of setup, but you need a rule like this I think: allow source <lan ip="" range="">destination <lan ip="" range="">on the LAN interface. The other approach is to add a static route on the LAN hosts, but is more work and harder to maintain. To test you can manual add a route on a LAN host. Also, only the first packet of any traffic will be directed through your pfsense box. Most operating systems has an "ICMP redirect" implementation, which you might have to enable. This way the host on the LAN network will learn the direct route to the openvpn clients through the openvpn server, bypassing the pfsense box. I Hope this will help you.</lan></lan>

@Wolfsokin: The list(s) you use for ipblocklist might be a bit heavy handed. I prefer to use my own custom lists to block what I want rather than let somebody else tell me what I should block. Thanx for the idea :)

The problem still persists and the occurance is random. Additionally, I get following alert in the email on multiWAN setup: Gateways status could not be determined, considering all as up/active. Recently, I have installed a pfSense box with single WAN and that too is randomly not updating "dynDNS" servers at times. Is it better and more reliable to use RFC2136 and TSIG key on dynDNS?

OK, but I think its best to always the redirection only points to virtual IP. I logon to console on both boxes and ping respective sync interfaces, no RTO, but the master shifted. Also why does when it shifted, we need to relogin again to the portal, and it does'nt carry the record of already login users to the next master? When I shutdown either master or backup. Yes, it still work. For now I think it still best to run CP alone or CARP alone, but not both on same machine. additional question How many CP users it can accomodate? My CP seetings for Hard timeout is 720minutes or 12 hours. CP users always displaying portal page cannot continue anymore. already logon users can internet. Reboot fixed the problem temporarily for a day. Since 2.0Beta to 2.0RC1, when ever CP users reaches or below 50. 2.0RC3, when ever CP users reaches more than 50 or more than 100.

Interesting. On my 2.0 box kern.ipc.maxsockbuf is already set to 4262144. The -w option on the sysctl command is not needed. See here. My own experience is that skype is far from perfect and below what I expect from my connection. Anything you find will be useful. Steve