Netgate SG-1000 microFirewall

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - virgiliomi

Pages: [1] 2 3 4 5 ... 39
1
IPv6 / Re: What hidden rules are created for ICMPv6 and DHCPv6
« on: April 15, 2018, 06:39:51 pm »
First, the ICMP test of that site is strictly ping (ICMP Echo Request/Echo Reply)... there are many other ICMP packets that may or may not be blocked, so it's not even a really good test, just an easy test to perform.

If you're allowing IPv6 ICMP Echo Request into WAN via pfSense but still not coming up green, then it's likely your local firewall on your computer preventing the packets from getting in.

That being said... pfSense does have some hidden rules regarding some IPv6 ICMP traffic that are in place... those are IPv6 ICMP packets that are more important to IPv6 functioning properly (like for RA and NDP, among other things).

These are only present once...
Code: [Select]
pass quick inet6 proto ipv6-icmp all icmp6-type unreach keep state
pass quick inet6 proto ipv6-icmp all icmp6-type toobig keep state
pass quick inet6 proto ipv6-icmp all icmp6-type neighbrsol keep state
pass quick inet6 proto ipv6-icmp all icmp6-type neighbradv keep state

These are repeated for fe80::/10 to ff02::/16, the src/dest swap of that, and all are repeated again for pass in (changing echorep to echoreq)
Code: [Select]
pass out quick inet6 proto ipv6-icmp from fe80::/10 to fe80::/10 icmp6-type echorep keep state
pass out quick inet6 proto ipv6-icmp from fe80::/10 to fe80::/10 icmp6-type routersol keep state
pass out quick inet6 proto ipv6-icmp from fe80::/10 to fe80::/10 icmp6-type routeradv keep state
pass out quick inet6 proto ipv6-icmp from fe80::/10 to fe80::/10 icmp6-type neighbrsol keep state
pass out quick inet6 proto ipv6-icmp from fe80::/10 to fe80::/10 icmp6-type neighbradv keep state

There are also some rules if you're using DHCPv6. I'm just lazy tonight and don't want to edit my prefix out, so I won't be pasting those. :)

2
General Questions / Re: MFA for pfSense GUI
« on: April 15, 2018, 05:56:57 pm »
It doesn't necessarily matter who has access to it. Sometimes there are requirements your company must meet when it comes to IT infrastructure in order to do business with certain clients. So if you want that contract, you meet their requirements, no matter how many people have access to it.

3
I'll second chpalmer. I have WAN firewall rules for the SIP and RTP ports my two phones (one Panasonic, one Polycom) use when the connection is originating from my VoIP provider's IP address ranges, and I've never had any issues.

I'm fortunate that my provider has a support article detailing the address ranges they use, so I was able to set them up. I'm also fortunate that the two phones don't have overlapping default RTP port ranges... though I could probably adjust them anyway. I did have to change the SIP port for one of them though. :)

4
Traffic Monitoring / Re: NTOPNG, adding Pro or Enterprise License
« on: April 01, 2018, 07:50:59 pm »
If I had to guess, it's because the FreeBSD port of ntopng is likely the open source/community version, which probably doesn't have a way to support a commercial license. You'd need to get the ntop folks to create a pfSense package for their commercial version that could be installed in order to use a paid license.

Of course, they'd say "Why are you running this on a router/firewall?", and they'd probably try to direct you to their ARM versions, even though pfSense runs on Intel/AMD CPUs (with the exception of the newer Netgate produced devices; SG-1000 and SG-3100 are both ARM devices).

5
DHCP and DNS / Re: Identifying IPv6 devices with DHCP leases
« on: April 01, 2018, 07:34:06 pm »
The IPv6 address ending in ::17f1 you won't be able to use NogBadTheBad's tip for... that DUID appears to not be related to the MAC address. The one ending in ::1778 might also not be related to a MAC address.

