In this L2TP/IPSEC setup, the firewall rules in the interface tab do not seem to apply because of the underlying "incoming" assumption. To log traffic from L2TP clients, I created a "pass all" FLOATING rule, interface L2TP/IPSEC, direction outgoing, all IPv4 protocols, TCP flags any, sloppy state. That should take  care of it, but TCP traffic is simply dropped. So I added a second rule specifically for TCP traffic. The rules are: Pass&Log            IPv4 *                  *            *            *            *            *            none                    Secret Rule Pass&Log            IPv4 TCP              *            *            *            *            *            none                    Redundant Secret Rule In summary: the IPSEC interface will only log the first packet of the L2TP exchange all the rules applying to L2TP clients seem to be enforced only in the out direction and must be enforced with a floating rule it is not possible to drop a specific interface from the logs using an explicit block all rule. If anybody can enlighten me, I would  be grateful. Regards,

Thanks, I wouldn't have thought to look there, although it makes sense now I know! However, I think I've found a bug in the GUI: I select to create a new interface of type L2TP, select the wan interface as the link interface and fill out the required fields, but even when they're all filed in I get the following errors at the top of the page: The following input errors were detected: The field Local IP address is required. The field Subnet is required. The field Remote IP address is required. and the connection is not created, this is frustrating as it would seem I'm very close to getting the tunnel configured. I think the same error has been reported here in the forums but I don't really understand the fix explained: https://forum.pfsense.org/index.php?topic=110251.0 I'm happy to file a bug report (if I can) but if someone could explain a quick fix work around I'd be grateful : ) One last thing, I understood that when I connected to my L2TP tunnel I would be given an IP address so I'm assuming that the 'local IP address' setting will not be mandatory? Thanks,

Probably certified to be working with vmware in the first place, too. Of course.  Why would I run critical stuff on RandomCo hardware?? Are you talking about the official book? It is for version one and is seven years old. No, he's probably talking about this one.  There will never be another hardcopy book, says JimP.  This is a living document and will get updated as required.  Available to Gold subscribers only. [image: pfBook.png] [image: pfBook.png_thumb]

Why are you using an old version? At least upgrade to 2.2.6 Preemption should take care of that, you could verify the sysctl, but frankly do you have a problem with people unplugging the WAN cable from your master firewall? I know it seems a simple way of testing, but in my experience it is an absolutely useless test.

I think i solved it. I removed the GJTech and http://someonewhocares.org/hosts/hosts lists updated and reloaded pfblocker-ng now the problems are gone. GJTech list is gone http://someonewhocares.org/hosts/hosts is from top to bottom filled with 127.0.0.1.

@heper: @SoulChild: He's just using a /16, nothing wrong with that. I'm using a /8 at home(10.0.0.0/8) [image: 844.jpg] What's the point of subnetting a /8 if I don't even need more than 1 subnet and only have a grand total of 20 IP devices at home, including cellphones, tablets and a NAS? I don't do DMZ or hosting or anything.

I have tested on Chrome Firefox and Internet Explorer. Not tested on safari. For firefox you have to put the certificate on firefox's certificate manager. And as you said you have put the certificate in Trusted Root Certification Authorities but where on Computer account or User's Account. For me it worked with computer account and install the certificate with administrative privilege.

Cool, this is what I didn't know. Excellent, thank you. and most likely enough to fight brute force if your admin paswword is not "password" or "admin"  ;D ;D ;D

If you assign additional "virtual" IPs to you unique WAN interface, then you will be able to handle, at port forwarding level, different forward rules based on destination IP without having to rely on different port for same URL (e.g.) This is somewhat easier than true reverse proxy, with slightly different mechanism. It also allows different FW rules depending on destination IP, which also means capability to have different public DNS entries pointing to these different IPs well, quite a lot of flexibility  ;)

A problem with the hard drive or possibly the disk controller itself on the motherboard (where the drive is plugged in) I'm not sure if proxmox is smart enough to generate an NMI on its own for things like that, so it may be passed through from the actual hardware. There is a chance it's something in proxmox or the host itself, but someone more familiar with proxmox would have to chime in and answer that part.

It depends on what is causing the outage. It's definitely not normal to see that, but a couple different things could be to blame. For example, if one of your gateways is marked down and you have the option to kill states on gateway failure active, then each filter reload will kill all states, resulting in an interruption.

