We have a very difficult topology.

We have 3 routers in different places where each have a VPN to our customers.

Our customers have more or less branch offices, home offices, external service partners and local partner networks.
Not every router knows the whole topology and will route unknown subnets in direction of the hub router.
Its like routing in a tree. If we have to optimize it we will make short paths.

In this situation there should be something like a big transfer network and every router should use ospf.
If a roadwarrior is added he will get a IP from this transfer network and get all routing information automatically.
At least this must be possible with multi wan at different bandwith, qos, load balancing and fall back.

Not encouraging to see this is still around in 2.1  ::)

Yep, I am posting this from a laptop connected on the WiFi to an ALIX 2D13 with 5004 MP ATHEROS 4G (Wistron CM9) kit in it.
The ALIX is running:
2.1-BETA1 (i386)
built on Tue Jan 22 05:52:55 EST 2013
I also have one running 2.0.2

The whole config was buggy.
IPSec didn't work too. So I set it to factory default and made all settings again.

The whole config was buggy.
IPSec didn't work too. So I set it to factory default and made all settings again.

This thread is for 2.1, not 2.0.x.

That is a known issue in 2.0.x that is fixed in 2.1, and there already a few threads about it.

That implies that something at the very start of the CF was corrupted somehow. I don't recall seeing that happen before even if a previous upgrade failed in odd ways.

There probably isn't a way around that exact error without re-imaging, but I would also start being suspicious of the CF as a whole. Get a good backup, grab a spare card, write that out and you'd be a lot better off.

It's possible that you could write the image to the same card again and be fine, but given that CF cards are rather inexpensive it may not be worth trying to save if there is a chance the card is starting to fail.

Ha! Well that explains how I missed it.
Have their behaviour been changed more recently? When I first went to a dual WAN setup, under 1.2.3, I started experimenting with load-balancing and policy routing. I had to add my own rules to allow access to local subnets using the default gateway otherwise nothing was accessible. Perhaps I am misunderstanding the purpose of the negate rules but I thought that's exactly what they did.  :-\ Something seems to have changed between now and then since I no longer need those rules (with negate rules not disabled).

It's the change of behaviour that worries me. Of course it could be that was previously mistaken about how things were working.  ::)

Either way I'm glad to have the check box to disable negate rules. Personally I much prefer to have everything visible, or as much as possible at least.

Steve

Same problem, just in PF rather than ipfw.
https://redmine.pfsense.org/issues/2762

I double checked and the settings are set correctly.

I tried to do my due diligence and poured through similar issues in the forums trying other suggested fixes, but I haven't been able to lick it yet.

With latest snapshots those entries will be cleaned up.

and now the latest nanoBSD VGA update images are appearing nicely in http://snapshots.pfsense.org/FreeBSD_RELENG_8_3/i386/pfSense_HEAD/.updaters/. All is well with the snapshot updating world.

Jan 16 19:07:16 openvpn[36432]: UDPv4 link remote: [undef]
Jan 16 19:07:16 openvpn[36432]: UDPv4 link local (bound): [AF_INET]eee.fff.ggg.hhh:xxxx

Link Remote and Link Local look fine, showing my Home IP and OVPN UDP Port on the bottom line for this Road Warrior Setup.

I only have one other OVPN instance which is Client for a Site to Site VPN but that above error in my first post is specific to my Road Warrior Server Tunnel.
Both Site to Site and the Road Warrior VPNs are using WAN as interface.

Nothing in my firewall logs.  Using another remote site now and I cant reproduce the error.  I'm wondering if this error was strictly due to the remote wireless network I connect to when I'm at work.

Replacing the NIC fixed the problem. Thanks for the help.

You have renamed your OPT1 interface to WLAN which to me implies it is perhaps access via a WiFi access point.

Are you sure you are comparing like with like?

Can you confirm that your speed testing through the "WLAN" interface is via an ethernet switched connection with no WiFi involved?

Cheers
Jon

Yes I have two physical interfaces on the host, both with a bridge setup, so the pfSense VM is attached to these two bridges.

Well, the KVM host looks configured good, in  fact 2.0.2 works. Looks like something related to the newest version.
I even tried configuring the interfaces using intel/rtl drivers (in kvm setup), so not using virtio, but I still have the problem.

Thank you very much, this indeed works very well.

Thanks, latest snapshot works fine.

This thread is referencing 2.1 not 2.0.2, 2.0.2 had no changes related to this. This is how things are supposed to work without the negation work around we put in place to prevent you from foot shooting. 2.1 has changed some in this regard and that needs to be re-evaluated.