@coreybrett: Is there a proper term for referring to the practice of assigning multiple IP addresses to the WAN interface of a router? I'm looking for the right lingo to explain my setup to the ISP. You mentioned that you have an allow rule on WAN for ICMP.  What is the destination address/ network you have listed in the rule? Your ISP does seem to be routing/ forwarding your subnet in an unusual manner.  Most will deliver in a 1 + 8 or 1 + 16 manner. i.e.  There is a separate /30 for WAN and all of the allocated static IPs in the block will be forwarded through that.  How you want to use them (Virtual IP/ routed) is up to you.

I agree OpenVPN is the way to go - but I need OpenVPN with AD authentication … and comes with it own set of challenges. The reason this one is an issue is that there is a PPTP server inside the LAN - pfSense 'forwards' to it. When the person is trying to connect to a PC on the internet (customer) using PPTP/RDP and setting up a new PPTP connection the reply coming back in from wan goes back to the PPTP server in the lan rather than the PC that initiated the connection. I found out that this is a 'known' issue and can be avoided with a second static IP etc. but I rather remove the PPTP server from the LAN and go with OpenVPN.

Maybe unrelated but check apinger logs. I had once a situation where connection stayed up but the gateway did not respond in time. Causing pfSense to reload its rules causing unwanted outages. You can adjust apinger treshold if needed. Good luck Peter

There is the Service Watchdog package that JimP wrote a couple of months ago. That auto-restarts services that go missing. It does not have any function to send notifications, but perhaps it could be enhanced to optionally send notifications (and optionally just send a notification and not actually restart stuff automatically).

If you are using postfix, i would suggest that you use RBLs to reject suspicious mail. I would suggest the following ones: reject_non_fqdn_sender reject_unknown_client reject_unknown_hostname reject_unknown_sender_domain reject_rbl_client zen.spamhaus.org reject_rbl_client b.barracudacentral.org reject_rbl_client bl.spamcop.net reject_rhsbl_client dbl.spamhaus.org reject_rhsbl_reverse_client dbl.spamhaus.org reject_rhsbl_sender dbl.spamhaus.org Postfix can also incorporate ClamAV and Amavis. I would also suggest that you use pfBlocker and use the following lists - ET, Spamhaus, dShield, CI Army, Zeus/Spyeye/Palevo, iBlock at a minimum The above steps will block a lot of Suspicious known activity eartly on before ClamAV sees the traffic. You could still use ClamAV as a last step. Also using pfSense Snort on your WAN and LAN. There is also a product called "Security Onion" that can be installed as an IDS to get a full understanding of what is happening in your network. Hope it helps you

Hmmm… sorry about that. I intended these scripts to be an easy way to setup a very specific configuration. I've never had any issue as long as I've stuck strictly to the intended use case.  The downside of that approach is that I haven't tried a lot of variations (multiple gateway boxes, different gateway addresses, etc.) and I'm sure there are multiple ways it could be broken. However, if you can pin down issues with the install process or instructions (or give me enough info that I can find them) I'd love to know what they were so that I can try to fix them. I'm a software guy by trade as well. What I've learned about networking has been purely by playing with stuff like this. Nice to see someone else branching out...

Okay, i went back to the orginal rc.newwanip did only this: https://github.com/pfsense/pfsense/commit/f3a4601c85c4de78caa4f12fefd64067fd83dbe8 and added boot/loader.conf.local and these 2 lines are in that kern.ipc.nmbclusters="131072" hw.em.num_queues=1 Rebooted. Under Firewall/ NAT i checked: Static route filtering Bypass firewall rules for traffic on the same interfac IP Do-Not-Fragment compatibility Clear invalid DF bits instead of dropping the packets The servers are timing out a lot less now. Maybe once in 30 pings sometimes 2 pings in a row… What is see in the logs at that times are tcp:fa / tcp:a from DMZ packages , has that anything to do with that? for example: block Jan 16 14:14:03 DMZ serverip:80   ipadres:50155 TCP:A

I got it to work eventually, but not with passthrough, it just wouldn't go. I used bridge mode, but with ipv4 disabled for those 2 nics at the host, so that there is no direct connection from the host to the internet, only through pfsense. Too bad passthrough didn't work, would've been better.

What it should do (i think) is issue or not issue the "ifconfig-pool net/mask" option in the config file (if you follow the logic). But, I found the following, from my observations: if you try to use "ifconfig-pool" in the advanced options, you get an error (in the logs) saying that you cannot use ifconfig-pool and "server" at the same time, because "server" already creates a pool for you. Indeed there's a "server" option in the config. the server option is not very flexible because it is kind of a ifconfig + ifconfig-pool in the same option, and the server takes the 1st address and all the rest of the entire range is reserved for the pool. I like to issue a ifconfig-pool where I use only a portion of the range, leaving another portion to static IPs in the client overrides. from googling, it seems that in the old days there was a configuration text filed where you would indicate the range for dinamic assignation (just what I expected) and that would issue a separate ifconfig-pool config option (or not). I was then changed to, when on  (presumably) issue a server command taking all the range and (presumably) when off, switching that command back to a normal/simple ifconfig (which I would be happy with because it would allow me to issue a ifconfig-pool in the advanced options). In the current state it seems useless. But maybe I'm missing something.

Is this a known issue? By the way, this happens only if my default gateway (VDSL1) reconnect. Update: Have a look on a other pfsense with only one pppoe wan connection, ntp work here fine. See in the log that the ntp server stop for a reconnect of the wan pppoe connection, is it possible that the ntp server start again to fast? Update2: "fixed" it with the Service Watchdog package  ;)

I try this this tonight. Many thanks. Nico38.

That looks like a device already in modem mode (PID: 1506). Exactly what devices do you have in /dev? Please copy and paste the output of: ls /dev/cu* What was the result of trying to setup a ppp interface? What did the ppp log say? Steve Edit: The Huawei E5331 is a mobile hotspot device. Is that what you have? How are you connecting to it?

@loupalladino: Do you have Nagios by chance? Not yet, but is planned for 2014  ;)

Bravo johnpoz for hanging in there. I like nothing more than to help people understand networking - so I sure hope this helps the light bulb turn on for you Indeed you must.  And I'm sure you helped someperson472034.  In enjoyed reading your networking explanation as well.

Yes you can do all of that. Q1. If you have firewall rules in place pfSense will route traffic between the subnets. You can access a server at, say, 192.168.3.10 from a machine at 192.168.2.20 by simply entering it's IP. No need to bridge the subnets which would effectively make one big subnet. If you want to access servers by name you can add DNS overide entries to allow that. One area that can cause problems here is if you want to browse network shares. Generally the client OS will only look for servers inside it's own subnet. If you are running Windows clients and you have a Windows server you can specify the address of that as the WINS server in the DHCP information which will allow clients to know where to look. Q2. Yep, port forwards are easy enough and well documented. https://doc.pfsense.org/index.php/How_can_I_forward_ports_with_pfSense%3F Q3. Yep, traffic shaping on a per IP basis can be done. A better configuration would be to bridge your router so that your public IP is on the pfSense WAN interface. That will, as you say, make port forwarding easier. Steve

I was having an issue where my WAN interface would not stay up.  I switched the WAN interface from em5 to em0 and found the problem was resolved.  Every other time I've plugged anything into em5, same result.  My issue seems to have been simply hardware related. Maybe swap interface assignments and see if you get the same result on the the same NIC.  If so, it's most likely hardware related.  If the problem moves to the WAN interface on the new NIC, the problem is probably generated by a conflict between the pf box and the router/modem, or some other ISP setting. At least, that sounds logical to me!  : )