@johnpoz

ok so my ISP opend up my NAT i able to connect to the VPN by the DDNS adress configred on the router!!!

one more Q... i am using openvpn... lets say i want to pay and use somnthing like expressvpn, will i get faster speeds ?
or it depends on my ISP speeds?

also can somthing like expressVPN do a tunel to a network?
https://techrobot.com/how-to-set-up-and-use-expressvpn-on-pfsense/

from all the latest VPNs(nordVPN , all paid ones) are advrtised to watch netflix? and stuff
my Q , do thay still funcation as a vpn , or just a fancy tunel out of your host...

@mer said in How to best test/verify firewall rules?:

@furom said in How to best test/verify firewall rules?:

This surprises me a bit, and is in fact what made me want to test the rules. I have been told rules act according to "quick", that first match wins, but experienced otherwise when testing a bit with a simple raspberry pi,

Well, that's what the GUI hides a little from you, hence me saying "pfctl".

Under the hood, pfSense uses pf (originally from OpenBSD) to implement firewalling and NAT. pf has always been last match wins, but other keywords change that behavior. Think of an old HP calculator using RPN and you're thinking "correctly" ;)

If you look closely at the rules you'll see how the "as applied" order matches with the "floating", "per interface", etc ordering in the GUI.

Basically, rules you define in the GUI always have the "quick" added, which makes them effectively "first match wins" because "quick" aborts processing of the rules (there are a few exceptions, but for the most part this applies; I think floating rules you may have to actually check something to get quick applied).

Ah... That clears the woe around that, makes sense now. :)

This is a handy bookmark:
https://docs.netgate.com/pfsense/en/latest/

Definitively! Thanks, had found it already, but a great resource - almost a bit daunting... But what I have seen so far, really good and comprehensive!

If you have other packages enabled, it may affect what rules are evaluated and when, so I'm just talking about base install, nothing else enabled.

Got it, I haven't come to addons or anything like that yet, but will have that in mind when time comes.

The pf book by Peter Hansteen is a little old but the concepts and fundamentals still apply to "how pf works".

Disclaimer: take anything I write here as my opinion, not an official "pfSense position" and like any thing else engineering/networking more than one way to get your result.

For sure. I read a lot and try to compute what I can from it... :) Good thing there is a great backup feature, so there's most often a way back to where I started if messing things up too much :)

@the-other
Yeah this is even better 😊

Thanks everyone!
My confusion was with 'blocking' - I thought it was a too way street. Now I understand it only prevents the source from Initiating a connection, but not replying to a request.

@silence I wish i could provide more info, but as looking in General Error Logs, there is no something specific.

@briankoch709 said in Firewall policies work (sometimes):

For a stretch of 15-20 minutes, working firewall policies stop working, resulting in blocked traffic. And then after some time, traffic will then be allowed. It's occurring quite regularly, and getting frustrating with my customer.

What services do you have enabled?

checks the status of your gateway during the period of time that the rule stops working.

and post your full logs! please (not from the dasboard)

@furom well you could always test by trying to create connects your rules should block and set them to log and see if the block is logged, etc.

But to be honest I have never seen an issue where rules were not what they say they are.. If having problems with say block rules not working - most likely an existing state that is allowing, etc.

Being a good netizen I have an outbound rule to block rfc1918 that shouldn't go to the isp, ie if I typo something locally or something.. If there is no local network your trying to get to, then yeah pfsense would route that out the public internet, wouldn't get very far ;) But sure if you don't want to send such possible noise to your isp you could create an outbound block rule in floating for the rfc1918 space..

blockrfc1919outbound.jpg

@johnpoz Here is the DMZ rules now and is it completely separated from LAN and future VPN?

Screen Shot 2022-01-20 at 5.41.37 PM.png

Screen Shot 2022-01-20 at 8.19.03 PM.png

@dma_pf Yes. As I said "NAT and firewall rules don't seem to help."

I've done it, with logging.

At this point my initial goal is to see the packets in a log. No success to date. tcpdump easily finds them with a port filter ;)

@nosenseatall said in Firewall Rule Not Working:

One other thing that I don't understand, is when I am on either network and use terminal to ping either way the don't go through.

To ping from Netgear to LAN you will need to create an allow rule in the Netgear rules to allow the ping to to the LAN network. You do not have to create a similar rule on the LAN rules.

Are you sure that the Netgear access point is set to respond to pings?