What I would do is go to Diagnostics > Ping and ping those addresses... that should get them added to the NDP table, assuming you got ping replies, then you can go back to the DHCPv6 leases and hopefully MAC addresses will show for them now.

6
Traffic Monitoring / Re: Traffic totals not working for march.
« on: April 01, 2018, 08:24:16 am »
And now that it's April, the chart seems to show April properly, skipping March.

7
Traffic Monitoring / Re: Traffic totals not working for march.
« on: March 31, 2018, 07:12:36 am »
Why is my traffic totals not working for the month of march?

Is there something I should be checking? This happend last march.

Jason
Check the table closely... you'll see there are two 11/2017 rows with different numbers. And yes, I'm pretty sure I remember this happening in March last year as well.

8
Traffic Monitoring / Re: Monthly traffic reports?
« on: March 21, 2018, 09:12:52 pm »
There are definitely issues with the Status_Traffic_Totals package... mine's showing two "11/2017" months, and data for March 2018 is being shown as February as a result.

9
Official pfSense Hardware / Re: Coreboot update - release notes?
« on: February 13, 2018, 04:14:22 pm »
Then I must have been behind and didn't realize there was an update somewhere in the past. I'm currently running the 1.00.00.12 version.

Thanks for the link, ivor!

10
Official pfSense Hardware / Coreboot update - release notes?
« on: February 10, 2018, 07:15:03 pm »
I noticed that there was an update to the Coreboot package... so naturally after updating the package, I check to see if there's an update to the Coreboot software to be installed. Sure enough there is. Any release notes on what this might fix?

11
IDS/IPS / Re: Snort OpenAppID RULES Detectors fail to download
« on: January 24, 2018, 07:35:12 pm »
It might have everything to do with the timing of downloading your updates for Snort. I installed Snort not quite a month ago and have been downloading the OpenAppID Rules without any problems to date. I have my Snort updates run at 4:05a Eastern (GMT-5), with one update per day.

12
General Questions / Re: Ransomware Detection Capability
« on: January 20, 2018, 07:05:21 am »
I agree with johnpoz, this just for detection. Machine is still infected.
Correct... you haven't prevented the infection, but you have prevented data loss from occurring. And you still have the opportunity to remove the infection without incurring any data loss. Of course, if you're not backing up your data, shame on you... but that's a different story. :)

13
IPv6 / Re: comcast business head-scratcher...
« on: January 18, 2018, 09:23:52 pm »
With Comcast Business, spending the extra for a static IP Address isn't worth it IMHO. The inflexibility you get by having to use their own gateway ends up causing more problems than it's worth.

Skip the static IP, get a nice D3.1 modem (even if you don't have a speed tier that requires it, having the extra RF spectrum available is never a bad thing) and connect pfSense right to the modem. Request your /56 and go to town. Get your IPv4 address and set up Dynamic DNS to automatically update a hostname in your domain (so many Dynamic DNS services available!). Anything on the internet that needs to connect in, use the hostname instead of a static IP address.

And this is even if your IP address ever changes. I don't think I've actually had my IP address and /60 prefix (I'm a consumer customer, not business) change for months. It'll probably be a year in a couple more months.

14
General Questions / Re: Ransomware Detection Capability
« on: January 18, 2018, 09:02:32 pm »
User runs code - infected, all their stuff encrypted.. How does your blocking their C&C prevent that?
Usually before the encryption begins, there's a key exchange that takes place between the malware and the C&C server. If communication to the C&C server is blocked, then you can at least extend the amount of time to remove the malware before it finds a way around the block.

15
General Questions / Re: Is DMZ supported in pfSense firewall?
« on: January 18, 2018, 08:57:12 pm »
If you want the servers in your DMZ to be accessible via IPv4, yes, you do.  If you have IPv6 available and you're happy with your DMZ devices being only accessible through IPv6 (assuming they support it), then there's no requirement that you create IPv4 port forwards.

Pages: [1] 2 3 4 5 ... 39