I removed for now the imspector-wip package, since its settings page didn't load correctly, so maybe that points to some other issues that might cause this. If after the next build is available I autoupdate, and have the same issue again, I know this wasn't the solution, and will investigate further.

Currently the config history starts with an entry that corresponds to when I did the last autoupdate, and it reads simply:

"7/26/11 07:10:12 (system): made unknown change "

No shit! :D

What follows later are only the changes to reconfigure the packages and the deletion of the imspector-wip package.
The problem will be: if the problem persists, then it looks like it not only resets the packages, but also the config history, which makes it kind of difficult to trace what's going on.

Try to reinstall it again now. There were some binary updates to the packages that didn't go quite right. Though the correct files should be up now.

On 2.0 there is a daemon which periodically updates hostnames used in aliases. It's safe to use even dyndns entries there these days.

That has zero to do with the snapshot you are on. That is with the package binaries on the server, which are completely independent from snapshot releases.

That's is more likely. Should be easy enough to yank the card and test without it.

@sn00p:

Hi,

We've been running pfSense at work for quite a few years, we initially set it up to bridge our "building control" network to our lan.  The lan has unrestricted access to the building network (OPT1) and they are configured as a bridge.  The OPT1 interface has very limited access to the LAN, for example we allow UDP broadcast packets on a certain port through to the LAN as they are packets from our building control system.

It's worked fantastically.

However, the ability to VPN into the network from the WAN side has always been something that we'd like to do, especially with iPhones.  Obviously pfSense 2.0 has a working implementation of IPSEC that plays nicely with the iPhone.

So, following various guides in here I successfully created an IPSEC configuration that allows my iPhone to connect.  All good.

However, although I can see machines on the LAN, I cannot see any of the machines on the OPT1 side (anything on the bridge).  I can't see any obvious answer as to why this would be, there doesn't appear to be anything in the logs saying that anything was explicitly blocked.

I'm not at work now, so I can't post any specifics of the configuration at the moment, I was just wondering if there are any "gotchas" that I should be aware of?

Our network is running in the 10.0.0.0/8 space, with our building control devices living on 10.0.X.X and lan side DHCP machines on 10.5.X.X and servers on 10.6.X.X, the exception is the pfSense machine that lives on 10.5.0.1.  Our building control devices have a simple web page which just shows the state of their operating system, one of them lives on 10.0.0.1 and I can see this on my machine from the LAN without any issues, however, as soon as I VPN in I cannot see it anymore, I can however quite happily see the pfsense box or anything else on the LAN side.

I appreciate you'll probably need some more detailed configs, but I thought I'd start the ball rolling!

Thanks guys for a brilliant piece of software!

Sounds like a big mess. Though if your subnet masks everywhere, including the phase 2 bits of the IPsec config, are /8 (255.0.0.0) it should work.

@sn00p:

P.S a real nice addition to the logs would be to see what rule caused a packet to be blocked, i.e if it was a default block by virtue of no pass rules or whether it was a specific rule that blocked it.

It already does. Click the action icon (red/yellow X, green arrow).

yes, fixed

much appreciated!  Guess i just need to wait for the renew request to find out, as I cleared the log looking for it yesterday.

Played some more and as long as the cable is connected, it will look for a dhcp.  I think it was my testing that was at fault.  Now if I just knew when it would renew….  I just need some patience. I thought it would be in a config file or a status page (should be).

DNS rebinding is a technique used to fool a router into thinking the client is on the LAN side and can access the web interface (This would allow an attacker to own your system if you were foolish enough to have a default password still set)

IIRC PFSense 1.x.x was vulnerable to this type of attack as was monowall and most home routers. There is a check in 2 to alert you and it can be triggered by your own servers doing domain forwarding if you've not excluded them.

@kmitche:

I was able to get the PPTP connection working without modifying any code. Using the latest build (7/22/11), I set the WAN to PPTP, created an OPT1 interface (set to DCHP and based on the WAN interface) and rebooted.
…

Pls, step by step

Wow, well if the Sonicwall is that buggy…you sure it's not getting sent in a more proper way in the new ipsec-tools but it's ignoring it? May want to crank up the debug logging (2.0 has a checkbox for that under System>Advanced, Misc) and see what that shows. That's absurd they don't offer a standards-compliant solution as a no cost upgrade especially given they were shipping effectively a broken IPsec implementation for years. Paying that kind of money you ought to get something that works.

This may be a configuration issue with the Internet Authentication Service on my Windows 2003 Server. If anyone out there has this working with pfsense 2 rc3 and Win Server2003 IAS please let me know, a screenshot of your settings would be very helpful.

Thanks you!!

Still not working, testet with RC3-nanobsd …

WAN interface is configured for DHCP

Any chance getting it fixed for the final release?

Yes, upgrade to the latest snapshot fixed my problem.
Thanks.

If you would show how you have conigured the shaper and your router than some help can be given.

Yep, the 7/24/2011 snapshot fixed this problem – thanks!
Mike

I am having same problem on two systems also; following for lightsquid -

Downloading http://files.pfsense.org/packages/8/All/png-1.4.5_1.tbz …  could not download from there or http://ftp2.FreeBSD.org/pub/FreeBSD/ports/i386/packages-8.1-release/All/png-1.4.5_1.tbz.
of lightsquid-1.8_2 failed!

Latest RC3 updates built on Sun Jul 24 01:58:22 EDT 2011

Update - Okay, could be possibility that it's not with snapshot; did downgrade to 2.0-RC3  (i386)
built on Fri Jul 22 14:52:05 EDT 2011 - I believe this is when it was last working for me, and tried reinstalling package lightsquid and still getting problem with installation failing.

Thank you for the previous fix.

I have a new problem now with OLSR and it overriding routes on my router.  I'm running 2.0 RC 1 and 2 (going to update the router to RC3 shortly.)

I have a router with 3 interfaces with OLSR enabled, each is connected to a separate Wireless network (2.4Ghz, 900Mhz, and a 5.8Ghz)  via ethernet.

Interface 1:  101.94.43.254/24  connected via ethernet cable to a Robin Mesh radio at 101.94.43.1 which is on a mesh of approx 20 nodes.
Interface 2:  10.1.0.4/24 connected to a UBNT 900Mhz bridge at 10.1.0.3 using WDS as a backbone, connected to other radios and pfsense firewalls.
Interface 3:  10.2.0.4/24 connected to a UBNT 5.8Ghz Bridge at 10.2.0.3 being used for a point to point link to the other side of the mesh to add some speed and capacity with another pfsense firewall at 10.2.0.1

what i'm finding is that the olsrd routes seem to be over riding even the most lowest metric routes, i.e. a route to 101.94.43.1 which is directly connected to the router on interface 1, is being listed in the routing table to use 10.2.0.1 as the gateway…

Is there a way to add a default cost to all OLSR routes? or will the olsrd interface Weight parameter be able to help with this?

Solved thanks.