any progress on this coz i see some dummynet patches lately

what i meant was im on the nanobsd and i see these issues, might be issues in general and not specific to nanobsd

People, please stop hijacking threads. Do not post things in a thread that aren't addressing the original purpose/question of the thread. Start a new thread.

http://redmine.pfsense.org/issues/show/517

Are you sure? I am pretty certain my original version wasn't march 22nd's version anyways, and thats what my dashboards shows.

Furthermore, I just did an upgrade through the console, and things seems to work properly.  But the 2.0 version's date is still march 22nd.

It should never have been march 22 as far as I know.

Anybody care to tell me whether his  NanoBSD pfSense 2.0 Beta shows something newer than march 22nd  on the dashboard?

This means something somehow got messed up in config.xml.  If you can somehow get a copy of the config.xml lines for the rule you tried to add, it would be useful for diagnosing the bug.

I don't think we have gotten a code update from them in a few months, so the situation is unlikely to have changed.

@gnhb:

Search domains are, I think, domains that your host will append to a hostname before sending to the DNS server when you don't specify the FQDN.

This is what i'm also think. But how is the Syntax inside the Textbox? I tried several combinations, but can't get it to work … maybe someone knows ...?

Because of how routing works.
This is not a pfSense specific problem.
Behind the scene a static route for each monitor IP to it's respective gateway is created.
You cannot create a static route for the same IP to multiple gateways.

@ttlinna:

I don't think it is RealTek nic that causes the problem.

It is in his case. If you're getting a bunch of watchdog timeout messages with Realtek NICs that's probably the same. If you aren't getting watchdog timeouts that's something different. You'll need to start a new thread with a backtrace assuming you're getting a kernel panic.

Hi Ermal,

I noticed you made some more changes so I thought I would try a more recent snapshot (pfSense-Full-Update-2.0-BETA1-20100412-1748) and those errors have gone away and the captive portal isnt bypassed as it was before, however using captive portal with "Per-user bandwidth restriction" enabled breaks captive portal again unfortunetly, the captive portal page loads on the client, when the client
authenticates successfully, the redirect page appears but just sits there in a stalled state, if the "Per-user bandwidth restriction" is disabled, the client gets redirected successfully.

I also noticed this error in the log when I enable/disable captive portal.

Apr 13 04:28:57 php: /services_captiveportal.php: The command '/sbin/ipfw -f delete set 1' returned exit code '69', the output was 'ipfw: rule 16777217: setsockopt(IP_FW_DEL): Invalid argument'
Apr 13 04:28:57 kernel: ipfw2 (+ipv6) initialized, divert loadable, nat loadable, rule-based forwarding enabled, default to accept, logging disabled

Thanks in advance.

Slam

I think this may be related: http://redmine.pfsense.org/issues/show/446
PPPoE, PPTP, and L2TP are all handled by the same program, I think.

Great thanks!

I was thinking this was the case, but I wanted to make sure before I screwed up a perfectly well setup pfSense 2.0.

Web browser

Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.3) Gecko/20100402 Namoroka/3.6.3

Read this.
http://forum.pfsense.org/index.php/topic,20917.msg107386/topicseen.html#msg107386

Please cancel the pptp one, one of my colleagues had disabled pptp to make outward pptp connection from lan, so that explains why config was lost…
Sorry for the hassle....

I have a same problem (clients connected can not see each other despite that option being checked).

They do connect to the openvpn just fine (status shows all 4 clients (2 connected through WAN and 2 through LAN)). Firewalls on the clients are off (LAN ones as I'm testing with them for now). Even though I try and ping the correct IPs (as shown by the openvpn status) it still does not work. There is no contact between the clients.

This used to work on 1.2.2 but then I upgraded to 1.2.3 and now to 2.0 beta and no go (both for 1.2.3 and for 2.0 beta). I've tried recreating the tunnel as well as using the old one that worked on 1.2.2 but no go. Clients just refuse to see each other.

This is the client config file if it helps:

client dev tun proto udp remote 192.168.1.1 1196 resolv-retry infinite nobind persist-key persist-tun ca ca.crt cert xxx.crt key xxx.key ns-cert-type server cipher AES-256-CBC comp-lzo verb 3

Anyway I just have no idea how to continue with this so if anyone has any advice it would be very appreciated.