Ah ok. Thanks for the quick reply : )

The kernel file seems missing. Which file is about to be loaded? Should I be able to load it manually? Update: A sober thought: This really should have been todays snap. The update really messed up. Full install should work. Update2: Latest snap is running since 1 hour.

@elijahmm: I have the same problem.  I'm looking into rolling a custom PFSense just to get this fixed.  Have you found a better solution yet?  It seems to be dependent upon the speed of the connection to the client as well. Sorry, no soloution yet. Not sure where to take it from here. Regarding the connection speed, I have seen the same thing, seems as if it works more often on a faster connection.

I have this problem with 2.0-RC1 from hacom, is this a known issue with that build? @UrbanSk: Running latest bet: 2.0-BETA5 (i386) built on Thu Feb 10 22:00:00 EST 2011 After installing the latest snapshot I started seeing this in system logs: Feb 11 16:59:50 miniupnpd[57746]: ioctl(dev, DIOCCHANGERULE, …) PF_CHANGE_GET_TICKET: Operation not supported by device Feb 11 16:59:50 miniupnpd[57746]: ioctl(dev, DIOCGETRULES, …): Operation not supported by device Feb 11 16:59:49 miniupnpd[57746]: ioctl(dev, DIOCCHANGERULE, …) PF_CHANGE_GET_TICKET: Operation not supported by device Feb 11 16:59:49 miniupnpd[57746]: ioctl(dev, DIOCGETRULES, …): Operation not supported by device Feb 11 16:59:07 miniupnpd[57746]: Failed to add NAT-PMP 50189 udp->192.168.10.44:50189 'NAT-PMP 23652' Feb 11 16:59:07 miniupnpd[57746]: ioctl(dev, DIOCCHANGERULE, …) PF_CHANGE_GET_TICKET: Operation not supported by device Feb 11 16:59:07 miniupnpd[57746]: ioctl(dev, DIOCGETRULES, …): Operation not supported by device Feb 11 16:59:07 miniupnpd[57746]: Failed to add NAT-PMP 50189 tcp->192.168.10.44:50189 'NAT-PMP 23652' Feb 11 16:59:07 miniupnpd[57746]: ioctl(dev, DIOCCHANGERULE, …) PF_CHANGE_GET_TICKET: Operation not supported by device Feb 11 16:59:07 miniupnpd[57746]: ioctl(dev, DIOCGETRULES, …): Operation not supported by device Feb 11 16:59:06 miniupnpd[57746]: ioctl(dev, DIOCCHANGERULE, …) PF_CHANGE_GET_TICKET: Operation not supported by device Feb 11 16:59:06 miniupnpd[57746]: ioctl(dev, DIOCGETRULES, …): Operation not supported by device Feb 11 16:59:05 miniupnpd[57746]: Failed to remove NAT-PMP mapping eport 50189, protocol UDP Feb 11 16:59:05 miniupnpd[57746]: ioctl(dev, DIOCGETRULES, …): Operation not supported by device Any hints? /UrbanSk

BUMP: discovered the source of the issue however cannot get a carp failover working with ipsec as a result of this "issue"

No. What I had to do is to set up IP Passthrough on my VDSL router (Motorola Netopia 7357-84, http://www.netopia.com/swisscom/firmwareA.html). If I bridge the VDSL router, the internet stopped working every about 2 weeks. Then I had to reboot the pfsense. With this IP Passtrough I have a stable internet within sevaral month (on pfsense V1.2.3)…

Most of those should be fixed in new snapshots, but I did find a couple issues with theme colors (in the corporate and nervecenter themes). https://rcs.pfsense.org/projects/pfsense/repos/mainline/commits/0ef48aed8b6b9098c924229f725e12b3f7ec7013

hi ermal; i forgot to update this post. someone else was experiencing the same issue so we worked it out on another thread with jimp: http://forum.pfsense.org/index.php/topic,35024.0.html

Passing from a hostname works last I tried it. Can you look under Diagnostics > Tables, and pick the entry from the list that corresponds to your alias name, and see if there is an IP in there and that it's correct? Someone found a bug in the filterdns daemon which monitors DNS entries last night or so, and it should be fixed in the next new snapshots, so updating later today might be useful as well.

Outbound PPTP is meant to connect to ISPs that require that for a specific connection type. It's not meant to be used for a site-to-site VPN.

@onhel: @clarknova: You could always PM them or post to the mailing list. From what I've seen, Jimp is the most accessible on these forums and if you've ever seen his signature it states in sum and substance, Dont PM me for sh*. ;) Reporting a broken builder is fine, it's the dozens of people who PM me asking me for personal help with $random_config_issue that the signature is aimed towards (and yet still gets ignored… ;-)

Thanks for support. This comes as a slap on the forehead and here's why. I tried to replace an old firewall with this pfsense 2.0RC because I liked it when I tested it and for the main reason that it does Fail Over and Load Balance. While replacing the old firewall which was the gateway situated at x.x.x.254 the new one is situated at x.x.x.1. Since what was getting it's IP from DHCP was working fine, my issue started with the servers that had static IP because they had the OLD GATEWAY in their settings. That's why they were replying to the pings inside the lan. As soon as I changed to the new gateway which is the firewall mentioned in this post the port forward came back to normal. Told y'all that it must be a glitch somewhere, this time was in my head :) Thanks again.

Well, I think what I'll do tonight (if I can schedule the downtime) is revert to the "factory" RC1 without importing my config, then play around with the user manager to get a feel for how it interacts with SSH out of the box. When I import my config, I'll try to hand-edit the current 'root' username to anything else except 'root'/'admin' and see if it behaves any differently. I wasn't suggesting we outright block users from being able to do these things, but maybe there should be a simple notice somewhere explaining that they might have unintended or non-obvious repercussions. (Kind of like how pfSense now warns not to use .local as a LAN domain name – you still can if you really want to.)

ermal, if so, then what I want is possible? I just need to bridge the two interfaces?

I think there are plans to include it by 2.0, but it's hard to say for sure at this point. It's easily added, and it would be something that some people may not want, so there are some considerations to be taken there. As it is, even without sudo, you should consider every shell user as having root access, due to the info found in files on the firewall that are world readable for various reasons. So only those you'd trust with admin access to the firewall should have shell access.

I'm not sure offhand of a comparison site, but the FreeBSD man pages have info on both. http://www.freebsd.org/cgi/man.cgi?query=gif&apropos=0&sektion=0&manpath=FreeBSD+8.1-RELEASE&format=html http://www.freebsd.org/cgi/man.cgi?query=gre&sektion=4&apropos=0&manpath=FreeBSD+8.1-RELEASE

Fixed thank you for reporting. Try with new snapshots.