Depending on the cable modem it may be running some filtering on the ports and switching. Can you login to the cable modem to do any diagnostics?

Thanks; it looks like that may have done it.  I'm not sure why a protocol based rule worked, where an IP based one didn't.  Their site must hit some other address at some point and they don't want to admit it.

HI Guys,

I set it up as above and it still wasn't working. Then I figured out that I setup my Hyper V Virtual PC's VLAN's/virtual network adapters (is there a difference?) incorrectly .

All is working now. Now for the fine tuning.

Thanks a million for your help.  ;D

I'm not at all too familiar with the Cisco IP phones, I am more of a HP Procurve kind of guy so the terminology is a bit different.

Unless you segment your switches with VLANs everything can see everything, i.e if you want your VLAN1 (10.0.1.0 network) to talk to only ports 1-24 those ports have to be untagged (this is a procurve term, not sure about the cisco term) to reach the VLAN, when the VLANs are combined on a single link (i.e. to your single NIC on the pfsense box) you have to make a tagged uplink set (each of the VLANs going to a specified port has to be tagged).
When you distribute vlans from one switch to another the link between the switches have to be tagged for the switches to understand and send the packets right.

When it comes to the IP phones, are the computers connected behind the IP phones ? or do the computer have a seperate link to the switch ?
If the computers are located behind the phones the phone will have to be able to understand that the uplink is tagged and that there are multiple VLANs coming in on that link, I do not know if they do.

Hope this clears some things up, even though it's procurve speak instead of cisco speak.

PS. I think the name for a tagged uplink set is called a Trunk on cisco.

It depends on how you plan to use these IPs. If you want to use them for port forwards, 1:1, or outbound NAT, all you would need is to set them up as "Other" type Virtual IPs and then you can use them.

If you want to use these new IPs directly on your LAN, assign one of those IPs as the LAN IP of pfSense, disable NAT (Switch to manual outbound NAT and delete the rules) and then you can either setup DHCP or assign the remaining IPs to LAN clients, using pfSense's IP as the gateway.

You could also do a traditional LAN subnet with NAT, and use these IPs in that way on a DMZ if you like.

@GruensFroeschli:

http://google.com

( http://doc.pfsense.org/index.php/Multi-WAN_Version_1.2.x )

tanks

Solved

Hello All,

Wanted to do  a follow up post on what resolved what I thought was a load balancing problem I was having with pfSense.
I decided to start tracing back to the IPS's router( That the pfSense machine is plugged into). Low and behold there was a problem with the ISP's dsl line coming into the building. The ISP tech had to monkey for quite a while with the NOC office and finally got the problem resolved.
The rrd graphs for the WAN now looks like it should.

Thanks,
Barry

It appears the reason is because I have STICKY CONNECTIONS ENABLED

DO NOT ENABLE STICKY CONNECTIONS FOR MULTIWAN
I thought the "do not use" restriction has been lifted lol.

Thanks for your reply, Perry.

Just a question: What Sticky Connections does? Why I shouldn't use it?

It turned out I had a problem with the WAN my machine should use: I was able to exit the DMZ using another WAN with the NAT working fine, so I investigated and found that the router was blocking even the pfsense machine  >:(
A colleague of mine had changed the NAT of the router from none to MUA…..changing it back to none makes the pfsense and DMZ working fine!  ;D

yes, I know that jimp. thanks for that.

I will use squid on pfsense box which lies between 2nd ISP and LB server.

The LB server will only do the load balancing job.

thank for your reply, jimp. :)