Thanks, i'll do it that way

Nevermind – found out that it was actually a problem using a virtualized client machine.  A physical device worked OK.

yepp on the trafic shaping section its told many times that imcp (ping) is set to a low priorty when you shape you can chanche that if you like butt ping is only for testing its not just for real world trafic so that is the resen for the low priorty

Incidentally, at this point, if you're running 1.0.1, you really should be on at least 1.2-Beta-2, especially if you're having problems.

We are still having issues with this.  We reinstalled pfsense but the problem continues.  Basically VPN over UDP is erratic.  It works some of the time but other times does not.  It will work fine for a few days then it will stop working for a day.  One client machine may be working while another isn't.  It seems random. Is anyone else having a similar problem?  We have not yet upgraded to 1.2-Beta2 (still running beta1), but we might try to see if it fixes any of our issues. James

Hi, I htink it will work the same way as BFD for APF, something like it. Matts

Hi well both are exist, in the NAT there is : WAN….TCP/UDP.... 113 (IDENT)....10.0.0.1 ext any....113 (IDENT) and in firewall rules there is: TCP/UDP.............10.0.0.1....113(IDENT)....*...

OK, that's what I needed.  Thanks. -Robert

No, but it should make 1.3.

It's pf, not ipfw. You have to make your rule changes via the webGUI, otherwise they'll be overwritten. If your existing ruleset does not allow you into the webGUI, you can make temporary rule changes at the command line. Your running ruleset is /tmp/rules.debug. Info on changing it can be found here: http://www.openbsd.org/faq/pf/ Don't do anything other than add a rule to permit access to the webGUI, then go into the webGUI and setup the same rule there, as well as whatever else you want. Editing the ruleset manually is unsupported and may cause problems, I strongly suggest having someone on the LAN side let you into the webGUI rather than doing this. You could use tunneling with SSH to get into the webGUI, that's probably a better and easier solution.

After a lot more testing I come to the conclusion that simply my old observations must have been wrong (maybe I shoudn't do setups at late night) ;) . Summarizing this meas: the confusion started with the fact that the bridged LAN IP can be accessed from the outside network (ping and webinterface and ssh). All other observation where just due to other effects, e.g. the pptp stuff still works. Hence, what remains from here is just, that it's probably a bug that the internal ip can be accessed from outside in bridge mode. Furthermore, this cannot be deactivated by deactivating the anti-lockout rule. This is discussed here: http://forum.pfsense.org/index.php/topic,5441.msg32479.html#msg32479 . Sorry for the long post and the confusion.

Look in firewall rules -> LAN, edit the default firewall rule and click the advanced button.

@dcbour: Wan - Cogeco - blocks SMTP except to their own server. Hopefully you mean from their Server. On WAN you can only block/reject packets that enter on this interface… Chris

@Kim: Thanks for that. So in the NAT window, I would just do the following: (where 10.7.31.20 is our Exchange/Web Server) - see attachment? - Then the same for HTTP and HTTPS? Yes. Once you have the first one done, you can use the handy + create a new rule based on the first one, and just change the ports. @Kim: Do I also need to create a Firewall rule to Block * from the WAN? (and order the rules so this is the last rule?) - or does pfSense block everything else by default? Defaults to blocked. @Kim: What are the VIPs? You would define Virtual Ips if you had additional static IP addresses assigned to you by your provider.

@Cry: @tulsaconnect: We plan to use Dell hardware, and unfortunately the newer Dell's are using Broadcom NICs, which aren't as well supported under FreeBSD as Intel NICs.  I wonder how the onboard NICs are connected internally – e.g. at something better than PCI-X or PCIe bus speeds... ? From discussions with somebody I know you'll find you get better throughput with add-in Intel GBit cards even on boxes with onboard Intel GBit.  He wasn't sure why, but even when the add-in cards had the same chips as the onboard cards he still saw better performance (beyond 100 Mbs, don't remember the exact values) with the add-in cards. From what I was told from an Intel engineer was that, the OnBoard NIC's use shared resources relying heavily on the CPU whereas an Add In NIC, usually has it's own timer chips, etc.