Unable to whitelist MS Skype range

[bitcurition]

First of all, the pfblockerNG whitelist is at  the top of my firewall rule list on the LAN and WAN, followed by pfb block then pfsense block then pfsense whitelist.

In the pfblocker IP4 whitelist, I've added the iblocklist.com list which doesn't have the new Skype IP range as explained in this post:

13.107.64.0/18

52.112.0.0/14

Therefore I added these two in the IP4 whitelist's "IPv4 Custom List" in the format as in above and selected "update custom list" then update/reload the pfblocker and even reboot the pfsense.  Still, the 52.112.. microsoft IPs still shows on my pfblock alert list from the ip where I've been trying to log on to skype, both mobile phone and laptop.

Although I checked the "Suppression" checkbox in the General Setting, there are no "+" sign shows next to these blocked alerts, but in other alert such as those from "yoyo" there is "+" sign, no clue why it is like this.

What am I getting wrong on this?  These blocked IP by the way are from "level 1" (iblocklist.com) which I have to disable but I do like to leave it enable if I can figure out how to whitelist or supporess certain IP range.

[BBcan177]

Keep in mind that Domain (DNSBL) and IP blocking are independant of each other.

When you whitelist/suppress an IP, it doesn't remove any Domain names that are associated with those IPs.

In the Alerts Tab, you will only see a "+" icon for a blocked IP if its a /32 or /24 Blocked IP.  If the "+" icon is shown, then that IP can be suppressed and added to the suppress list.

DNSBL will also show a "+" icon but that will only whitelist the Domain listed.

If you have added the "52.112.0.0/14" to a Custom list, did you define the Action as "Permit Outbound" and is this permit rule above the other Block rules? You can change the Auto rule order in the General tab.

I'd also recommend not using IBlock as they are not very well maintained IMO… YMMV...

[ASM_COPE]

So the IPv4 lists support the CIDR formats?  Nice to know if that's correct (no documentation elsewhere that I've found to confirm this).

I've been struggling a bit with the whitelist process - but with the list set as "Permit_Inbound" and appearing at the top of all the Rules, they don't seem to be "obeyed".
I posted yesterday under a different thread the detail of what I had tried and then ended up with: https://forum.pfsense.org/index.php?topic=102470.msg750435#msg750435

