yep doesn't seem to be working. It seems like the combination of these two features would be pretty common. I would like to help test and figure out how to make them work together.

@clarknova:

As I recall, if the modem was giving me a 192.168.100.1 address, the lease was very short, like under a minute, in which case pfsense should be getting a proper address very shortly after you reboot your modem. Obviously this is not the case for you.

Not necessarily - the first thing any DHCP client will try is to renew the existing lease when it has one, which the modem will likely accept, and it'll keep on renewing that IP indefinitely.

nojstevens - Your issue isn't related to the firewall at all (any DHCP client would have the exact same issue, it's just taking what it is being assigned), something is causing the modem to assign it an IP rather than one from the ISP. I suspect it's related to your microcell, it's probably picked up your public IP, leaving any other device stuck with a lease from the modem. As for it not doing that initially, initially your firewall won the race to get the public IP. Unpredictable things will happen with a setup like that. Put the microcell behind the firewall, power cycle the modem, don't plug anything else between the modem and the firewall's WAN, and you'll likely be set.

But you are also showing that you changed the port number.

I fixed this by deleting the wedges off the config and reinstalled.

Mine works on the latest snapshot. Your gateways showing online in Status >Gateways?

I just verified that radius authentication to the web gui is working. It is also falling back to local database is radius authentication fails.

Thanks very much ermal, for your support on this!
Brett

If that proxy can act transparently, it might be possible to add a NAT rule which would match the traffic heading to that subnet and direct web access heading that way into the proxy.

Hi, Efonne,
that's the only way in which I work, you know another way to do better? as I can give you access to a captive portal users?

Thanks, I'll give it a try.

You do not need outbound NAT for the VIP if you are using 1:1.

A 1:1 NAT entry for 115.78.142.88/32 to 172.16.0.100/32 should be all you need, provided you picked the "WAN" interface on its settings.

The FreeBSD supported hardware list for version 8.1 (http://www.freebsd.org/releases/8.1R/hardware.html) lists the Abocom FE2500 so your card should work.

I would guess that this card was last tested a few releases ago and some change in teh meantime broke the support. If you want it fixed you will probably have to report it to a FreeBSD forum or lodge a problem report.

The fastest resolution would probably be to purchase a more recent cardbus card.

@Supermule:

Its bloody annoying to be honest…..:S

Why do you say that?
It's not me that write: "Requires a minimum of three public IP addresses (will be resolved in a future release)" ->PUBLIC (http://www.pfsense.org/index.php?option=com_content&task=view&id=40&Itemid=43).

With this , we can think that will not work well with private address it's why i ask for a solution…

++

Redmine has a roadmap.
http://redmine.pfsense.org/projects/pfsense/roadmap

I noticed that a couple days ago too.
http://redmine.pfsense.org/issues/777