Yes, we have got movement in the rules. Vnc works! Thanks for your help. Now gradually moving machines and rules to pfs. Default gateway change. Also we have to get it working with 2 isp's

So, can someone shed some light on that setting - what's its value (as I would think you'd always want Unique - thus I would have expected that to be the default). Thx.

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?