Thanks much wallabybob for helping clear that up some. Ed

@jimp: How about now? Looks good! Verified in preview and post. Thanks.

So good news/bad news. Good news is i no have internet pushing from LAN into my switch and i can connect devices to the switch for internet access now. Bad news is i dont know what i configured previously to not be able to do this before. At the pfsense console i choose the factory defaults option to start from scratch and i only enabled dhcp on LAN, plugged into switch and i was up and running. So i really dont know what i did to mess things up in the first place. Live and learn i guess. Thanks to posters for trying to help.

Thats what I was trying to find out stephen So long as I have some information to go by, that will allow me to be able to work on the rest of it I just have to remember to backup the config now, as I have the squid proxy server finally working as it should be (man you wouldnt believe what relief it is to finally see it working as it should). I've transferred the Wireless NIC from the Sun Workstation to my Proliant ML350 G5 (which is going to be built as the Fileserver/Backup Server) But do you think finding 15k RPM SAS drives is cheap? lol as well as DDR3 ECC Ram, lol  ;D I've configured the pfsense box as best I can for now, so I have to finish the rest of it after work tomorrow (Have to be up by 5am to be ready for work  ::) )

Ah yes.  :-[

I am not sure if I understand you correct but for pfsense it is independet if there is another router which does NAT on the interface. What you describe - or like I understand it - it is doueble NAT. This is working. You can do LoadBalancing and Failover as you like. ISP–--NAT-Router1--------NAT-pfsense-------LAN ISP2-------------------------- On the pfsense interface which connects to the other NAT-Router you will probably have to uncheck "block private networks"

No way to do so. It would be faster to manually import than write and validate something to do it in an automated fashion unless you have thousands of rules.

Nope. I think you may have misunderstood what the netmask is. The netmask is simply how the IP protocol defines the subnet that each machine is in, what other addresses it can talk to. See: http://www.computerhope.com/jargon/n/netmask.htm Steve

Thanks, I will look into that.

I wonder if my question is not clear, too complex, or really nobody knows. From my testing it seems like NATed connections (only ones I tested) do not obey any routing changes for existing connections.  I wonder if that is one of the reasons for the option below is defaulted to disabled.  To make sure any existing connections are terminated for the wan when routing changes.  WIthout doing that it would appear that packets for states that were already connected before a routing change would still be going to a dead gateway until the TCP times out. There must be a way to make sure packets are routed according to the routing table for already established connections when a route changes. Advanced->Gateway Monitoring - States By default the monitoring process will flush states for a gateway that goes down. This option overrides that behavior by not clearing states for existing connections.

Hm, ok, but this is a remote location with a satellite connection only. Is there any other way of fixing it? Thanks in advance. BR, Jarle

Doesn't actually help provide an explanation either way! The 'ethernet extentions' product is routed via their fibre network, which is presumably shared with other traffic, where as the extensions+ product is swiched ethernet. Plenty of people complaining about virgin media in general though.  ::) Steve

There is also http://doc.pfsense.org/index.php/What_is_a_bridged_interface_and_how_would_one_be_used%3F If you clicked the category at the bottom of the link you posted (for "Bridging") that shows up. I just added a "See also" link to the page so it's a little more obvious.

No.

@XIII: @k6usy: To many bots out there trying to crack simple passwords I would rather not have the traffic going to my router. Thats why you use key based SSH authentication, cuts down on the exposure drastically. That works too.

Thank you Wallybob for walking me through routing troubleshooting. It was a routing problem all along. I thought the AP was acting as a bridge, but it was actually a DHCP server and didn't know where to forward 192.168.2.0/24 traffic. FACEPALM In my defense, it's my first week on the job…  :P Lessons learned: PFSense does not randomly drop traffic. If you can't reach something because of routing, you do not always get Destination Host Unreachable when pinging. Have faith in the system logs. Thanks, Seanny