carp works fine in v1.2.3 not v2.0 rc2 going to retry …

Hi, There is another thread talking about this problem. (no solution yet ) Seams related to Xen/Hyper-V and AMD Cpu http://forum.pfsense.org/index.php/topic,36281.0.html

It has been a week without incident.  I believe the changes Ermal made seems to have resolved in the issue. I'll keep on monitoring the issue and will report if there are any changes. Thanks.

FYI- I upgraded a 64-bit VM I have to today's snap from the 19th with no problems, and I had the following packages installed: nmap, nrpe2, ntop, OpenVPN client export, and TFTP.

I've just been working on this same problem and managed to get it working under esxi 4.1. The missing ingredient was to enable promiscuous mode on the virtual switch from within vsphere. Just edit the properties for the vswitch and under security change promiscuous mode from "reject" to "allow". I didn't even need to restart my VM, it just started working instantly. Hope this helps.

hehe, man truss will be your friend… :) I did that trace first with save gateway, then i switched to Interfaces - wan and did the same here. I did a truss -fae ... Hope that helps Update: Todays update of pfSense solved the problem. Now all seems to work again as expected. Thanks for your help! trace.txt

It work !!! thank you very much to all

I tried this, but wasnt able to get relayd to accept and forward connections through the same interface. When configured to listen on the lan interface, it wasnt able to forward connections out the same interface, even with permit rules added to the LAN interface allowing all traffic to the hosts on the same network.

To bad I found this after buying a new Alix board and taking the time to setup my router again from scratch.  But hey now I have an extra router, a clean configuration file, and I found a bug.

It is unlikely you will ever get blacklists to work on ALIX. The error messages you show indicate a lack of RAM and other related errors (/tmp is a RAM disk and it's also probably full)

Hmm, well you could reduce that by changing the key rotation time from 1m to 1h. My own logs look like this: May 25 09:39:39 hostapd: ath0_wlan0: STA 00:1c:b3:51:a2:8a IEEE 802.11: deassociated May 25 09:38:52 hostapd: ath0_wlan0: STA 00:1c:b3:51:a2:8a WPA: pairwise key handshake completed (RSN) May 25 09:38:52 hostapd: ath0_wlan0: STA 00:1c:b3:51:a2:8a RADIUS: starting accounting session 4DD28AB7-000000E9 May 25 09:38:52 hostapd: ath0_wlan0: STA 00:1c:b3:51:a2:8a IEEE 802.11: associated May 25 09:37:53 hostapd: ath0_wlan0: STA 00:1c:b3:51:a2:8a IEEE 802.11: deassociated May 25 09:37:06 hostapd: ath0_wlan0: STA 00:1c:b3:51:a2:8a WPA: pairwise key handshake completed (RSN) May 25 09:37:06 hostapd: ath0_wlan0: STA 00:1c:b3:51:a2:8a RADIUS: starting accounting session 4DD28AB7-000000E8 May 25 09:37:06 hostapd: ath0_wlan0: STA 00:1c:b3:51:e2:8e IEEE 802.11: associated That's just one iphone. It gets worse with three or four!  ::) Steve

I'd just like to say thanks for putting this feature in.  It is a deal breaker for me and works just fine.  Once again thanks for the great work. Cheers Trevor

My config is : 2.0-RC2 (i386) built on Mon May 23 12:42:57 EDT 2011

ok, looking around a bit in the forums I found the solution by myself… http://forum.pfsense.org/index.php/topic,35244.0.html ...so I guess this will change with rising version-numbers. greetz plex

Thats fine. Always good to get a feedback if a problem is solved. Whatever the solution is ;-) Frank

@stramato: @jimp: HTTPS is not proxied transparently, so you are probably missing outbound NAT rules if you are running a second subnet on LAN via IP Alias VIP good day jimp thank you for clarifying. currently I'm just using "Automatic outbound NAT rule generation" what rules should I create and would it be necessary to use Manual Outbound Nat? Got it, jimp. Setting it to Manual Outbound NAT automatically produced some rules. I just copied them and change the IP Addresses. Also added 127.0.0.0/8. Now I have multiple Virtual IP subnets, Squid, Multi-WAn and Load-Balancing in 1 box, working together. Very nice. Using April 10 RC1.

Doesn't matter, the IPsec status screen still doesn't try to match it up. Matching the tunnel in the GUI is not the problem, it's showing the individual status for each and every connected mobile client that is the problem. You have to walk up and down the SAD/SPD which is quite a large operation when you get a significant amount of tunnels connected to a box. It doesn't scale well, so we haven't rewritten the IPsec status to properly handle mobile clients until a more efficient solution presents itself.

Didn't get this error after a firmware update. I will let you know if it occures again. Thanks. option domain-name "hpa"; option ldap-server code 95 = text; option domain-search-list code 119 = text; default-lease-time 7200; max-lease-time 86400; log-facility local7; ddns-update-style none; one-lease-per-client true; deny duplicates; ping-check true; authoritative; subnet 172.17.0.0 netmask 255.255.252.0 {         pool {                 option domain-name-servers 172.17.0.1;                 range 172.17.0.200 172.17.3.254;         }         option routers 172.17.0.1;         option domain-name "hpa";         option domain-search-list "hpa";         option domain-name-servers 172.17.0.1;         default-lease-time 7200;         max-lease-time 14400;         option ntp-servers 88.198.51.165,178.26.114.66; } host s_lan_0 {         hardware ethernet d0:d0:fd:4e:08:a7;         fixed-address 172.17.0.2;         option host-name SG300-28-F8-1; } host s_lan_1 {         hardware ethernet 4c:e6:76:00:de:a3;         fixed-address 172.17.0.40;         option host-name LS-QLEA3; } host s_lan_2 {         hardware ethernet 00:24:a5:00:4b:4f;         fixed-address 172.17.0.41;         option host-name LS-QLB4F; } host s_lan_3 {         hardware ethernet 00:15:60:48:ea:bd;         fixed-address 172.17.0.50;         option host-name HP7310; } host s_lan_4 {         hardware ethernet 00:1e:0b:f8:ff:b6;         fixed-address 172.17.0.51;         option host-name HPK5400; } host s_lan_5 {         hardware ethernet 00:30:6e:f7:31:5d;         fixed-address 172.17.0.52;         option host-name NPIF7315D; } host s_lan_6 {         hardware ethernet 00:19:99:1c:88:41;         fixed-address 172.17.0.60;         option host-name cyber; } host s_lan_7 {         hardware ethernet 00:50:56:18:12:69;         fixed-address 172.17.0.61;         option host-name FOURnSIXnet; } host s_lan_8 {         hardware ethernet 00:19:99:0b:8d:87;         fixed-address 172.17.0.100;         option host-name HPA0019990B8D87;

Uhm… I'll take it into consideration and I'll try to find a window for doing it (since it's a production enviroment). Thanks :) Ruben.