@darkcorner said in Tips for IP with CIDR Summarization:

This is for each office, both central and remote.
Instead, I was thinking of using a configuration with now
192.168.0.0/20
In this way I would have:
192.168.16 - 31.x for the head office
192.168.32 - 47.x for the first remote office
...

The broadcast address is the last IP address in the subnet and the network the first.

I'd leave spare subnets at the top of each range unused incase you have any extra requirements at each site, i.e:-

Site 1

192.168.0.0/20

192.168.0.0/24 WAN network
192.168.1.0/24 LAN network
192.168.2.0/24 OPT1 / DMZ1 network
192.168.3.0/24 OPT2 / DMZ2 network
192.168.4.0/24 Spare
192.168.5.0/24 Spare
192.168.6.0/24 Spare
192.168.7.0/24 Spare
192.168.8.0/24 Spare
192.168.9.0/24 Spare
192.168.10.0/24 Spare
192.168.11.0/24 Spare
192.168.12.0/24 Spare
192.168.13.0/24 Spare
192.168.14.0/24 Spare
192.168.15.0/24 Spare

Site 2

192.168.16.0/20

192.168.16.0/24 WAN network
192.168.17.0/24 LAN network
192.168.18.0/24 OPT1 / DMZ1 network
192.168.19.0/24 OPT2 / DMZ2 network
192.168.20.0/24 Spare
192.168.21.0/24 Spare
192.168.22.0/24 Spare
192.168.23.0/24 Spare
192.168.24.0/24 Spare
192.168.25.0/24 Spare
192.168.26.0/24 Spare
192.168.27.0/24 Spare
192.168.28.0/24 Spare
192.168.29.0/24 Spare
192.168.30.0/24 Spare
192.168.31.0/24 Spare

You could even split a /24 into a /25:-

192.168.31.0/24 Spare split into /25 would give you:-

192.168.31.0/25
192.168.31.128/25

https://packetlife.net/media/library/15/IPv4_Subnetting.pdf

@dlewis_nepean

So tested the recommendation and it doesn't seem to work.
I have a PPPOE interface plus a /29 so 6 ip's total.

the PPPOE interface is the one I use as my general nat. when I put that IP in the override wan address ( I even rebooted). The same situation happens. the 8081/8082 ports which are on one of the other ip's fail. The Device that is using the uPNP reports the correct external address. but when I go to the status page in pfsense, the entries that show those ports and internal IP show "any" under Ext IP.

@viragomann Perfect, missed that one, thanks!

@cathal1201 Sorry, it looks like I'm a little behind on the timing of your responses and me typing mine.

Ok, so if that's not working, you can also make the opposite - a pass rule with the time frame you want the IP address to have access. But, in this case, you have to also setup a BLOCK or DENY rule immediately under it, no schedule, for the same IP address.

I'm gonna be honest, it's a little bit difficult to setup a schedule-based rule in pfsense, since it's a stateful firewall, and states aren't necessarily dropped like you/we are hoping. You have to try either one of these methods until you get one to work. In my opinion, it should be a lot easier than this, but it it what it is...

@peter247 when connecting routers there really should be a transit network (no hosts on this network) this prevents asymmetrical flow that can happen when you talk to devices that sit on the network between routers..

I have gone over this countless times... Here is old post with some drawings explaining the problem.

https://forum.netgate.com/post/865509

If you only have 1 router, pfsense and your networks all are connected to pfsense - then you don't have asymmetrical flow as long as these devices can not talk to each other in some other way that does not flow through pfsense.

I had the same issue after updating to 21.05.2.

For my use case the easyrule script is a somewhat critical need. I have never applied a manual patch on pfsense before, but this one was relatively easy.

I basically took the new easyrule script from the redmine, and dropped it in usr/local/bin. (replacing the previous easyrule). And it works fine now.

@hescominsoon without you showing us what you had done its not possible for us to know what you might have been doing wrong.

But to be honest inverted or ! rules are not how I would suggest you do it.

Allow what you want to the firewall, icmp, dns, etc. Then create a block rule with your rfc1918 alias, then below that an any any rule.

Here is an example set of rules. That prevent a vlan/network from talking to any other rfc1918 networks, and still allows internet

rules.jpg

! rules can work, and do - but there are some scenarios where they could be problematic, its just better to set explicit rules. Much easier to read and understand from a quick glance of your rules as well.

