Yeah.  I use the initial LAN port as my management interface so the anti-lockout functions make sense. I've been looking at this more since posting and have decided it is better to simply create a port alias with 80, 8443, and 22 and enter a reject rule that prevents each subnet from accessing those ports on their own interface.  I already have to have rules that reject traffic, for example, from OPT1 to Management and OPT2 anyway. Way better than modifying 2.0.3, though the ability to bind admin services (webConfig/ssh) to a specific interface would be a welcome enhancement.

OK… Thanks to everyone.. it was my cable . Now it works ;D

It sounds like the WAN and LAN are connected together on one single layer-2 network. And that you have WAN and LAN subnets the same - 10.0.0.0/24. The LAN client is probably getting DHCP from the ADSL gateway, rather than pfSense. Make your LAN subnet different from the WAN subnet. If you have 2 NICs in your pfSense hardware, then connect the ADSL gateway directly to 1 NIC and use that as WAN, completely separate from the VLAN stuff; otherwise you have to configure the VLAN switch, and use a VLAN for WAN devices and separate VLAN for LAN devices, with pfSense trunk port between them. That way a DHCP request from pfSense WAN is only seen by the ADSL gateway, and a DHCP request from a LAN device is only seen by the pfSense virtual LAN interface.

I am confused by the description of your network configuration. Please provide 1 a network diagram including IP addresses and network masks of interaces, identifying particular hosts on that diagram that can't communicate; 2 output of pfSense shell commands``` /etc/rc.banner ; ifconfig

@jimp: How did you "recreate" log logs? They are supposed to have lots of null characters, they are binary circular log files, the are not plain text logs. They are read with the clog command, such as "clog /var/log/system.log" Usually that clog crash means that the logs were not created with a clog format. Use the "clear log" button on a log tab to clean and re-create the log file properly. Click Save on the Log Settings tab to restart the syslog process which usually will get logs going again. Thanks very much. I'd actually worked this out at stupid o clock this morning - i.e. that i was being an idiot and assuming the logs were plain text, not binary. On the upside, I now know about clog and a lot more about pfsense, so 10 hours of banging my head against a brick wall wasn't entirely wasted! Thanks again - the key point to other users if they are stupid like me, is to not manually kill and recreate the log file to clear it! Use the pfsense gui and manually check it's logging using 'clog [filename]' rather than vi.

When reading both the graphs and the bandwidth-by-IP table, always think of In/Out with respect to the interface or IP address reported. Then the In/Out makes sense. e.g. when doing a big download: WAN graph - In is high WAN IP bandwidth table entry, In is high. LAN graph - Out is high (traffic is going Out of LAN interface to the device receiving the download) IP entry for device on LAN -In is high - the device receiving the download is getting a lot of traffic in. (No comment on the OP about speed figures - I don't have a 2.0.3 system any more to do a real test)

@Fmslick: still getting connect timed out!?! You have discussed two different configurations in this topic. Which configuration has the problem?

The HAProxy-devel package can work ok with multiple certificates for different (sub-)domains. Just create multiple "shared" frontends and assign certificates to each.

I have the exact same symptoms. I would really appreciate help/comments on the issue. It's frustrating to be booting igmpproxy all the time…

That's helpful, thank you.

Whether or not something should be found on the Internet doesn't necessarily matter. Bogon or assigned but unrouted IP space is hijacked and announced by those with nefarious intent all the time. Alternatively it could be something your ISP is assigning internally and NATing, could be that there were routes for 25./8 in the Internet routing table at some point in time (there isn't right now, at least not on our full BGP feed). It also could be any number of other things depending on specifics.

You're on the right track, seperate subnets for both LANs and the Metro-E section So you would have site1: pfSense LAN: 10.0.0.1/24 pfSense WAN (Metro-E): 10.20.0.1/24 site1: pfSense LAN: 10.10.0.1/24 pfSense WAN (Metro-E): 10.20.0.2/24 and then follow: http://doc.pfsense.org/index.php/OpenVPN_Site-to-Site_%28Shared_Key,_2.0%29