@simontkk: Hi,, I have a doubt regarding the pfsense 2.0.3 pre-release version that built by following the instruction. May I know is it normal if the Packages link that under 'System' does not included on the pre-release version ? OR maybe is my compilation error ? Packages link only appears on installed systems, not the live CD (which can't be modified to install things like packages).

well, you have 2 nics, setup one as a WAN and the second as a LAN. The wan address can get 192.168.200.0/24 network from the tplink. then you setup LAN with something like 172.16.1.1/24 with dhcp running. no real need for VLAN. Pfsense might be able to handle the modem.

@crisnil: Id like to ask how do you relay dhcp on other vlans? my dhcp server (windows server) in on vlan2, some clients autoobtain ip automaticaly are on vlan3, vlan4, vlan5.? Services>DHCP Relay. Enable as needed.

Well, here's the end of the story: The actual problem turned out not to be a stream truncation at all.  A different Wireshark filter showed it had to do with IP fragmentation.  The UDP packet was being fragmented and somehow the IP headers were altered and the checksums were incorrect by the time the packets hit the LAN.  A packet capture at the LAN nic didn't show any errors, but one at the corresponding switch port did, which was very difficult to figure out.  I resolved it by upgrading both the switch firmware and then pfSense (to 2.0.2).  It was after the pfSense upgrade that the packets in question finally got to the destination server application.  I'm relieved.

Thanks jump. I may well go for a pfSense box on an esxi server. I need an SMB server to share files and I could run pfSense on the same hardware (already do that at the other end anyway). Will update the thread when I have it working.

I took a break from this, but I still have not got this going.  If anyone has any suggestions on the issue, please let me know.  I suppose it's time to keep trying different things.  :-\

@LinuxTracker: Interestingly, my IP is one that shows open. nmap seems to indicate that I (and other IPs in my /24) have 1900/2864 UDP open w/ no services. Just a misunderstanding of port scanning UDP. With UDP, either you get an ICMP unreachable, so the port is closed, or you get no response at all, which either means the port is open or it's filtered by a firewall. That's what "open|filtered" means in nmap. Not very helpful, but there is no difference in response between an open UDP port and one that a firewall is silently blocking. Tools that actually send a UPnP request and will check for responses will be able to determine whether it's open or filtered. A UDP port scan can't differentiate between those.

Don't know the exactly solution - please search the forum you will find some solutions for that. As far as I know there were problems with different perl versions und wrong symlinks and so on. Another solution could be to just run the lightparser.pl and see if it works or not. Doing a "full refresh" on the GUI and click "CTRL+F5" to reload the browser windows/logs without the browser cache

Right now it's only an opt-in trial so I'm not too worried. Plusnet are by far the best ISP I've ever dealt with, their customer service is quite frankly astounding. So I'd be very surprised if they started forcing CG-NAT on their users. http://community.plus.net/forum/index.php/topic,110652.0.html Steve

Sorry for the late followup on this. Finally resolved the issue. The DNS was open to public, closed that and after a week it all went back to normal. Thanks everyone for the input and help. Learning as I go. ~ Tom

Your picture looks nice but the link is to a thumbnail so it's hard to appreciate it fully.  ;) 1: Is there any particular reason you are using the wifi APs for DHCP? In my opinion it would be much better to use pfSense for DHCP on each interface. Doing that makes it much easier to keep track of the leases or to hand out static addresses for filtering purposes. All your admin can be done in the one place rather than having to log in to each AP to change things. 2: Normally you would not bridge them. pfSense will route traffic between them if you have firewall rules in place to allow that so that you can access, say, the AP in zone 2 from a computer in zone 1. The only reason you would bridge the interfaces would be in you had software that needed to see machines in the same subnet. Many media player programs will only look for servers in the same subnet for example. By default all traffic from the additional interfaces will be blocked so you will need to add firewall rules to allow traffic that you want. Only the LAN interface has a default allow rule. 3: You can add a rule to allow traffic from Zone 2 to the printer but no other address. Better, you can restrict that rule to allow access only from specific clients in zone 2 if you have all static dhcp leases. 4: Squid with Squidguard is a lot more mature (in pfSense at least) but Dansguardian has more/better filtering options. 5: You could use VLANs to get more interfaces in pfSense without having to add further NICs however I don't believe you will need to. Do your switches support VLANs? Do your APs? Steve

We fixed m0n0wall's CSRF issues over 2 years ago with csrfmagic, same thing they implemented recently. 2.0.2 fixed a couple that were found more recently.

At (very long) last: http://www.freebsd.org/releases/9.1R/announce.html http://www.freebsd.org/releases/9.1R/relnotes-detailed.html

Thanks :-) Happy/Merry/Joyous $winter_solstice_holiday

You are currently running Double NAT, which is a very undesireable setup. See if you can get your modem/router to be in bridge mode so the real wan address goes to the pfsense box.