Hopefully fast - but You should use search function before posting:

http://forum.pfsense.org/index.php/topic,33587.0.html

Well thanks again for all of your replies…

Anyways I figured it out. I don't know how but one of my gateways was in the XML file twice... While one of them was configured with the weight I wanted. The other one (apparently the one being used by pfsense) was stuck with a weight of 1. It was missing the opening <weight>and just had</weight> so I'm guessing it defaulted to 1 even though it didn't have a value there.

So anyways not that anyone was looking into this but figured I'd edit it as resolved in case someone else has the same glitch.

If I follow correctly, I need to remove both rules regarding my sipserver from the "Floating Rules" and add them to WAN and LAN rules and queue them.

This is how it was setup prior to update to RC1 and stooped working since then. I'm using snapshot "built on Mon Apr 18 10:01:33 EDT 2011".

I'll try again your suggestion and come back with results. What's odd is that calls using IAX does not have this problem. IAX rules are the same as my SIP rules, in fact the IAX port is in the same alias ports and the SIP/RTP one.

MageMinds

:Edit1 Begin:
Nope, not working either… I now have two rules, one in the WAN saying "any to SIPServer:SIPPorts" -> qVoIP and one in the LAN saying "SIPServer:SIPports to any" -> qVoIP. I rebooted the router to make sure it takes the new config and still getting the same result, "qDefault on WAN" / "qVoIP on LAN"

I just found what you're talking about with the "tagging" I'll try that now... That would be the first time I'm using that.
:Edit1 End:

:Edit2 Begin:
OMG, It's working! For the record here is what I've done to make this work.

Tree rules are necessary to make this work.
1 in the WAN
1 in the LAN
1 in the Floating Rules

The WAN rules is basically controlled by the NAT rule and I selected the queue "qVoIP", in the advance section I set the tag to "fVoIP"

The LAN rule is the same as the WAN except instead of destination you setup the sip server and ports as source to any, choosing the queue "qVoIP" and set the tag to "fVoIP" also.

The Floating Rule is simple, you select the packet based on the flag "fVoIP" and then set the queue to qVoIP.

TaDah!

Note: The queue selection is mandatory only in the LAN queue, the WAN queue does not need to select the queue, the floating rule does that. I've setup every rule to select the queue to make sure it gets the job done…

Here some pictures... I know you guys love pictures :-)

**Here is the WAN rule (note where the flag is entered in the advanced section)

Here is the LAN rule (note where the flag is entered in the advanced section)

Finally the Floating rule (note the advanced section, the flag goes in an other editbox)
**
:Edit2 End:

Great!

Now I know, this is not responsible for the lag of response while surfing the web which several users reported to me. I will try an actual snapshot and create a new thread if I cannot resolve the problem on my own.

Thanks!

Please give me a few details on how you compiled usb_modeswitch and transferred it to pfSense.
What version of FreeBSD did you use?
I read that one has to have libusb installed…is it installed in pfSense 2.0 RC1?

Alternatively is there not an equilvalent to usb_modeswitch built into pfSense 2.0 RC1?
I tested another similar USB 3G modem (from a friend) on pfSense 2.0 RC1 and it just worked?
Now the actual one I purchased and want to use, ZTE MF 668, requires modeswitch - I know this as I tested it on Ubuntu and all I had to do is a modeswitch and it was recognized as a modem.

I can confirm this issue, it also affects the ISP that I am using. Disconnects every 8 minutes :(

hmm…
I would rather prefer certificates...  ???

I too have an internal router and to stop the ping I use RIP to distribute the routing information so no need for a internal gateway.

Just a thought!.

It's something specific to USB sticks that doesn't happen on CF drives.

I'm not sure anyone with the know-how of filesystems at that level has taken a look at it. No matter what size we make the images, the upgrades always fail. We can't just expand the check because that could break CF installs if something went wrong, and a lot more people use NanoBSD on CF than USB.

No os in this planet can protect from that by design.
There are tools that can be installed on pfSense for this as well.

I think one of them is a package.

Your firewall rules on VLAN2 are correct ? If VLAN1 works, try to use the same rules on VLAN2.
Check out, if the DHCP for VLAN2 offers the correct DNS and Gateway.
Try to ping the VLAN2 IP address and see if this works.

My statement is true for LAN rules doing queue-ing as well.
For floating rules no they should just work for ipsec as long as the latest matching firewall rule, the one that actually lets traffic pass through, is on the ipsec tab.

The "msk0 no phy found" is your issue, the msk driver has never changed as long as we've been on FreeBSD 8.1 (~1 year) so that's not resolving your issue. Apparently something with your NICs, or in combination with that driver is occasionally flaky.

This is getting confusing replying in two posts!  ::)

If you only need console access you can do a full install on a PC and then go into the web gui and select 'serial console'.

Steve

yep the issue was DF fixed it
thank you

And as I said, the lifetime is settable when you make the CRL in the GUI. If that isn't working there is another problem elsewhere. It works with OpenVPN so I'm not sure what racoon is complaining about. Feel free to research it more.

That is probably a side effect of your first action after the timeout being a POST, and tripping the CSRF protection. There may not be a good way around that one, though I'm not sure why it makes you login twice.

That's great. Thanks guys!