Well, I did some tests and it "seems" that actually works using the multiwan/multilan wizard. Penalty box seems not to affect bursts but I notice a lot of rate drops.

Thanks, good to know that.

failblog.org comes to  mind.

confirmed,  I just loaded the most recent release and it works fine now.

Jim

Thanks for the info.  I will give it another go shortly.

Thanks guys for the confirmation.  This help configuring the whole thing when you know that!

Thinking about it more, what would happen and what should happen with NAT reflection if the user selects "any" for external address?  Maybe that change you made with $extaddr might prevent the case I'm thinking of where it might possibly redirect all outgoing connections on that port if the user selected "any" for the external address.  For example, if it does what I'm thinking it might, forwarding port 80 on an external address of "any" with NAT reflection on might redirect all web sites to the local web server that the port forwarding rule directs it to.  What I'm describing sounds related to a bug I recall reading about in a recent forum post (on 1.2.3, I think).

update:

Actually, the bug I was thinking of was mentioned early December on the 1.2.3 rc forum, but it did not ever get any replies, probably because of the 1.2.3 release shortly after.

no config just try to active them with the checkbox

Looks like there were some broken patches, it might build now, but needs to be kicked off again.

There's no harm in writing it out every time (it would probably take a few thousand years to hit the write limit with what happens during reboots), and if you don't, it creates a huge number of possibilities for bugs or other inconsistencies.

I had 1.2.3-beta (don't remember which version) running about a year ago with a Millenicom/Verizon EV-DO USB key running into the little 3G router they sell (which I don't recommend–flaky firmware).  I had this set up to load-balance between that and a partial T-1 we had coming in (the rest went to actual DS0 phone lines).