The block to "this firewall" prevents this vlan from accessing the web gui of pfsense on its wan IP, which quite often is public IP, and without that rule would be allowed via the any any internet rule.

I found the problem.

0089fae6-f2a8-405d-818d-8a40648a0bf7-image.png

The virtual machine can now access the internet.

@sp00ky

These :

33fef112-7eba-4b44-bd64-e8d63d6f9a9f-image.png

b2d7d122-5d86-4e34-a0fe-7293654ff378-image.png

If you suspect DNS issues, I advise you eliminate all third parties.

The first image : wipe them all. This is the default.
The second image : When checking "DNS server override" pfSene will use the DNS info received when establishing the uplink to your ISP. This means you'll be using the DNS servers that your ISP suggested. This method is what our ISP rouyters use, very popular in the past.

What pfSense does, out of the box : it resolves. This means that it uses one or more main root DNS servers. There are 13 of them. IPv and IPv6 The addresses are build in, as they are very fixed and static. These main servers know where to find all the com org net us, any known TLD name servers. All these tld servers are cloned all over the place, so there is always one near by. One goes down ? No problem, another one will do the job.
These tld servers maintain the domain name records that are accessible by the registrar : when you rent a domain name, the registrar writes into the tld the domain name and the domain name servers of your domain name. There must be at least 2 domain name servers. These domain name servers of a domain name can tell you (pfSense, your browser etc) what the IPv4 is for a given domain, what the MX is, the IPv6, or an alias, or whatever TXT field.

If you can not resolve spotify.com : use nslookup and siwth to trace mode, or use the console access on pfSEnse, and ask for 'why ?' :

dig @127.0.0.1 spotify.com +trace

Knowing that spotify is not a small player on the Internet, there must be an answer.
No or wrong answer means :
Your uplink is bad,
Your ISP has peering issues ?
Your ISP, or someone upstream, is changing your DNS requests ?
The resolver, unbound has issues ? ( check the pfSense resolver logs )
And last, but not least, facebook has learned us that even the big companies themselves can have 'internal' issues that removes the access to all of their own domain name servers.

The biggest bottleneck is always : your uplink - and anything close to that uplink.
pfSense, the resolver, on an average box, can handle you thousands of DNS requests and answers a second. These have to 'fit' over the uplink. Your ISP will route them then to the DNS server the resolver chose to work with.

This method is created, tested, by billions, and this is done over 30 or 40 years.

Of course, you could use some external DNS server, like 8.8.1.1 - or the DNS server of your ISP. Just say to yourself : why would do these servers exist, knowing that they cost (hundreds of) millions every year to maintain ?
8.8.1.1 is a resolver, just like the one pfSense uses. So my thoughts are : when doubt, use the shortest road, exclude all non needed factors.

Btw : I excluded local problems like a bad WAN interface of pfSense. You mentioned one domain name, and not overall bad 'access quality'.

@johnpoz said in traffic in wan:

And gain your "users" have no complaints of anything be slow or not working?

Exactly, nobody is complaining about anything and in the firewall you continue to see this type of traffic.

@bluesun, no I haven't.

@johnpoz said in stretchoid.com IP list for use in blocking their port scans:

@sissy said in stretchoid.com IP list for use in blocking their port scans:

IPs I've seen in recent times have been in the 192.241.128.0/17

Why would you need to parse anything? If you have the netblock they are coming from, just block the whole /17?

Because there are 32K IP addresses in that range and only 2.5% of them are assigned to stretchoid.com. Some of the others are assigned to legitimate small businesses and organizations, some of which could be clients of, or vendors to, someone for whom I provide services.

For that matter block all of digitalocean inbound.. What/who would be coming from some IP hosted at DO?

Email is one thing that comes to mind, and there are just shy of half a million mail servers hosted on Digital Ocean.

Sure not going to be actual clients you would like to allow.. Block their whole freaking ASN, which you can easy setup with pfblocker.

No one would want to do business with python.org, letsencrypt.org, or Alex Green Farms, which sells organic fruits and vegetables, right? I may not like that the National Eating Disorders Association (NEDA) chose Digital Ocean as their provider, but NEDA is the type of organization that might turn to my client for content creation.

Inbound block doesn't stop you from going there, but it would stop any inbound unsolicited traffic to your IP, like scanning for what ports you have open,etc... I show the ASN for that netblock to be AS14061 – DigitalOcean, LLC

