What traffic goes over the VPN and what goes over the normal WAN is defined by the firewall rules. So if the criteria can be defined by firewall selection fields (IP address, protocol, ports and more) then it will work. Certainly what you describe is easy.

And what rules did you create on lan2?  Out of the box lan that is created has an any any rule that allows outbound traffic, when you create another interface opt1, 2, 3 etc.. there are no firewall rules and you would have to create them if you want any traffic to work. So seems this e4200 could just be removed as it seem to serve no purpose other than your pppoe connection, which can be done on pfsense.  Why would you not want to remove that?  Its just something that could fail..  And complicates the setup with a double nat, performance hit if nothing else.

Yeah I was thinking that a workaround would be to schedule the graphing backend to disable and re-enable every 2 days to get around this.

This thread is an interesting read: https://forum.pfsense.org/index.php?topic=78062.0 I don't agree with all of it, or at least that's not quite how i'd do it. The huge variation in user experience, network size, hardware etc amongst pfSense installs makes writing such a document very difficult. It would likely be both unreadably complex or patronizingly simply depending on the reader.  ;) Steve

oh my…. Just solved the problem. I create 2 rules in windows firewall that allow ICMPv4 and 445 port for SMB-In. what a mess with my windows firewall. (tried restore windows firewall setting before but still blocked). Now works like a charm. Thanks

Normally pfSense will do NAT out the WAN, so traffic going out WAN will appear to come from the WAN IP. When WAN is on the public internet, and LAN is private address space, like in your example, you have to do that. Because the public internet cannot route back to your private address space. If you have public IPs on LAN, then you could switch to manual outbound NAT and delete all the rules. That will send packets out from LAN clients with the real LAN client IP as the source IP. Why do you think you need to do this?

Thank you very much for taking the time to respond. Will disable pfblocker and see how it goes.

Fair enough. As you can see 4GB is way more than pfSense uses without any packages running. I have a test box running 64bit that I upgraded from 32bit, the process was painless. You should check the firmware update location is set correctly if you do try this. I would probably go for a full re-install on a production box to be safe. There have been several hints from the devs that 32bit will eventually be phased out so that's one reason to be running 64bit. I hope it's not for a while though since I have several boxes that aren't 64bit.  ;) Steve

Exactly. Because your box is over-powered for your requirements? What is your WAN bandwidth? What packages are you running? The only problem you may have is that you're consuming more power than is necessary.  ;) Steve

Just kind of happened.  ;) Steve

Do you have a proper default route under Diag>Routes at the time? Can you ping that gateway IP? If so, what does a traceroute to something on the Internet look like when it's an issue?

pfSense is no different than any other router at the network level.  If your DMZ subnet is 172.16.0.0/24 then your other servers should also be in that same subnet.  Then you can use firewall rules to cordon off the DMZ from other network segments.

System->Routing, Groups Add a gateway group with WAN-A and WAN-B both at Tier1. (e.g. call it LoadBalance) On LAN add rules to match whatever traffic you want load-balanced. In the Advanced section of the rule, Gateeway - select the LoadBalance gateway group. Now the traffic is feed into the gateway group. As states are created they are round-robined between whichever WANs are up. And I see you are running a very advanced version of pfSense - 2.5.1 - what are all the new features that we will get in a few years?  ;)

@torontob: Thanks, is there anyway to do this without traffic shaping? I have used traffic shaping before and queues tend to full really quickly rendering the whole system useless. I find traffic shaping to be the weakest link in pfSense. Not as far as I know…

Cool - Glad its up.

Hi there, I was wondering if you ever managed to sort this out. I can't find any other posts on this subject and i have the exact same issue. Thanks!

@tobiascapin: Log http and https connection storing transfer length, destination hostname and local ip or mac address Filter hostname from a list of denied hostname or by regex rule Do not use a connection configuration (transparent) Do not decrypt https content and do not alter certificate exchange (man-in-the middle) Optionally can be usefult to cache the http content. Hi, Squid and SquidGuard will cover all of the points above. The SSL Interception is optional. As long as you leave the SSL Part disabled, there is no modification (and interception) of SSL traffic. SquidGuard is optional but nice to have if you want to use complex rules (e.g. complex Regex) and logging. Speaking of logging: All users should agree that you log there sessions. Due to the law in many countries. As an example: I'm from Germany and the German/EU law doesn't allow the logging of accessed URLs and other personal data. this is due to privacy protection. A valid workaround is to log the MAC Address and mask it in your reports.

@Mikeyb!: To caveat this first, this is a bad idea, but it's just for testing on a test network. Watch out for the vHosts Package. It works out of the box. Yes it have PHP, but if you really want to get rid of PHP just modify the Package defaults and you have a very light weight Web Server.

@kiekar: all worked fine even without changing any LAN and WAN settings on the wireless router. If you do that at the very least you must disable the DHCP server on the wireless router. It may be working fine now but sooner or later a device is going to get an IP address from the wireless router and it will be in the wrong subnet with the wrong gateway. Going the way you originally had it configured is generally frowned upon because of the double NAT, as Derellict said, but in many situations it will work fine. I'm writing this from behind double NAT and have experienced no issues with day to day stuff. Things get complicated if you have to forward ports though and some things (VoIP) really hate double NAT.  ;) Steve