But after several folks indicated customer emails (from domains that I had already whitelisted the IP's for) were still not coming through, I obviously need to revisit this.

So, I have defined two lists under the IPv4 tab of PFB (attached images 1, 4 and 5).  One uses just IP (no CIDR notation), the other I started this morning by adding domain name (google.com, gmail.com being two examples - don't know if that format is correct as there's no documentation examples).  Both of these are set as "Permit_Inbound", as I found that using the Alias_Permit option and manually adding the rule doesn't work as PFB always pushed the rule below the block rules on each update (see my detail in the post linked above).

The PFB rule priority is pfB_Pass/Match | pfB_Block/Reject | pfSense_Pass/Match | pfSense_Block/Reject.  This keeps the Permit_Inbound rules above the Block rules (attached image 2).

But… looking at the admin home page with the PFB summary, there are zero packets indicated for matching the "pass" rules (attached image 3).

I've used both mxtoolbox.com and dnsstuff.com to check for the MX server IP's to add to my IP list.

Testing a message from gmail to myself failed, despite the pass list settings - until I unblocked USA, at which point several messages came through (also from sources I thought I had whitelisted, such as Microsoft).

I'll reiterate that I am using the GeoIP "block" approach rather than its "permit" approach, as this seems to provide the actual protection expected.  But as noted in my post linked above, I am very happy to alter the config based on solid information.  I do not have DNSBL (Unbound) enabled - I have not been able to determine if this is a requirement for the GeoIP feature to work fully (particularly the whitelisting), or a separate feature altogether (again, no documentation to cross reference).

Does anyone know of a user-guide (up-to-date wiki, whatever) that actually FULLY documents all the features in pfBlockerNG and explains what the various choices are and their impacts?  This seems such a hugely popular add-on to pfSense (and great kudos is due to BBCan for developing it) but with zero official documentation, it makes it very hard to determine the correct implementation for a given desired control scenario (I'm an IT person in a small company, but NOT a network specialist and have limited resources, so clear A, B, C steps are always welcome).


[MarkVLK]

I'm having a similar issue with whitelisting, but for Hulu and Dropbox (I guess for who is irrelevant). Some of the pfBlockerNG "help" text seems to be misleading.

I'm running pfSense 2.3.4-RELEASE-p1

So under Firewall > Rules > LAN, if you scroll to the bottom of the page and click the blue "i" information bubble it says:

"Rules are evaluated on a first-match basis (i.e. the action of the first rule to match a packet will be executed). This means that if block rules are used, it is important to pay attention to the rule order."

However, if you go to Firewall > pfBlockerNG > IPv4 > Edit/Add an alias, and click the same blue "i" information bubble in the List Action section it says:

"'Permit' rules create high priority 'pass' rules on the stated interfaces. They are the opposite of Deny rules, and don't create any 'blocking' effect anywhere. They have priority over all Deny rules."

It even goes on to say that this is what you'd want to use if you were creating a whitelist… So I was sure I was doing it right, despite the other message on the Rules page saying that rules are evaluated top-down (first-match basis). So I used this mechanism to create a "Whitelist_IPv4" alias, added CIDR ranges applicable to the "IPv4 Custom list" section, added a custom DST port and protocol in the "Advanced Outbound Firewall Rule Settings" section, and set List Action to "Permit Outbound" which automatically added it to my LAN interface as desired thanks to the "Outbound Firewall Rules" section under Firewall > pfBlockerNG > General.

Now in my LAN firewall rules, I see the anti-lockout rule, all the block/deny rules created by pfBlockerNG (from IPv4 aliases), the single whitelist rule also created by pfBlockerNG, then some block/deny and permit rules I added manually. The issue is that I still see my devices getting blocked by one of the pfBlockerNG block/deny rules when trying to hit IPs defined in the CIDR range I added to the whitelist rule. I can only assume this is because the block/deny rules are above the whitelist rule, but then why does pfBlockerNG say that permit rules have priority over all deny rules?

The predicament I have based off of this behavior is that I can't just pick one of the defined rule orders in the dropdown of the Rule Order section in Firewall > pfBlockerNG > General because any one of them will break my rules in one way or another. I need my rules to be ordered like:

• pfB_Pass/Match

• pfB_Block/Reject

• All other Rules

The reason for this is that I need the pfBlockerNG whitelist permit rule first to allow connectivity to IPs/ranges blocked inadvertently by pfBlockerNG block lists, then I need pfSense permit rules to allow NAT redirecting DNS traffic to a specific local IP and allowing DNS traffic to the LAN address, then I need a pfSense block rule to block DNS to any other host, then I need my default allow LAN to any IPv4/IPv6 rules.

Therefore, it can't be as simple as permit/block/permit/block or block/permit/block/permit, etc. I really need the flexibility to put rules in an order I choose, OR I need it to function as promised where pfBlockerNG permit rules take priority over pfBlockerNG deny rules so that the whitelist feature works as expected…

[ASM_COPE]

Hi Mark - I'm still seeing very low matches to the inbound whitelists I've created.  In fact today, the only match listed in the Alerts (under the Permit category) was for the notification from the forum of your post on this thread.

One option I have looked at recently that might help your scenario is by using a "Floating" rule.  According to the pfSense wiki, Floating rules are processed before WAN or LAN rules.  These can be set to "quick" mode, so once matched, no other rule will apply.  You can use the "pfB_" prefixed alias generated for your custom IPv4 rule, so once added to the Floating rule, you would maintain the alias content through PFB's IPv4 page.  Might be worth you looking at that as a workaround to get the pattern/order you want.

I agree that the on-screen comments/help within PFB's pages can be confusing.  Another example is under the Advanced Inbound Firewall Rule settings for the IPv4 list, where "Protocol" default is "any", but the comment underneath that setting states "Do not use 'any' with Adv. Inbound Rules as it will bypass these settings!"  So this is very confusing (at least without further reference to explain this further).

Similarly to yourself (but for inbound rather than outbound), I have configured the IPv4 lists advanced inbound rule to restrict the traffic (in this particular rule case) to only permit email ports (via an alias list) and set destination to our email server (again by an alias entry for easier future rule management in case the internal server IP ever changes due to system migrations, etc).

I have managed to have the rules in the process order I wanted (custom IPv4/domains whitelist first, then the block lists, then the NAT forwarding for services) using the PFB rule order option.  I'm pretty sure that in our case it must be the limitation of my list content that is to blame for what I've interpreted as "not working" - as in us not having enough of the correct source address entries to match all the desired allowed senders.  And this is the real bug-bear of taking this approach - that list may never be complete and so we'll always face the risk of unintentionally blocking a valid customer email due to lack of config.

The plus-side of the lists is that a lot of our customers are using centralised email security services such as messagelabs.com - so in theory adding these to the second list using Domain/AS mode should simplify the admin.

But from a business viewpoint it's a PITA and while the blocking has helped cut a huge amount of malicious connection attempts (of various services, not just email) I'm not overly happy with the amount of time required to maintain this approach.

I commented elsewhere on the forum that the recommended approach of using PFB's GeoIP mode of "allow country" instead of "block world" doesn't prevent the malicious connections to NAT'd services.  I have tested reverting to the recommended "permit" option, selecting UK only in the "Europe" list, and got a large spike in malicious attempts to connect to our VoIP server - so promptly switched back.

Only by using "deny inbound" for the majority of countries (only allowing UK and USA) have I managed to get the primary desired protection result - although I'd like to also block USA with the caveat of adding valid senders using trusted USA-based services to the whitelist - and trusting that the whitelist would work.

[MarkVLK]

@ASM_COPE:

One option I have looked at recently that might help your scenario is by using a "Floating" rule.  According to the pfSense wiki, Floating rules are processed before WAN or LAN rules.  These can be set to "quick" mode, so once matched, no other rule will apply.  You can use the "pfB_" prefixed alias generated for your custom IPv4 rule, so once added to the Floating rule, you would maintain the alias content through PFB's IPv4 page.  Might be worth you looking at that as a workaround to get the pattern/order you want.

Thanks for the pointer! I'll have to check that out and see if it will help me get everything functioning as expected given the shortcomings/unexpected behavior of the other options I've tried.

[BBcan177]

@ASM_COPE:

So the IPv4 lists support the CIDR formats?  Nice to know if that's correct (no documentation elsewhere that I've found to confirm this).

Yes it supports CIDR, Range and single IPs.

I've been struggling a bit with the whitelist process - but with the list set as "Permit_Inbound" and appearing at the top of all the Rules, they don't seem to be "obeyed".

pfSense is a stateful firewall, so you would most likely use "Permit Outbound" since when a device on the LAN makes an outbound request to a site, a firewall state is created that allows those IPs back thru the firewall on the WAN side…. So when you add a "Permit Inbound" you are allowing those IPs to access your site without something on the LAN making the initial request....  Permit Inbound should be limited to open WAN ports like a Web server etc....

@MarkVLK:

The predicament I have based off of this behavior is that I can't just pick one of the defined rule orders in the dropdown of the Rule Order section in Firewall > pfBlockerNG > General because any one of them will break my rules in one way or another. I need my rules to be ordered like:

The Auto rules may not work for all network requirements. You can always use "Alias Type" settings. Click on the Blue Infoblock icons to see how that works… Basically the pkg downloads the IPs and puts them into an Aliastable.... You then make you own Firewall rules as required and then associate those rules to the applicable aliastable.

@ASM_COPE:

I'll reiterate that I am using the GeoIP "block" approach rather than its "permit" approach, as this seems to provide the actual protection expected.  But as noted in my post linked above, I am very happy to alter the config based on solid information.  I do not have DNSBL (Unbound) enabled - I have not been able to determine if this is a requirement for the GeoIP feature to work fully (particularly the whitelisting), or a separate feature altogether (again, no documentation to cross reference).

IP and Domain blocking are two completely separate processes… Only exception is the DNSBL IP which is a firewall rule created when the Domain feeds contain IP addresses, as those cannot be blocked by the DNS Resolver.

Does anyone know of a user-guide (up-to-date wiki, whatever) that actually FULLY documents all the features in pfBlockerNG and explains what the various choices are and their impacts?  This seems such a hugely popular add-on to pfSense (and great kudos is due to BBCan for developing it) but with zero official documentation, it makes it very hard to determine the correct implementation for a given desired control scenario (I'm an IT person in a small company, but NOT a network specialist and have limited resources, so clear A, B, C steps are always welcome).

Thanks… I'm still one guy doing this all myself... I try my best to post here, Reddit and Twitter to help... Its on the list of things to improve but as such no one really like making documentation :)  Wish there were more time in the day ....

[ASM_COPE]

I've been struggling a bit with the whitelist process - but with the list set as "Permit_Inbound" and appearing at the top of all the Rules, they don't seem to be "obeyed".

pfSense is a stateful firewall, so you would most likely use "Permit Outbound" since when a device on the LAN makes an outbound request to a site, a firewall state is created that allows those IPs back thru the firewall on the WAN side…. So when you add a "Permit Inbound" you are allowing those IPs to access your site without something on the LAN making the initial request….  Permit Inbound should be limited to open WAN ports like a Web server etc....

Yes, this latter config is what we need, as we have onsite email server (so need to permit inbound for email delivery at any time) and web servers (offering features for staff and customers via controlled accounts) and VoIP telephony (I've now locked this service's ports to only allow connection with the authorised SIP Trunk supplier, so that's helped there).  I think my lack of confidence in the whitelisting has been partly due to not having them fully configured (Google/gmail, protection.outlook.com and Messagelabs all use large ranges of MX addresses some of which seem to randomise which I suppose is due to loadbalancing) - I have added more domains in the Domain/AS IPv4 custom whitelist, but am still somewhat shy of re-enabling the country block for USA (further validation testing would certainly be required in addition to expanding those lists to all our non-UK-hosted customer mail servers).

Does anyone know of a user-guide (up-to-date wiki, whatever) that actually FULLY documents all the features in pfBlockerNG and explains what the various choices are and their impacts?  This seems such a hugely popular add-on to pfSense (and great kudos is due to BBCan for developing it) but with zero official documentation, it makes it very hard to determine the correct implementation for a given desired control scenario (I'm an IT person in a small company, but NOT a network specialist and have limited resources, so clear A, B, C steps are always welcome).

Thanks… I'm still one guy doing this all myself... I try my best to post here, Reddit and Twitter to help... Its on the list of things to improve but as such no one really like making documentation :)  Wish there were more time in the day ....

As a solitary internal developer myself (.Net, both winforms and ASP.net), I do appreciate the balance of time on developing vs. documenting (against all the other duties that come of wearing all the IT hats in a small company) - but I also recognise the value of reference docs to the community of users (in my case, mostly clinical staff who may not all be very tech-savvy).  In addition to a "full doc" PDF they can download for full/wider reference, I've started adding on-screen pop-up help panels (similar to what you offer in the PFB interface).  The pop-ups only offer limited info specific to one option - so don't give the "wider view".  The full ref PDF allows for more detail of course.
In the case of PFB, I'm not sure the doc would be very big.  A short illustrated comparison of GeoIP in the default "permit inbound" mode, vs the "deny inbound" (even a simple bulleted pro/con list perhaps of considerations?) could be just 2 or 3 pages with screen-shots?  It's not a published book of hundreds of pages I'm looking for - a "pocket guide" to be sure we're making the right choices for long term admin/maintenance balanced against the desired security objectives…

But I don't know what you're up against in time (day job permitting, etc!).  Despite my "griping", I'm very appreciative of what the add-on already offers (and I've read that the next version hopes to offer some easier configs).

[BBcan177]

If you're a pfSense Gold member, then you could take a look at the pfBlockerNG Hangout as that might help for now… Thanks for the feedback... appreciate it...

[MarkVLK]

@BBcan177:

@MarkVLK:

The predicament I have based off of this behavior is that I can't just pick one of the defined rule orders in the dropdown of the Rule Order section in Firewall > pfBlockerNG > General because any one of them will break my rules in one way or another. I need my rules to be ordered like:

The Auto rules may not work for all network requirements. You can always use "Alias Type" settings. Click on the Blue Infoblock icons to see how that works… Basically the pkg downloads the IPs and puts them into an Aliastable.... You then make you own Firewall rules as required and then associate those rules to the applicable aliastable.

I use the alias type firewall rules as well for various block lists, however it appears those are still affected by those rule orders.

[ASM_COPE]

Are we able to use a wildcard for sub-domain names in the Domain/AS mode of the IPv4 lists?

For example, messagelabs.com use a set of server clusters for their MX's (e.g. cluster5.eu.messagelabs.com).
Keeping continual track of all these would be awkward.

Does the list option allow *****.eu.messagelabs.com as a way to auto-resolve all the sub-domains?
(Similarly desirable for *.protection.outlook.com)

[ASM_COPE]

@ASM_COPE:

Are we able to use a wildcard for sub-domain names in the Domain/AS mode of the IPv4 lists?

For example, messagelabs.com use a set of server clusters for their MX's (e.g. cluster5.eu.messagelabs.com).
Keeping continual track of all these would be awkward.

Does the list option allow *****.eu.messagelabs.com as a way to auto-resolve all the sub-domains?
(Similarly desirable for *.protection.outlook.com)

Answering my own question: No, it doesn't seem to support sub-domain wildcards.
I created a test list with just one known domain (the messagelabs one, first testing *.messagelabs.com), but the add-in log file reported "Aliastable file not found".  Also tested as *.eu.messagelabs.com, but the same logged result.