My firewall is on a business Internet connection on which I host servers. It's not something through which I'm web surfing. I don't have the option of firewalling off 2.6 million U.S. IP addresses and then just hoping that everything works out.

There is another very good reason for parsing: I have a rule that is logging port scans by stretchoid.com so that I have a record of the activity.

@frodo problem is you don't know what disector to use, or you need to write one to be able to view the details of that payload you see there in DATA..

You would need help from the vendor, or you need someone that does that sort of thing.. That could be completely benign and be just some info in a json file, or it might not be..

With the noise for example I showed you there are lots of people that have dug into that and listing what is being sent, etc.

For that - You could try decoding it as different stuff in wireshark.

https://ask.wireshark.org/question/20679/how-to-decodedecrypt-udp-packet-data/

@silence They? :) I added one and one network range each time a new IP appeared and this managed to stop the attack already at pfSense. Since the traffic then didn't go to the heavy wordpress site, that solved the issue.

I managed to (sort of) get this to work.

Rather than create the rules on the LAN, I created the rules on the WAN.

It's not ideal because it requires the filter to be applied to the destination server IP, which could in theory change. I'll just have to keep an eye on that.

I tweaked etc/inc/filter.inc to add the new rules immediately after the marker for the user defined rules:

$ipfrules .= "\n# User-defined rules follow\n"; $ipfrules .= "\nanchor \"userrules/*\"\n"; $ipfrules .= "pass out log on { em0 } dup-to ( em1 192.168.aaa.aaa ) inet proto tcp from any to bbb.bbb.bbb.bbb port 80 tracker 1641638644 flags S/SA keep state label \"USER_RULE: Outbound mirror\"\n"; $ipfrules .= "pass in log on { em0 } dup-to ( em1 192.168.aaa.aaa ) inet proto tcp from bbb.bbb.bbb.bbb to 192.168.ccc.ccc port 80 tracker 1641638677 flags S/SA keep state label \"USER_RULE: Inbound mirror\"\n";

where:
192.168.aaa.aaa is the internal IP address of the server on my network that is monitoring the device
192.168.ccc.ccc is the internal IP address of the device to monitor
bbb.bbb.bbb.bbb is the public IP address of the server that the monitored device talks to on the internet

@droidus said in pfblcokerng-devel possible web gui bug?:

I tried that, and it still deselects from the other field.

Try Click by holding CTRL pressed.

@johnpoz excatly , so i can change the gateway in routing of this isp , and under interface assimgnets, change the ip ,and add the new gateway that was given by isp.

@bly I did see (only now) on LAN side I did put 'TCP' instead of 'any' in the protocol. That was the error...

@hfarinha forgot to mention that I had to add acl's manually as well under DNS resolver otherwise dns resolution does not work.

@ddbnj I personally do not have such rules on my lan side interfaces currently. I do have some log rules for some specific blocks and specific allows. But my sons haven't been teenagers in like 20 years (both in their 30s) and long gone from the home.. But I get your reasoning ;)

If I was needing to troubleshoot something where I need to see all blocks for sure, I would just toggle the default logging back on.. But sure you could do the same sort of rules on your lan side interfaces.

I personally am more interested in unsolicited inbound into the wan that is interesting.. Gives me an idea what major noise is going on right now - remember back awhile when those modems got compromised and were generating tons of traffic globally - that popped up to the top of my block list in the report.. Then there is always the common 80,443,22,21,3389, etc.

@johnpoz I have it done through the host now. I'll get the opt port setup later today I'm just not by the device to do so now.

@viragomann We think alike, and that is exactly what I did. Floating rule, quick, selected the VPN interfaces, out, port any, dest port 636 IP any, etc etc. Sent the rule to the top. States showed traffic when ldap test was performed in user manager, as it once again fails because the outgoing interface is a VPN interface.

Was thinking creating a port alias, and bypassing that alias in LAN but the traffic never hits the LAN interface. It's coming direct from pfSense.

Ok, I get it now. Sorry.

I looked at my wan rules and noticed there had been activity on the port.

Opened up Emby on my phone and the magic networking fairies did there thing over night....
it now works

@nic82m, can detail more your configuration! How do you have your wan interfaces configured for example ...?

I managed to solve this.

I needed to add a NAT rule and fix the allowed IPs in the Peer definitions which used a /32 netmask and should have used a /0 netmask.