Oh not a bug then, sorry. I now am confused though cause utorrent happily maps ports and I no longer get such errors in pfsense logs. I will try to understand why it looks like it is working fine now.

To make it more complete, should include individual IP graph, for example, select an IP plus show me the values, the graph corresponding to that IP traffic would be excellent and also a more effective visual aid.

Hey,

you're right… radvd stats up automatically.... I didn't notice that.

But there is now another Problem - a big one and a not so big one...

The big one: All IPv6 traffic is routeted absolutely unfiltered to the IPv6 clients rendering the firewall useless….

http://forum.pfsense.org/index.php/topic,65249.0.html

And the not so big one… everytime my IPv6 Address changes, the (linux) clients get an new (good) additional (bad) IP, so after the fourth change the Interface under debian linux looks like this....

ifconfig eth0
inet6-Adresse: 200x:x0x1:3sce:64:exx0:fxfx:fe05:ef24/64 Gültigkeitsbereich:Global
inet6-Adresse: 200x:xxx5:as7e:64:ex40:f2xf:fe05:ef24/64 Gültigkeitsbereich:Global
inet6-Adresse: 200x:x0x1:3sce:0:eax0:f2xf:fe05:ef24/64 Gültigkeitsbereich:Global
inet6-Adresse: 200x:xbx5:ac82:64:ex40:xxxx:xe05:ef24/64 Gültigkeitsbereich:Global

the locallink + loopback + ipv4 Addresses...:-)

But that might be a debian issue.....

Cheers,

4920441

Commit https://github.com/pfsense/pfsense/commit/08597fcc811eaa8299610b1e797b16abe3c7235d Line 485, "if (!empty($_POST['max']))" is overriding a preexisting function below on line 494. From (http://www.freebsd.org/cgi/man.cgi?query=pf.conf&apropos=0&sektion=5&manpath=FreeBSD+8.3-RELEASE&arch=default&format=html#STATEFUL_TRACKING_OPTIONS) that we referred too, there is no traffic prerequisite for using any stateful tracking options except "max-src-conn" and "max-src-conn-rate" which are TCP only, as you have them currently. With the newer change to the filter.inc function we were working on (https://github.com/pfsense/pfsense/commit/dde3cae3dcbd7b64757c66acc4b56f1183831ede) that brings light to this fact, shouldn't some of these validation rules also be changed to reflect this? And while we're here, remove the double occurrence of "if (!empty($_POST['max'])". The function that states the rule must simply be a pass type rule to be accepted being more correct.

I think the basis for rule validation, rather than protocol, should be state type, as described at the very top of the linked section above: "A number of options related to stateful tracking can be applied on a per-rule basis. keep state, modulate state and synproxy state support these options, and keep state must be specified explicitly to apply options to a rule." So any protocol of any state type (basically any pass rule) can use all state options, while keep state must be specified to use the two TCP only "max-src-conn" and "max-src-conn-rate" state options.

Am I making sense here?

New snapshot is up - I have upgraded 2 Alix OK.
2.1-RC1 (i386)
built on Tue Aug 6 16:41:59 EDT 2013
FreeBSD 8.3-RELEASE-p9

@boohoo:

Is this an issue for WAN > LAN > FTP ? I did some editing on my rules table and now I cannot get it to work.. I even reverted back to my original settings.

This thread is NOT for debugging your firewall/server misconfiguration problem, please do not cross-port here.

Back to the topic: no problems after 2 days of testing.

Whenever I get tired of the "missing memory issue" (2016MB inszeead of 2048M in my case), I run vmstat.

That usually yields something like:

1800MB free memory
400MB reserved memory

Nicely adds ujp to 2.2GB. Bingo!

;-)

another thing to watch for when working with Cisco is to make sure that your trunk is using dot1q encapsulation. I believe on the 3750 it will default to ISL. use the command: switchport trunk encapsulation dot1q

Issue this command from the interface.

that didnt work for us, we were still going down, just not notified about it or logging as often. BUT!>>>>

