Looks that way. Register it (www.pfsense.org/activate) and open a ticket. Refer to this thread and RMA should be easy.

Ah, after ages of wondering what on earth is going on, checking settings over and over, it seemed the interface had been unselected. So em0 was no longer em0. How annoying is that! Anyway, online and all good.

I really don't get why you don't just vpn, its sure not overkill.  And allows you do other stuff other than just ssh in.  I can vpn in from my phone, my desk at work via a proxy.. Click I have the vpn connection. As I stated before if your going to allow ssh on the wan.  I would look it down to only the region of the world your going to be coming from, and yes turn off password auth.  If possible lock it down to your actual IPs or netblocks you will be coming from for remote admin.  This is quite easy if your admin your own remote sites from say hq or your house, etc. If you leave it open your going to not only get firewall noise of a hit, but log noise of them trying to log in even if you have just public key.  If you want to reduce that noise then change the port - but this might be a limit to where you can access it from if they are not allowing for your non standard port outbound. One of the nice things I like with openvpn is running it on 443 tcp which pretty much always open if there is internet access where your at.

sorry, but anyone could suggest complete list of yahoo ASNs…thx

those lines are exactly what I see whenever my system boots up but just continues to normal boot after that. I can now do a clean install of 2.3.2 CE version again. Thanks for the reply!

Any host needs a route to the networks it wants to reach outside its own subnet. The default gateway is the router the host will send traffic to that is not in its local interface subnets and for which it does not have a route in its local routing table. This is typically the interface address of the router on the host's subnet. Look at the diagram I link to below. The default gateway on Host A1 would be 172.25.232.1 The default gateway on Host A2 would be 192.168.1.1 etc.

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.