There was a problem with the load balancer losing packets while testing whether the EV-DO connection was up and so it would flip up and down, or just stay down quite often, especially when Verizon's network was under load during rush hour (we're right next to a major freeway).  I BELIEVE this has been fixed by the time 1.2.3 went into final release, but I'm not positive and haven't tested it--we dumped both and went to a WiMax connection from a local provider that, once finally set up, has been very reliable. (And why not DSL or something?  Qwest/U.S. Worst wouldn't give it to us, saying we couldn't have that and the T-1 running.  We're at the very limit of the loop, several miles from the CO and NO DSLAMs in between!)

I guess one problem is, do you really need the hard-core filtering a full pfSense setup provides or do you just need the connectivity?  Considering that, by your words, this is in the middle of nowhere, perhaps security isn't important enough to really worry about compared to, say, keeping power consumption low and having a reliable box with firmware that doesn't crash--this last bit being the most important since there won't be anyone around to reset the box!  Price tags mean nothing in that department unless you go carrier-grade (expensive Cisco stuff, say).

Mike

UPnP traffic will go into the queue given on the UPnP configuration screen. If it's VOIP traffic or bittorrent traffic, it doesn't matter, it all goes into the queue you give for use by UPnP.

The UPnP rules are inserted dynamically and won't show up in the GUI. They are not permanent; the rules come and go. If you really want to view them, go to Diagnostics > Command and run:

pfctl -vvsn -a miniupnpd

UPnP traffic is not monitored specifically, as there really isn't a good way to track it. You can get a byte count out of the command above, but that would only track incoming packets, not outgoing.

You don't need to add anything to let UPnP work, just enable it, and it should take care of the rest.

That problem was fixed quite a while ago. Update to a recent snapshot and it should work.

you right.. layer7 doesn´t work anybody knows when will be fixed? because I want to use pfsense 2 Beta

@jahidhk:

It's does not caching anything
& lightsquid cant install…..........

The Squid packages haven't been updated to work with 2.0 yet.

When it's done…

They said in 2010. 2.0beta has a looong way to go...

OK - so heres me from one of my live internet [as in colo - no dmz, no nat or anything] web servers

AAA.BBB.CCC.200 - my personal server in DMZ [behind pfsense - public IP routed - no natting - routed in via cisco sdsl router - then next fixed route to pfsense box on WAN1 ]
( AAA.BBB.CCC.200 has a gateway (DMZ1 on pfsense) at AAA.BBB.CCC.193 and a mask of 255.255.255.224 - so in range AAA.BBB.CCC.192 -> AAA.BBB.CCC.223 [ a /27 ] )

AAA.BBB.CCC.228 - a company server, on standard public IP in a data center
( AAA.BBB.CCC.228 has a gateway at AAA.BBB.CCC.225 and a mask of 255.255.255.240 - so in range AAA.BBB.CCC.224 -> AAA.BBB.CCC.239 [ a /28 ] )

DDD.EEE.FF.219 - the public IP of the adsl connected to wan3 on my pfsense box

From AAA.BBB.CCC.228 :

I fired off a 'telnet AAA.BBB.CCC.200 80' captured with 'tcpdump -n' [ diag_packet_capture.php doesn't want to show any capture at the mo]

10:19:37.476767 IP AAA.BBB.CCC.228.49940 > AAA.BBB.CCC.200.80: S 2457225471:2457225471(0) win 5840 <mss 1460,sackok,timestamp="" 1076751111[|tcp]="">10:19:37.479894 IP DDD.EEE.FF.219.53622 > AAA.BBB.CCC.228.49940: S 712187932:712187932(0) ack 2457225472 win 5792 <mss 1460,sackok,timestamp="" 318338740[|tcp]="">10:19:37.479904 IP AAA.BBB.CCC.228.49940 > DDD.EEE.FF.219.53622: R 2457225472:2457225472(0) win 0

And again - From AAA.BBB.CCC.228 :

I fired off a 'telnet AAA.BBB.CCC.200 25' captured with 'tcpdump -n' [ diag_packet_capture.php doesn't want to show any capture at the mo]

09:53:35.427471 IP AAA.BBB.CCC.228.49843 > AAA.BBB.CCC.200.25: S 2411757476:2411757476(0) win 5840 <mss 1460,sackok,timestamp="" 1076360598[|tcp]="">09:53:35.499524 IP DDD.EEE.FF.219.64428 > AAA.BBB.CCC.228.49843: S 2037136731:2037136731(0) ack 2411757477 win 5792 <mss 1460,sackok,timestamp="" 318182522[|tcp]="">09:53:35.499536 IP AAA.BBB.CCC.228.49843 > DDD.EEE.FF.219.64428: R 2411757477:2411757477(0) win 0

From any other machine i have tested from thge telnet request connects
[ I think what makes this a special case is that AAA.BBB.CCC.228 is a server we connect to (almost constantly) from our LAN, via WAN3]

I have included the network setups as these ranges are neighbours - which throws up the possibility of me doing something wrong in the basic mask setup etc

As far as I can see,

AAA.BBB.CCC.228 connects to AAA.BBB.CCC.200 [ comes into pfsense on wan1 and goes to AAA.BBB.CCC.200 out of dmz1 ]
AAA.BBB.CCC.200 replies to AAA.BBB.CCC.228 [ comes into pfsense on dmz1 and exits pfsense on wan3 [ why? ] getting natted on the adsl router attached to wan3  ]
so AAA.BBB.CCC.228 doesn't see it as an ack from AAA.BBB.CCC.200

I cant understand why the return path is through wan3 not wan1

Am I right in thinking that the firewall rule allowing the inbound connection should route the reply back out the way it came in ??
I am therefore presuming that this is taken care of by the rules on wan1 and the rules on dmz1 dont come in to it ??

I am at a bit of a loss :

I still think that there is a possibility that a (routing/firewall) rule matching a.b.c.d:m -> e.f.g.h:n maybe catching a.b.c.d:n -> e.f.g.h:m
[ transposing the ports - as if the check is are do the ips match && do the ports match, rather than does the ip/port combo match ]
however I imagine that this would cause more problems and would have been noticed : but then that is the point of BETA - so maybe thats the issue

The only other thing that occurs is maybe i should be aliasing AAA.BBB.CCC.192 ( the network address for teh DMZ if you will ) onto WAN1 ??
[ as it stands it just has 10.0.13.2 with the sdsl router on 10.0.13.1]

Any thought would be appriciated,
Sorry for the mammoth post

TIA

puge / DennisBagley</mss></mss></mss></mss>