Ah, OK. I also found some other posts about it. I got further along in the configuration, but the dmesg output on the monitor says "zyd0: HOSTAP mode not supported". So, back to the drawing board…

Interesting idea. Not sure about the security implications of having any hypervisor software being public facing but definetly something to look at.

i'm guessing upon LAN-disconnect, pfsense runs a script to remove the routes/rules/… for LAN because your route for LAN & OPT1 is the same, it affects opt1 and makes your firewall unreacheable. this is a guess, but i'm probably not incredibly far off target. as others have pointed out, don't attempt this.... it'll probably be possible with some manual hacking, but why bother? There are plenty of other ways to accomplish your goal. @Olman: So … Gurus .... Any one can explain why do operate on LAN Interface, such as disconnect cable, will affect other interfaces like OPT1 and OPT2. BUT disconnection OPT1 or OPT2 do not affect other..... Without empty chat, "it wrong", "outsmart" e.t.c. ; don't watering thread I have tons of installation of pix, netsceen  some times, they behave out of logic,  but none of them just shut interface 1 and 2 when interface 1 got disconnected.... back to the business: will check if such behavior exist on 2.0.3 later ... and it remote network, i can operate within existing /16 network ... so any advise of separate nets, don't work

If anyone ever needed a seriously low-watt and super reliable box, its you. I bet people there have seriously considered putting a DC-Dyno on a bicycle frame.

You can open a ticket yourself on RedMine. However, if it is already fixed in FreeBSD 9 and later, then it will just fix itself for pfSense 2.2 on FreeBSD 10.

Generally speaking, no things aren't slower in the GUI where everything is 100% identical. There are the possibilities jim-p mentioned. The base OS of 2.x is slightly faster pushing packets than 1.x's base OS versions. The most important job performance-wise has only improved in 2.0.x and 2.1. How much depends on your specific hardware and combination of hardware, but generally 5% or so improvement on top end performance going from 1.2.3 to 2.1.

@tomdlgns: will this thread be updated when the release is ready? There will be an official announcement. The entire 2.1 board here would usually be retired and locked once the release happens.

Hi jimp Thank you I will try to Update today. regards supermega

Yeah - I've only faced this issue when setting up a pfsense in a VM with a single interface and no LAN at all.  (Just using it as a Openvpn server)

Thanx evry1 :)

Testing now stunnel on 2.1RC1 and can't even get it to start. stunnel service onestart tells me that it can't find the service in any rc, but in fact it's correctly configured.

@rodymcamp: interesting, i am having the same issue, where did you edit the file to fix? i had 192.168.1.1 as a dns server. now i use 8.8.8.8 and my domainname

Hmmmm…  I didn't see those links or maybe just wasn't paying attention.

@jimp: The code that is in place is correct for most setups, perhaps there is something else unique/incorrect about your configuration contributing to the detection failure, but we had some fallout from this while testing the -RELEASE images. So the code is back to how it was before, and it is confirmed working on several very large CARP+DHCP Failover setups. If it does not work for you on 2.1-RELEASE, I'd take a closer look at your configuration first. Okay. I don't see how the original code could be correct, since the loop variable to check for "a defined vip" (according to the commentary) isn't actually used for searching, and I pointed out that your fix was not correct either. But I understand you don't want to break things just before release. My later version seems to work correctly for me, so I'll just work with a local patch then. I suggest to have a look at this again in 2.1-stable . Cheers, Markus PS: for illustration (original):                                 foreach ($a_vip as $vipent) {                                         if($int == $real_dhcpif) {                                                 /* this is the interface! */                                                 if(is_numeric($vipent['advskew']) && ($vipent['advskew'] < "20"))                                                         $skew = 0;                                         }                                 } can be transformed into:           if($int == $real_dhcpif) {                       foreach ($a_vip as $vipent) {                                     /* this is the interface! */                                     if(is_numeric($vipent['advskew']) && ($vipent['advskew'] < "20"))                                             $skew = 0;                       }           } and this just doesn't look correct to me.

Ah that's good to hear - somehow anyways :- But it's interesting and a bit disturbing to see another issue arise which is more or less depending on multi-cores and/or threads. Hopefully that won't be the start of a trend. Greets

@stephenw10: So your problem is that it's not working? Looks like the modem is configured correctly but it trying to connect to something that's not answering. Are you sure the APN details are correct? Steve The settings works fine when I use it with the windows software. I think it has to do with missing APN details rather? I think it is out of the forum's hands? I live in the Philippines, if there is any Philippine PFsense Usersn out, I need local network Knowledge.

THANK YOU SIR! Exactly what I needed to do - I'm always tickled when someone actually posts their own solution instead of saying "I fixed it" - I've added a few links to your note - there are lots of other people with similar issues, but some of them don't seem to have found answers as pretty. Cheers!