We found this doc on pfsense.org

http://doc.pfsense.org/index.php/Tuning_and_Troubleshooting_Network_Cards

and (knock on wood) we have not had an outage at all today! Maybe we are good? We will monitor over the next week and I'll update if we find anything.

Thanks ssheikh

fstab on NanoBSD isn't used for mounting filesystems at boot time.

If you want it mounted, add an earlyshellcmd to mount it, or even better, call a script that will try to mount it, run fsck if it fails, and then try again.

Similar to what /etc/rc does for / and /cf

For posterity, and anyone else googling in the future, this is now resolved.

The problem I had was that the web sites running against the pools were all password protected to prevent unauthorised access before production could begin.  This meant that when relayd sent out its http(s) checks every few seconds, these pools would return a 401 code rather than the expected 200 code.

Fixing was simply a case of adding a new monitor called HTTPS401, and making sure it checked for a 401 return code, assigning the new monitor to the new pools, restarting the loadbalancer service, and watch the new pools become available.

So simple now I can stand back and see it.

This whole bogonsv6 idea seem to do more harm that good, starting from insane memory usage and ending with blocking legitimate traffic. How about dumping it altogether, huh?

It sounds like the full functionality can (almost) be retained, in case someone does want to listen on just an IPv4 or IPv6 address on an interface. The current selection list displays the "pfSense names" of the various IP addresses of each interface. Keep asking the user for and storing this information in the config. Generate a –listen-address= parameter list like the code does now, but also add --except-interface= for any interfaces which are not selected at all.
A case for which this does not work is:
a) LAN with IPv4 and IPv6 address - user wants to listen on both
b) OpenVPN with IPv4 and IPv6 address, IPv6 link-local address is same as LAN - user wants to listen only for IPv4. The OpenVPN interface can't be put in the --except-interface list.
The user can block IPv6 DNS on the OpenVPN interface to fix this. But not if they want to run a different DNS service that listens there - I am struggling to think of why someone would want to have DNSmasq listening for IPv4 and some other DNServer listening for the IPv6 on the same interface. But having weird use cases that don't quite work is asking for Murphy to come along and invoke his law.

Just tested this and it is working well.

The three cases you mentioned are also working exactly as you described.

I think a minor change in the description of the "Do not forward private reverse lookups" option can remove some of the confusion surrounding the three cases.

Do not forward private reverse lookups
If this option is set, pfSense DNS Forwarder (dnsmasq) will not forward reverse DNS lookups (PTR) for private addresses (RFC 1918) to upstream name servers. Any entries in the Domain Overrides section forwarding private "n.n.n.in-addr.arpa" names to a specific server are still forwarded. Use the Domain Overrides feature to forward a particular private IP address reverse domain or its sub-domain. Parent domains of private IP address reverse domains (e.g. in-addr.arpa, 192.in-addr.arpa, or 172.in-addr.arpa) cannot be used in Domain Overrides if this option is set. If the IP to name is not known from /etc/hosts, DHCP or a specific domain override then a "not found" answer is immediately returned.

Or something like that…

I did finally get around to setting up 2.1RC for this guy out in Denmark who is actually alot smarter than you might think from reading his thread.  Language barrier.  It works well.  When I get time, I''l take a look at his firewall and see if anything weird is happening since he does have a Many WANs running and a ton of computers on the network. I should probably be able to turn on IPV6 for him also and see whats up there.  Initially I made it all IPV4 to save myself a headache in the first day.  I'm sure the firewall logs are just getting hammered right now as I have yet to do anything to it.

Just to confirm in the beginning (a couple of weeks ago) the only way i could get NAT working was using the virtio for WAN and e1000 for LAN
it seems this is/has been fixed as of lately could this have to do with hardware checksums as i have read the post below and adjusted the offload setting and a couple of reboots later i have 2 virtio interfaces WORKING now even for NAT

http://forum.pfsense.org/index.php/topic,50128.msg340321.html#msg340321

Should this option always be disabled when using virtio interfaces anyway??