Ok, I assume it's nothing to worry about

Hi onhel

Thank you very much, I just did not see that. Problem
is solved.

cheers hafnix

In general, you would do something like-

Go to Firewall, Virtual IPs. Add the outside IPs. Setup outside to inside maps via Firewall, NAT, 1:1 Go to Firewall, Rules, WAN, and create rules to allow the traffic.
eg- TCP * * 1.0.0.124 80 * *
etc…

Although you could just use port-forwards instead of 1:1 NAT.

Okay.. something has happened and it does appear to be an automagic type thing.  Don't know how but it is now working!  W00t!.. I think LOL!

Anyhow, thanks for all the help guys!  It is mucho appreciated!

@excel905:

Would it be possible to use the router as a "hub" for more connections since my PC only has 2 network adapters (One for the WAN the other for LAN),

Yes

and would it be possible to use the wireless interface from the router for wireless connections aswell.

Yes, provided the router supports that. (Perhaps the router's wireless support is only for a point to point link, perhaps the wireless support is not for WiFi etc etc)

Hope i provided enough information.

Enough to say that "in principle" it can be done.

Shawn…. It is moving towards small boxes and not old powerguzzling hardware.....;)

Either small boxes or 1U appliances build into new home networks. Many people today have NAS and other things stashed in their basement, and surprisingly enough, many have small racks(at least here in Sweden/Scandinavia). Just for your info....

Sounds like its a HTTP or TCP specific problem particular to the path through the wireless AP.

You mentioned VLANs - they require some additional header bytes reducing the space available for data. Maybe you are losing a packet in the HTTP response because its too long. It might help to do a tcpdump on a few nterface to verify that large packets are getting to your client or to the wireless AP.  On this, the last time I looked, it wasn't clear from the documentation whether or not tcpdump showed packets that were discarded by the NIC driver. That is, a packet that is discarded by the NIC driver might still appear in the trace on the sending side even though it doesn't make it to the wire.

This one seems to be the biggest reported one so far:
http://forum.pfsense.org/index.php/topic,7668.msg43776.html#msg43776

Not a problem, I can drive there tomorrow. Better to test on this one than units I have in other cities.

An update to 1.2.3 or just updating your bogons list should do it. You should be running 1.2.3 anyhow.

I don't recall if this is on 1.2.2, but on 1.2.3 you can do this:

/etc/rc.update_bogons.sh now

And that should refresh the bogons list.

@bobbob2:

And what we'd like to achieve is:

Both LANs have Internet Access.

In pfSense you three interfaces will initially be called LAN, WAN and OPT1. LAN will default to allow internet access. You can add firewall rules for OPTx interfaces to allow internet access.

Neither LAN can see each other.

Add firewall rule to the LAN interfaces to block access from OPT1, add firewall rules to OPT1 interface to block access from LAN.

Custom NAT / Firewall rules per LAN
      - LAN1 is to be highly secure, filtered web access, minimal open ports etc
      - LAN2 is to less secure although still protected by the usual Firewall gumph.

Custom firewall rules per interface is definitely possible. Not sure what you mean by "custom NAT".

LAN1 & LAN2 need different outbound public IP's (e.g. LAN1 has x.x.x.146 and LAN2 and x.x.x.147)

I don't know if this is possible.

Have you read through some of the tutorials linked to be http://doc.pfsense.org/index.php/Tutorials or any of the documentation linked to by http://doc.pfsense.org/index.php/Main_Page?

You probably have a hardware problem, possibly faulty memory.

Now that helped :)

Unless you are very lucky and have an ISP that can bond circuits for you.  Very pricy :(