Did you upgrade from a previous 2.1 snapshot? Did you read the sticky about editing/saving all your gateways?

@jimp:

Commit is inbound for that on snort-dev, I didn't touch snort dev initially.

Thank you Jim! It fired right up after rule update

Try it again now.

Just a quick reminder that file /etc/version_kernel on 2.1-BETA0 23-Jun-2012 still reads 8.1. Shouldn't this be 8.3 ?

@rcfa:

Beginning package installation for Dansguardian . Downloading package configuration file... done. Saving updated package information... done. Downloading Dansguardian and its dependencies... Checking for package installation... Downloading http://e-sac.siteseguro.ws/packages/amd64/8/All/dansguardian-2.12.0.0_1-i386.pbi ...  could not download from there or http://files.pfsense.org/packages/amd64/8/All//dansguardian-2.12.0.0_1-i386.pbi. of dansguardian-2.12.0.0_1-i386 failed! Installation aborted.Backing up libraries... Removing package... Starting package deletion for dansguardian-2.12.0.0_1-i386...done. Removing Dansguardian components... Tabs items... done. Menu items... done. Services... done. Loading package instructions... Include file dansguardian.inc could not be found for inclusion. Deinstall commands... Not executing custom deinstall hook because an include is missing. Removing package instructions...done. Auxiliary files... done. Package XML... done. Configuration... done. Cleaning up... Failed to install package. Installation halted.

This install error should be fixed now (copy/paste error again…)

@cmb:

@rcfa:

But yes, it's better to separate things, it's easy that a bug in a tool creates a lot of damage, when it accesses the file system with root privileges.

Then you don't want to use admin. admin==root

Create another user that has shell privileges to accomplish that.

I did that :)

@rcfa:

So I created a new user named after the web site, made a new group called webmaster, with one privilege, which is to login with a shell. So that user now can sftp in just fine. May have to work on the access privileges a bit such that the user can write into the proper folder, that's pretty much standard stuff, just depends on if/how vhosts works, which is what the whole exercise is all about: having a user that can sftp web site content.

You can uninstall them and the settings persist. The ability to enable/disable is definitely something every package maintainer should be building in and I'd estimate most do. Any that don't, I'd bring it up on the packages board. Service status is not meant to persist across reboots.

@databeestje:

Not sure who the original author was. Maybe we can let Darren have a look and make this into a theme of sorts.

That would be awesome, I really miss having the widescreen feature enabled.

Got another one show up today:

192.168.13.143  00:26:b0:18:4b:86    2012/06/23 05:27:28  1970/01/01 00:00:00  offline  active

Thanks. The CaptivePortal seems to be working. Altough I had to resave the settings to get it working after a reboot.

@databeestje:

I'm pretty sure that nobody has touched the snort package to work with IPv6 yet. So that probably means that if you use snort you kill your IPv6.

You would at a minimum require the local interfaces to be setup in snort to prevent it from blocking it's own interfaces.

Well, I added the IPv6/IPv4 addresses of the tunnel endpoints to the whitelist as well as the, and the various "autogenerated IPs" checkboxes on the whitelist page, so I figured that would do the trick, assuming these auto-generated addresses would take care of both IPv4 and IPv6 addresses, maybe not.
Also, some of the interfaces added to snort only have an IPv6 address, like the tunnel interface, so I also assumed that being able to do that would mean that snort understands IPv6. Similar, I'd have assumed that adding the LAN interface which has both IPv4 and IPv6 addresses, would lead snort to "get it" that these are local addresses.
So how does Snort figure out what is a "Home net" and what's an "External net"???

Oh well…

The real issue that tricked me, however, was that snort was indeed running, while the status indicated that it wasn't...

In any case, for now, snort is disabled, and IPv6 is back. It was already back with snort enabled and blocking disabled, but I don't need snort just to fill my log files with triggered rules, so if I can't use it to auto-block unwanted traffic, it's kind of pointless, particularly given its resource use.

Thanks
So I got my ID10T certification on line!!

Why are you running postfix on NanoBSD? Seems like a disaster waiting to happen…

Doesn't matter how much you increase the space of the ram disk if whatever is filling it up doesn't clean up after itself it will pile up and fill up the larger one, too

Make sure you have no additional spaces.

There are a few ICMPv6 types that are required and thus they are allowed by default in pfSense.

/etc/inc/filter.inc

# IPv6 ICMP is not auxilary, it is required for operation # See man icmp6(4) # 1    unreach        Destination unreachable # 2    toobig          Packet too big # 128  echoreq        Echo service request # 129  echorep        Echo service reply # 133  routersol      Router solicitation # 134  routeradv      Router advertisement # 135  neighbrsol      Neighbor solicitation # 136  neighbradv      Neighbor advertisement pass quick inet6 proto ipv6-icmp from any to any icmp6-type {1,2,135,136} keep state # Allow only bare essential icmpv6 packets (NS, NA, and RA, echoreq, echorep) pass out quick inet6 proto ipv6-icmp from fe80::/10 to fe80::/10 icmp6-type {129,133,134,135,136} keep state pass out quick inet6 proto ipv6-icmp from fe80::/10 to ff02::/16 icmp6-type {129,133,134,135,136} keep state pass in quick inet6 proto ipv6-icmp from fe80::/10 to fe80::/10 icmp6-type {128,133,134,135,136} keep state pass in quick inet6 proto ipv6-icmp from ff02::/16 to fe80::/10 icmp6-type {128,133,134,135,136} keep state pass in quick inet6 proto ipv6-icmp from fe80::/10 to ff02::/16 icmp6-type {128,133,134,135,136} keep state

Well, I can partially answer my own question, but it's not yet fully cleared up.

Messing around with Snort (downloading new rule sets), which showed as NOT being active on any interface in the GUI, IPv6 connectivity suddenly came back. Then it went away again. So I turned off any blocking through Snort, and it remained there for a while, but then, even without any blocking enabled through Snort, all of a sudden the Gateway would always go down, even though the tunnel was/is up…

So something is ill-behaved with Snort. I also can get snort showing as active on at most three out of my four interfaces, doesn't really matter much with three, but the moment I activate a fourth interface, one or more of the others go red.

So I'll reboot the system once, and like deinstall snort until that can at least be installed and not block anything when it's told not to block anything...

...hopefully then I'll have IPv6 back.