@kejianshi: It is a good idea, but he didn't seem like the remote logs server type (-:  I could be wrong.  Seriously, 99% of people who would put a regular HD in a PFsense box would just do a full install on that HD and be done with it. Yes, that is fine if you use pfSense just as a simple firewall and router, but if someone uses services for penetration prevention like snort, squid+squidguard, HAVP and others, a huge logging partition is needed to figure out intrusion detection. Mere a simple firewall and router can be run from a floppy disk, still, but pfSense I guess has a larger scope. Just my two cents.

@jimp: poison. lol! Like the term, jimp!

My initial testing indicates it's working for me too.  Thanks much.  This was a PITA. If I have a gateway I have not updated and run into this, can I just run: /sbin/sysctl net.link.ether.ipfw=1 net.inet.ip.fw.one_pass=1 to get the portal working again? Thanks again.

@ermal: Did you do any changes to yoru firewall? Seems you had rules for ipsec and have disabled it? IPSec should never be disabled, because ALL IPv4 traffic to the public internet is routed through my IPSec link. No IPSec, no internet for me.

@wallabybob: Depending on your bandwidth requirements, you could use a VLAN capable switch acting as a port multiplier for one of your existing NICs. Yes, it would be a nice workaround, but streaming from and to the mediaservers in the DMZ would be slowed down. Not that it would take the full Gbit link, but I gave it a try before I bought 2 dual port NICs ;) @zenny: The easiest and more reliable would be go for two quad-port intel/broadcom NIC (a bit expensive option but worth your time, imho). Forget about RealTek it gave me immense problem in the past and lost several hours to make it work, fyi. Well, then i will have to buy one or build a new box. @zenny: FreeBSD 9.1 does not seem to have this problem (http://forums.nas4free.org/viewtopic.php?f=58&t=953#p3465), but pfSense 2.1 is still based on FreeBSD 8.3! According to jimp (read somewhere in the forum), the next version of pfSense would be based on FreeBSD 10 as the pfSense developers are skipping v 9.x! Thanks for this info :) But it will take much too long to wait for the next release ;) br, stephan

Yeah, the bogonsv6 thing is insane for embedded systems. As for logging of IPv6 by default rules, some recent change (a couple of days ago) caused some more nonsensical logflood by logging link-local traffic on LAN. Why, goes beyond me. All LAN IPv6 traffic is permitted. [image: 2uzc611.png]

Thanks, that is what I have been searching for. @jimp: But what made you think that I am one among the 'faint of heart'? ;-) Anyway, thanks for the pointer. :D

Thnx Jimp Squid3-dev is installed again!

Yes my WAN is pppoe. I found a solution if I add the virtual ip on the Localhost Interface it works like a charm. If the VIP is on the WAN Interface I get TTL expired. So thanks for your help  :) regards supermega

This was stuck way back in my Inbox, meant to poke at it again. This works for me on a system that has no trace of nmap. Note that this is not the exact same script posted earlier in the thread, but an updated version. : /etc/rc.conf_mount_rw  (NanoBSD only) : cd /root; fetch -qo /root/ http://files.pfsense.org/jimp/update_oui.sh ; sh update_oui.sh : ls -l /usr/local/share/nmap/nmap-mac-prefixes -rw-r--r--  1 root  wheel  520508 Jul 16 13:03 /usr/local/share/nmap/nmap-mac-prefixes I was going to make a package for it, but then I thought better of it. We don't need an extra 0.5MB in the package repo and it will need to be manually kept up to date and it's just not really worth the hassle. If we gzip it we'd have to put it on another server (no binaries allowed in the pkg repo) and it would be more difficult not only to update it, but to remember to update it and bump the pkg version, etc. Most people are OK with the nmap version, those that aren't can just grab this and run it manually. If I can get some confirmation that it works I'll write up a short doc wiki article on it.

Managed to solve this in the end, after I remembered similar weirdness on my main firewall (full install) which I upgraded several weeks before. I removed the following tags from my config <dns1gwint>wan</dns1gwint> <dns2gwint>wan</dns2gwint> <dns3gwint>none</dns3gwint> <dns4gwint>none</dns4gwint> and kept what was already there <dns1gw>WAN_IPV4GW</dns1gw> <dns2gw>WAN_IPV4GW</dns2gw> <dns3gw>WAN_IPV6GW</dns3gw> <dns4gw>WAN_IPV6GW</dns4gw> I performed a config restore and apart from an initial "out of swap space", everything has been back to normal now for a few days. Im not sure if those tags I removed were migrated over from my 2.0.3 > 2.1 upgrade but it seems to sorted out a lot of weirdness I was experiencing, just thought I'd post in case someone was having similar issues. Cheers

dgwilson, Maybe too late but did you try the HP diags with the D-link card out of the machine?

Give it another try with a current snapshot, it should be fairly stable now.

I would agree about it being nice to be able to sort the IPs in an alias. Not to hijack your thread but, on the firewall log screen, I was wondering about the reason for having two different ways of doing the reverse lookup of the IP address. Also I thought that an easy block(pass) rule seemed a bit pointless if the traffic had been blocked(passed) in the first place.  Could the icon just be in a new "easy rule" column at the end and be a block if the traffic had been passed or vice versa? I realize it would have to put the easy rule above the one that caused the log entry in the first place.  That may not be possible.

All the changes have been merged into the 2.1 branch. They are in the latest build and working.

Was there a resolution to this issue? If so, can someone share it? Thank you.

Yeah for god's sake give as NAT66! Just one line code! :-)