So it does pull its IP from the RG via DHCP in that passthrough mode, just the public IP? In that case it should act the same as the modem, with a very short lease time and the RG should hand it its new IP when it gets one. That apparently doesn't work right on the RG (damn things are buggy as hell if you try to do anything other than using it as your NAT device, so that wouldn't surprise me in the least). The firewall you put behind it isn't "detecting the IP change", the RG has to assign it the new IP via DHCP and such devices generally do so quickly by assigning very short lease times. If it's not handing out very short leases, it'll take time until the lease is renewed and the new IP picked up. Doing double NAT isn't the best thing in the world, but I would expect that to behave better on the RG, and its regular DMZ mode seems to work fine. There isn't a functional difference between the two.

If I've learned anything in having the misfortune of working with those Uverse RGs on mine and several customers, it's do what works on the RG and be glad it's working. From its crappy stateful firewall that can't be disabled even with a static IP assignment (disable firewall doesn't disable anything), to numerous bugs throughout other things, those RGs suck.

I think see what you were saying in your original post.  Do you have NIC2 on the desktop PC connected to the WAN port of the wireless router?

What model of wireless router are you using?

Sorry I did not make this clear enough,  I suppose you are correct I can setup my cdn (Canadian) users to vpn into my US Pfsense box, currently I installed ccproxy on a windows server on the US side but I prefer not to run apps on the server can I use the proxy on the pfsense to accomplish the same task without a VPN?

Thank You,

Marcelloc - thanks for that - I really appreciate it. I'll check it out.

SPAMD should do what I want but getting it configured nicely is a pain. I've found that some of the spammers have already overrun the grey listing so I switched to black listing instead. It seems that I need to manually whitelist valid incoming connections using the SPAMD whitelist tab rather than the SPAMD Database tab - whitelist buttons.

I think I see the difference in the mechanics at play here. But without a method for working out who's connecting (other than tailing the damn logs and checking the IP addresses) how am I supposed to know what incoming mail to whitelist?

SO - your option may well turn out to be the best choice.

interfaces is not eth# named. those are named with drivers. ath# or em#

easiest way to do it is connect cable to that interface what you want to assign(other end of cable has to be in switch) and press a.

No bridging going on, but it looks like I might have had a breakthrough.
As per my previous thread, we are replacing our linux gateways. So far the pfsense and linux gateway have been active at the same time on one particular vlan. As soon as we disable on or the other gateway, the network stabilizes. There is only one dhcp server on the troublesome vlan. I'm not quite sure what is going on, but at least I have a starting point.

Do you mean, your DHCP server is not pfSense … its on your VLAN. And clients on WIFI dont get an IP adress? You have to setup extra rules for that kind of traffic. IMHO it*s not enough to allow ANY to ANY ...

Yes, you have heard right! You have to set a extra rule for this ... dont know exactly, but search for bridge and dhcp in the forum. There is a thread which is explaining the issue.

Yesterday the pfsense box went back to dropping all packets on trunk interfaces, even though the card was in promisc.
The only thing we did that could have upset it was to unplug its trunk port for a while, however repeated tests do not seem to cause the problem.

A reboot brought it back to full functionality.

Evidently, there must be some bugs in the kernel network code - but as long as I can't figure out how to reliably reproduce the problem, there's a very low chance of it getting fixed. (Although maybe if the the network developers fixed the trunk+custom-mac+promisc problem they'd stumble across the cause of this other problem :)

In any case, I'm brand new to the pfsense/bsd world. (I'm heavily familiar with networking at the packet header level and Linux, so I understand the general concepts)

Does anyone have advice for me? Is this a bug that can likely be fixed by the wonderful volunteers who write BSD kernel drivers, or am I pretty much stuck, especially so long as I can't easily reproduce the problem?

I really do need to use custom mac addresses and vlan interfaces together, and it certainly wouldn't do to have a router that arbitrarily stops passing traffic for an unknown reason :-)

Thanks a million!

~Jesse

@Nachtfalke:

If the range ist 192.168.100.100 - 192.168.100.200 then assign static addresses to 192.168.100.201+ and create a firewall rule which blocks traffic for these source IP addresses.

That's both obvious, and brilliant! I really should of thought of that  :-[

Thanks for the suggestion.

Welcome to the forum!  :)

Don't try to do everything at once.

A lot of new users come from another firewall or router and they try to replicate all the functionality of that in one go. Then when things don't quite go to plan it can be much harder to find the problem.
Start with the most basic setup you can and then, when you're happy with that, add more complex configuration one step at a time.

Steve

@pf2.0nyc:

Are you running multiple WAN or any type of load balance?

Nope i found solution it has been problem with ADSL line and some https traffic.

Sooo… I guess I got plans for the weekend: Reinstalling pfsense! =P

Was a network card issue as far as I can tell.

With new boxes - no loss, however I haven't tried with the onboard broadcom cards (which was what I was partly using before).

The reason for the carp is if either of the routers falls over - plus it means we can upgrade one and have the other running happily.

We do have a 2nd ISP, but no IP range with them…. it was never setup correctly in the past and I'm doubtful of it happening now - too much chance of knocking everything offline by accident.

@jimp:

You'll need to grab the commits here (or make changes manually), seems there is a bit of an issue with how things were laid out.

https://github.com/pfsense/pfsense/commit/54d1a165d500225547337ddba7aa10e7e5f79c98
https://github.com/pfsense/pfsense/commit/07c49a3698ab458ea7ad8c0501d394c09e48dc60

Works Perfect ! thanks

The next version of pfSense will be based on FreeBSD 9.X and hence will have those drivers. That's some way down the road however.  ::)

Steve