This is my nat.xml and aliases.xml zipped. You'll have to change the extension. nat.png

Squid uses pfsense dnsmasq and all nameservers in "resolve.conf". Local ip numbers (like your "spotweb" site) would be sent to upstream nameservers. I've also set my dnsserver in squid to 127.0.0.1 (different from default, "empty") Now only pfsense dnsmasq is used for lookups (and lookup-cache) in squid.

Like JimP said you would have to copy it across from FreeBSD 8.1. I believe you could use the PCBSD 8.1 live cd for this purpose. It looks like your problem has already been solved though.  :) Steve

Confirmed working on the latest 64bit build. Thanks  :)

Looks like this is fixed with the latest update.  Sweet.

Aliases are strictly in pf, captive portal is in ipfw.

@ermal: Well pftop i will see if can be fixed to at least show action match and not action 11. But really the match action rules will not have counters updated for the traffic they match. This is a deficiency on 2.0 i might see what are the impacts of having that corrected are. Then I must return to old pass out rules. When I make changes I would like to see the effects and pftop is the only tool for it. I can't live without it. @ermal: About the panic a minidump report would have been nice. AFAIK there are no more issues related to panics and belived me Feb 14 is quite a dangerous snapshot for some uses :) Sorry. The panic occurs during a very busy work time. I went back to whatever snapshot I have in hand as quick as possible so that users couldn't even notice it :P . I now update to the latest snapshot. Many thanks.

@ermal: It should. Show me your system log? Mar 27 23:35:28 apinger: /usr/local/bin/rrdtool respawning too fast, waiting 300s. Mar 27 23:49:06 apinger: ALARM: OPT1(4.2.2.1) *** delay *** Mar 27 23:49:14 apinger: alarm canceled: OPT1(4.2.2.1) *** delay *** Mar 27 23:49:16 check_reload_status: reloading filter Mar 27 23:49:16 php: : MONITOR: OPT1 has high latency, removing from routing group Mar 27 23:49:24 check_reload_status: reloading filter Mar 28 00:14:14 apinger: ALARM: OPT1(4.2.2.1) *** delay *** Mar 28 00:14:22 apinger: alarm canceled: OPT1(4.2.2.1) *** delay *** Mar 28 00:14:24 check_reload_status: reloading filter Mar 28 00:14:24 php: : MONITOR: OPT1 has high latency, removing from routing group Mar 28 00:14:32 check_reload_status: reloading filter Mar 28 00:16:28 sshd[50078]: Accepted keyboard-interactive/pam for root from 192.168.1.244 port 17385 ssh2 Mar 28 00:20:30 login: login on ttyv0 as root Mar 28 01:01:00 php: : DynDns: Running updatedns() Mar 28 01:01:00 php: : DynDns: updatedns() starting Mar 28 01:01:00 php: : DynDns: _detectChange() starting. Mar 28 01:01:00 php: : DynDns: _checkIP() starting. Mar 28 01:01:00 php: : DynDns debug information: 76.102.159.xxx extracted from local system. Mar 28 01:01:00 php: : DynDns: Current WAN IP: 76.102.159.xxx Mar 28 01:01:00 php: : DynDns: Cached IP: 76.102.159.224 Mar 28 01:01:00 php: : phpDynDNS: No change in my IP address and/or 25 days has not passed. Not updating dynamic DNS entry. Mar 28 05:46:59 apinger: ALARM: WAN(76.102.152.1) *** delay *** Mar 28 05:47:09 check_reload_status: reloading filter Mar 28 05:47:09 php: : MONITOR: WAN has high latency, removing from routing group Mar 28 05:47:34 apinger: alarm canceled: WAN(76.102.152.1) *** delay *** Mar 28 05:47:44 check_reload_status: reloading filter Mar 28 06:58:47 apinger: ALARM: WAN(76.102.152.1) *** delay *** Mar 28 06:58:57 check_reload_status: reloading filter Mar 28 06:58:57 php: : MONITOR: WAN has high latency, removing from routing group Mar 28 06:59:15 apinger: alarm canceled: WAN(76.102.152.1) *** delay *** Mar 28 06:59:25 check_reload_status: reloading filter Mar 28 07:56:47 dhclient[59901]: DHCPREQUEST on em0 to 68.87.76.39 port 67 Mar 28 07:56:47 dhclient[59901]: DHCPACK from 68.87.76.39 Mar 28 07:56:47 dhclient: RENEW Mar 28 07:56:47 dhclient: Creating resolv.conf Mar 28 07:56:47 dhclient[59901]: bound to 76.102.159.224 -- renewal in 172800 seconds. Mar 28 09:41:29 dhclient[53425]: DHCPREQUEST on re0 to 68.87.76.39 port 67 Mar 28 09:41:29 dhclient[53425]: DHCPACK from 68.87.76.39 Mar 28 09:41:29 dhclient: RENEW Mar 28 09:41:29 dhclient: Creating resolv.conf Mar 28 09:41:29 dhclient[53425]: bound to 76.126.99.181 -- renewal in 172800 seconds. Mar 28 13:33:26 apinger: ALARM: OPT1(4.2.2.1) *** down *** Mar 28 13:33:36 check_reload_status: reloading filter Mar 28 13:33:36 php: : MONITOR: OPT1 has high latency, removing from routing group Mar 28 13:33:42 apinger: alarm canceled: OPT1(4.2.2.1) *** down *** Mar 28 13:33:52 check_reload_status: reloading filter Mar 28 14:47:12 php: /index.php: Successful webConfigurator login for user 'admin' from 192.168.1.118 Mar 28 14:47:12 php: /index.php: Successful webConfigurator login for user 'admin' from 192.168.1.118 Mar 28 16:59:38 php: /index.php: Successful webConfigurator login for user 'admin' from 192.168.1.244 Mar 28 16:59:38 php: /index.php: Successful webConfigurator login for user 'admin' from 192.168.1.244 I don't think anything is important going on here.

So I just figured it out.  On the NAT rule I had to enable NAT reflection (the default setting is off).

search the forum… snort for 2.0 has a few bugs in it... the dev is working on it... no eta for its release yet. usually packages aren't created by the main dev team for pfsense... because of this, if something changes in the pfsense core itself, pfsense packages wont work untill they are updated.

I am having this same issue.  I know my NAT is working fine because it works great if I hit the IP from an external network.  But as soon as I try and hit it from within my pfsense network, it always redirects.  Its doesn't matter what port webGUI is running on or whether that redirect box is checked or not.

Here the generated ospfd.conf file by the gui: router-id 172.18.0.1 redistribute default area 0.0.0.0 {         interface sk1_vlan200         interface sk2_vlan201 } Is a simple configuration :-). When I will install the next one I will do it with the last version. Then I will paste the logs. Best regards.

I had the same problem too… now it's solved with build "Mon Mar 28 07:13:56 EDT 2011"... the problem was affecting only the x86 version...