I seen. Found the thread. So the only way is to build the ralink driver my self.

/Fredrik

I can confirm it

Ok i will send you an e-mail .

Best Regards,

Daniel

Hmm, I still haven't seen anything like this happen elsewhere. Not much useful in that log, it seems to think it's still running but isn't.

If this were nanobsd/embedded, I'd suspect a full image was uploaded instead of an upgrade image.

Don't change the platform, that is not supported.

Embedded platform only has serial output, so the changes are likely assumed to be present.

The only differences in the config there should be some CDATA protection on description fields for various parts of the config. That shouldn't affect NAT.

There are already some other threads for multi-wan NAT issues on current snapshots, check into them and see if your problem is similar.

I can say that this is (for me) a well known "feature" of dell-boxes, specially the optiplex. PCI-performance is really poor on this boxes, so maybe make a test with the same card on other hardware. It will work right.
My old optiplex is having the same probs. Installing the pci-intel-adapter into my dell-server results in a much higher overall speed. (Problem here is the much higher noise and more heat it produces, so i don't use it any more…)

At some point one or more of the professionals will blurt out something like "It feels like a RC" in the IRC channel which is the catalyst.

As long as none of the developers express that we're not ready for a RC. It may seem a bit awkward but it has proven to be mostly correct looking at the previous releases.

This is not to say that we don't take this seriously, we just steer the process on our feeling. I guess we've been burned too much by silly or just plain stupid software issues across the board. That's not something we want to force on other administrators.

if you install both on the pfSense box should be localhost 127.0.0.1

Thank you for your reply. I went through the NAT, IPsec and 2.0 forums but couldn't find any thread with a solution…

I don't think it should work automatically, because I'm trying to tunnel through the VPN traffic that wasn't supposed to be tunneled, from ips that are not on the vpn phase2 setup, thats why I need to NAT the traffic.

For instance, my LAN subnet is 192.168.5.0/24, but only the 192.168.5.10 is allowed to use the VPN (and I can't change the remote config to add other hosts), but I would like to access the tunnel from other IPs as well, so I'm trying to move that IP (192.168.5.10) to the pfsense box and NAT the traffic from my LAN through it.

So far I couldn't do it, I think I'll have to use the 192.168.5.10 box as a gateway to the tunnel, but I wish I could avoid having to add static routes everywhere for it to work, plus it creates a new point of failure.

Can you still reproduce this?

I just tried to kill several in a row and it worked every time.

checkbox is working?
ok than, it have to be something local at my pfs box.
thanks for all help

you can lock

1 should be fixed now, 3 is a limitation of relayd I believe.

2 probably just needs more input validation.

I'm not sure about 4. I thought someone had already fixed that tab to point to relayd.log

5 probably just needs updated with new code from the other page. Lots of changes happened there. Not sure how much work might be involved in that.

@biatche:

and i gotta say, i hope 2.0 shaping is better than 1.2.3 cuz when shaping on, ive had some nasty 2k latency at times which should never happen.

Wrong, it should. Low priority traffic like ICMP gets delayed, at times by a lot if your connection is heavily loaded. The wizards aren't much different from 1.2.x, and there is a lot of info on the 2.0 board here if you search.

Still looks rather erratic, as though there are connectivity issues between all of the sites that make the tunnels go up and down.

Does this still happen on recent snapshots?