"Jumbo Frames configured on all switches, and devices." So your phones (wired and or wifi) and other wifi devices are doing jumbo frames?  What about your TV or your DVR?  What about your thermostat or your toaster? While jumbo frames might be of some use on a SAN, or other layer 2 where traffic is not routed and takes advantage of the large MTU say vmotion or FCoE and the already mentioned iSCSI.  Other than that I am with SoulChild on it being pretty pointless on the rest of your network. Your printers support jumbo do they? Have you actually benchmarked your applications using a standard mtu of 1500 and with jumbo.  Many applications are never sending full data packets anyway.  Lots of little packets on the wire, where jumbo doesn't do anything. To your trunking traffic to a lagg.  So hairpin, and you do understand that when 2 devices talk they are going to use only 1 connection in the lag.  So a hairpin that /2 the bandwidth the available bandwidth on the physical interface for that conversation.  So you think your jumbo is any real value here for moving large amounts of data? Lagg, Port channel, etherchannel, etc. what ever you want to call it 1gig + 1gig does not = 2gig.  It equals 2 1gig connections. If you your looking for performance for intervlan traffic I sure wouldn't trunk the connection. You should put each vlan on its own uplink so that you don't hairpin.  This prob going to give you way more bang for the buck then any jumbo frames. If you need more than 1 gig, then have a bigger uplink.  10gig for example.  Lagg to be honest is nice for mitigation of failed port or switch you set it up correctly.  But as to giving you a fatter pipe not so much.  And then you just hairpin anyway?  Trunking and putting more than 1 vlan on the same connection is ok when the vlans on that connection don't want to talk to each other and only talk to other vlans on other uplinks, etc.  But when devices going through the same uplink to where they can be routed to the other vlan on the same uplink you just /2 your possible bandwidth because of the hairpin.

If the traffic lends itself to it it can be done.

@rolandk, The symptoms you are describing is exactly what occurred at one of our customers. What version PFSense were you running? Our customer site was running 2.2.6

Here are some more characteristics rrom this problem. The WAN connectivity doesn't actually stop. What is actually stopping is the e-mail manager program, such as Thunderbird and Outlook, and only for certain machines. Thunderbird, for example, stops at the SMTP connectivity process. Whenever the e-mail managers aren't working, the firewall machine won't answer to ping requests. The Internet  is always fine though. Reconnecting the network cable fixes the problem (ping and e-mail managers) for some time, but then it comes back. Changing the IP does the same thing. Any clues?

@ha11oga11o: @JeGr: But mine PfSense goes into 1Gbit switch, so no lan traffic actually goes via LAN interface…. or yes? Its PC with two nic, one is wan other is lan, and then 24 port switch. What do you mean by "no LAN traffic goes via LAN interface"!? That make no sense at all. You have built a router with two NICs and put the faster one on the WAN side on a modem link, that is no faster than 40MBit/s as you write and put the slow 100MBit/s link to a GIGABIT Switch!? That's nonsense in my opinion. Why would you do that? Put the slow 100Mbps NIC on your WAN and modem side as your modem link won't be faster that 40 anyway and put the Gigabit Interface onto your Gbps Switch where it belongs! Why artificially limit your LAN connection if you don't have to? Also one NIC or the other may connect worse with auto sensing. Perhaps your Gigabit Switch doesn't like your slow interface that much? I'd sort that out first and double check all connections if the auto negotiation is going bonkers somewhere. Also what dotdash said, the NICs aren't known for stellar performance. What you said about chane sides of NIC it make sense. But i have gigabit speen in my LAN environment, so i thought it does not matter. I will change that and revert with results. Also, ill try to find intel based nics, that would be much better. Thanks. I reverted sides with NICs… had same issue. I simply reinstalled fresh and seems it works for now. Something somewhere it was wrong, thats for sure. But seems its easier to reinstall it and do settings from zero. Thanks for guidance.

It's been pretty stable for me running a PC Engines APU2.

I did some experimenting and tried different combinations of using the onboard Realtek network ports and the addon Intel PCI Network card.  The best speed results came from having my WAN attached to one of the Realtek ports and my LAN attached to one of the Intel ports.  I got speeds over 500Mbps down and over 700Mbps up.  I think the primary limitation is the bus on the motherboard.  PCI is just not enough for gigabit Internet.  Unfortunately, I have turned off the pfSense router and am using the Netgear R6300v2 that Cox provided which gets speeds over 900Mbps down and up.  Until I can build a beefier pfSense system, this will have to do.  :(