@michael2z said in Upgrading a Netgate 5100:

Has anyone succeeded in upgrading a Netgate 5100 to the latest pfsense version. Any do's and don't's appreciated.

I have a Netgate SG-5100 device. I maintain it on the most recent pfSense Plus versions as they are released, so I'm never more than 1 version behind. I just click the Upgrade button and let it go. I have no optional packages installed. Generally takes about 5 - 7 minutes if I recall for an upgrade.

@aGeekhere Okay, so the real trouble is actually because of the few clients that you want to bypass the DNS filtering done by 1.1.1.3/1.0.0.3

1: Unbound DNS in pfsense by default does caching of all DNS lookups as TTL records allows. This is the same caching as Lancache does unless you start configuring some out of spec extra caching (of invalid records). If that is your reason to keep lancache in the loop configure Unbound to do the same (out of spec) caching of stale records - it can be done in the advanced settings.

2: Configure Unbound in pfSense to use forwarding instead of the default root recursive resolution. Then Unbound will do all lookups by forwarding to the DNS servers in "SYSTEM -> GENERAL -> DNS Servers"
It will still cache all records, so just hand the clients your pfSense DNS and drop the lancache server.

Using forwarding mode prevents us from exempting specific clients from being DNS filtered pr. the forwarding servers filters. So to have a few clients NOT being filtered things become a little more troublesome. For this you could:

1: Keep the lancache servers for those clients - make a DHCP reservation with a DNS override to hand them the lancache server as the only DNS
2: Configure Lancache to use your preferred public DNS as forwarding servers (1.1.1.1/1.0.0.1).
3: Create a stubzone on Lancache for you internal domain name for clients (the domain name used for your overrides in pfSense), and point that stubzone to forward to pfSense instead of 1.1.1.1/1.0.0.1

This will create the scenario you are looking for.

Just add the following line to your DNS Resolver Custom options:

local-zone: "duckduckgo.com" redirect

7122c48a-ec9a-4c84-891f-223556326f35-image.png

@GuillaumeJ
Try to follow the steps mentioned in their official guide for pfSense:

Proton VPN over pfSense

Regarding your question:

Once you are in NAT > Outbound, you should go to the tab:

Manual Outbound NAT rule generation.
(AON - Advanced Outbound NAT)

here you should see the automatic rules created.

Actually I have Proton VPN over pfSense working, although I'm getting some strange random issue I'm trying to investigate.

Hope it helps

@reberhar SUCCESS

After the latest upgrade for pfBlocker I started to have the same problems all over again and none of my other methods fixed it.

I finally got onsite and have learned some useful things.

First I have 2 Netgear GS108PEs, and one worked properly in this situation and the other did not. After thinking about it I realized that the one that functioned had 802.1q VLAN enabled. So I enabled 802.1q VLAN on the one that was not functioning correctly and the problem disappeared. No I didn't make any VLANs on the second unit, although the first unit I mentioned does have them. I just enabled 802.1q VLAN.

I reasoned that perhaps multicast was somehow involved in this. (duh) So I worked through enabling multicast on my Ubiquiti 24 port smart switch that had failed with this challenge earlier. It actually involved the Cloud Key as well.

This I did just on the two ports I am using for HA, not the entire switch.

That worked too and is still working.

😊

Yes I know, multicast is mentioned in the HA diagnostics write up. I guess I was just not following through. Actually, I was just a little unsure how to proceed. I have other very smart switches that have been testy in this pfBlockerng / HA environment. I am excited to try this approach with them.

The PHP error is a symptom of the configuration file being corrupted in some way. If I remember correctly, the corrupted configuration file is kept either in /tmp or /conf. If it exists, you can do a diff of the good and bad configuration file and post that here for review.

@Gertjan OK thanks, I didn't realize that the DNS name is tied to the pfSense user name used when connecting to the OpenVPN server.