1. It's not something I've ever tried. I can't really see what advantage it would be. If the WAN is up and you have convectivity to to other end then why switch to a different tunnel? If your first tunnel goes down, for whatever reason, then why switch to a second tunnel rather than bring the first tunnel back up? If you have both tunnels up simultaneously then you could run some failover/redundancy between them. However it's likely both tunnels will be using the same route such that if one goes down both will. You may get a better answer to this in the vpn subforum.  ;)

2. Not sure quite what you're asking here. Do you mean remotely access the webgui on a pfSense box?
If so you can do that already. The server that provides the webgui listens on all interfaces you just need to add firewall rules to allow it. It isn't recommended though to have the webgui accessible from the internet.

Steve

That should definitely be enough for 1 Gbps wire speed throughput.

I remembered VirtualBox on Linux has "USB passthrough": a VM can take control of a USB device. Hence you could (if supported in VirtualBox on Windows) add a USB NIC, assign it to your pfSense VM and connect that NIC to your "rest of network" so that traffic from that part of the network has to go through the pfSense VM BEFORE it can get to "server1".

pfSense is not real good with dynamically appearing interfaces so you will probably need to reboot the pfSense VM a couple of times to ensure the USB NIC is correctly seen on pfSense startup.

There are a number of USB NICs that are supported by FreeBSD/pfSense which say they are USB 2 compatible but don't say they are not capable of 480Mbps operation (that is, they talk to the host at only 12Mbps or lower). Depending on the speed of your WAN link you might need to choose the USB NIC carefully.

USB NICs don't have a great reputation in the pfSense community. I suspect at least a part of that is from people not considering all the details. I used a USB NIC for a while and eventually ditched it because it wasn't reliably seen on startup which meant I sometimes needed to be around to fix up the situation if pfSense restarted. I could probably have tweaked pfSense to get around that but I had a VLAN capable switch which I was able to use to effectively get extra ports removing the need for the USB NIC.

HI!

Did you manage to resolve this? I have the exact same problem.

This modem needs the HSO driver as explained here: http://forum.pfsense.org/index.php/topic,45229.0.html
usho.ko needs to be loaded for the interface. I doesnt work as a regular modem.

Is there  any way to get a working uhso.ko in pfsense?

Wish

So it's not receiving an IP on WAN.
Check the logs to see if it is sending a dhcp request. Check the logs in the ISP router to see if that is seeing and responding to the request.
Given that it didn't work with WAN set as static it's probably something more fundamental. It could have failed to negotiate the ethernet connection correctly. Could be a bad cable.
Does the router have link lights on it? What are they saying about the connection speed and duplex?
Please post the output of ifconfig here, that should show any problems.

Steve

There are some details missing.

@cfapress:

Changing the Elastix box to 10.2.4.227 (note the subnet change) and now the box can ping anything other than itself. I changed the subnet on the box to 10.2.4.0 and the gateway to 10.2.4.254 (which is the pfSense VLAN router IP).

You have a VLAN capable switch, pfSense connected to trunk port on the switch and the Elastix connected to a ?? port on the switch?

@cfapress:

Setting the Elastix box to any other IP in the 10.2.4.x subnet and it still cannot get outside of itself.

The "still" in the above sentence implies it previously couldn't "get out of itself" which seems to contradict the earlier statement "now the box can ping anything other than itself".

I get the impression you might be trying to achieve some sort of isolation between the two subnets without a VLAN switch. Please clarify what you are wanting to accomplish with VLANs and what VLAN capable equipment you have (or expect to have).

@Daemonseed:

That drives me nuts. I've run into issues finding the right wireless adapter for compatibility due to a card being available with 3 different chipsets, and had to figure out which revision had the chipset i needed.

yeah it sucks for anyone not running Windows… can't trust any big name vendor (Linksys, DLink, etc.) to keep their hardware consistent.

LOL  :) not even close to a genius, but glad to be of help with your problem

Now you can edit your first post and add [ Solved ] to the Subject  ;)

@/CS:

@trunix:

You may want to prefix this thread with the words "SOLVED" in the title.

I also wanted to do that but coudn't find an option in the menu to rename it,

The ability of the writer of a post to Modify the post seems to expire within a time less than a couple of days.

tnx. i changed it to amd64 and it's work really good

Are you sure it's not showing 100% idle?
The idle process uses up whatever cpu cycles are not being used by anything useful and is shown by 'top -SH' and opn the System Activity page. E.g.:

[2.0.2-RELEASE][root@pfsense.fire.box]/root(2): top -SH last pid: 58916;  load averages:  0.22,  0.08,  0.02    up 2+13:37:03  12:05:18 101 processes: 2 running, 83 sleeping, 16 waiting CPU:  0.0% user,  0.0% nice,  0.0% system,  0.0% interrupt,  100% idle Mem: 45M Active, 15M Inact, 66M Wired, 1064K Cache, 59M Buf, 359M Free Swap:  PID USERNAME PRI NICE   SIZE    RES STATE    TIME   WCPU COMMAND   10 root     171 ki31     0K     8K RUN     59.5H 98.00% idle  262 root      76   20  3408K  1224K kqread   9:36  0.00% check_reload_status   11 root     -32    -     0K   128K WAIT     8:01  0.00% {swi4: clock}   11 root     -68    -     0K   128K WAIT     4:15  0.00% {irq18: em0 ath0+}

A copy of your output will clear this up in seconds.

Steve

I never changed it.  I think its set to 1500?  Dont remember…

Thanks!!!!!    :)

Check the compatibility list at http://www.freebsd.org/releases/8.1R/hardware.html#ETHERNET

VIP settings, after saving those again everything worked

http://doc.pfsense.org/index.php/Installing_FreeBSD_Packages

@dhatz:

I wonder if it's still a problem with the newer FreeBSD 8.3 kernel used by pfsense 2.1-BETA

I have since sold the small WISP business that used the virtualized pfSense system I reported on earlier. However, my new employer (an ISP) asked me to build a vSphere cluster and help them virtualize large parts of their central office. So I will soon be able to do further testing with pfSense in this virtual environment.

Looks like packets pass across the bridge from the Physical OPT at least to the QinQ member vlan.
I have to wireshark on the WAN (QinQ) link to see if packets actually make it onto the wire.

Maybe it's some weird ARP issue?

I will have to recheck that the alix boxes I used had the bridging fix applied. I'm actually not sure cuz they were used in a previous lab setup!