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

All figured out, my rules were backwards, I had my source and destination switched. I have it successfully set up to forward port 80 to my Ubuntu server which is on 192.168.1.22, and I am able to remotely login to my pfsense using https://, all from one dyndns host. Thank you for the help.

Thanks jimp. That's what I was looking for.

well I just did a sockstat and don't see anything listening on those ports.. Let me turn it back on and see if the errors come back and then I will check with sockstat.

Writing to CF isn't exactly speedy. Far too many variables there to really speculate. It could be any of these, all of these, or none of these: Speed of the CF Speed of the box itself Other operations on the firewall could be slowing it down (check cpu usage) Might need to increase nmbclusters Sun spots, gremlins, stray sabot, etc, etc.

Yes. It already does this on 2.0.

And µ$ is lacking of reliability in means of uptimes is getting higher than 1 year

I inserted a 3rd NIC and connected the WAN to that 3rd NIC leaving the 2nd NIC (former WAN) empty. So I have the following: 1st NIC: LAN 2nd NIC: Empty 3rd NIC: WAN It worked. The strange part is that in our main router in which 2 nics works normally, Pfsense's WAN doesn't work for some reason.

Then you can edit first posts subject with [SOLVED]