When I run pkg-static upgrade, I get errors about unable to fetch package and error updating repositories.

It's so weird (and annoying). Everything was working, and then I removed the firewall rule, so actually opened everything, and now nothing works - the tunnel stopped working and I can't even ping to the WAN anymore, and can't do sudo apt-get update.

How?! I removed the firewall rule, then how it did the opposite?

Last time it happened, I switched from DNS resolver to DNS forwarder and it started working. But now - the DNS forwarder is still the one enabled. so now I'm lost as to what happened.

Edit: I now created a "pass" rule for Any/Any and I can ping to the WAN again. However, DNS still doesn't work again.

Urgh. Well nice to actually find the issue at least. Were all three devices using the same NIC type, all Realtek NICs?

The reset is at 5:55. Here is the system log starting at 4:00:
log.txt

@Gertjan
My acl's are exactly the same.

Hello @stephenw10

Thank you for you reply. Finally, we solved issue.

Phase 1 disabled was in Ikve1 config mode and VPN IPsec status blocked on Connecting message indicated ikve2

So we reenabled Phase1 with ikve2 + we force disconnect Phase 1 from vpn status and now it's oks

Best Regards

@VioletDragon
MTU is blank on all interfaces, so I assume default / 1500
In so far as I understand OSI, its all Layer 3. Its all firewall rules, no ethernet rules.
No I haven't tried a fresh install. I guess I should do that.

@kjk54 said in Best Network Topology with Current Hardware:

@stevencavanagh
Things are often not what they seem.:)

Very true!

What status where? You have a screenshot? Copy/Paste the output?

Steve

@cyberstudentnewbie The class I took they covered many different topics. We covered different vendor firewalls and we also covered base Linux topics like iptables all the way to Windows Server firewall settings, as well as pfSense all the way to PaloAlto major releases. Or school had student versions that PaloAlto had for us. After that we used pen testing software within the ethical hacking class to break into the equipment (I took both classes at the same time). Those classes will really help you get your foundational knowledge built. After I purchased an official pfSense firewall just to learn more with it is a puzzle. I am sure you know not many firewall tools are available for cyber security students to learn and work with like this. pfSense fits that need as it's opensource and it comes with an enterprise class web cache proxy if you really want to push yourself. Again, its proxy configuration is really complex, it's no joke with the need for certificate use and everything that needs to be configured for it to work. I purchased my official Netgate appliance while taking the ethical hacking class so I could really learn with it we even we used pfSense in the finals the instructor had it all set up for us to configure with. I was really happy that I got a grant that paid for my 2100-MAX, I thought it's what's needed for me to advance my knowledge. Keep in mind, because it is open source, I am still learning stuff with it, I am a computer science student, so I am now playing with the code on it. I cannot wait until I get my C+ class done, I have only learned Python, Java and Assembly code so far. I really need to take that C+ class so I can really get into the code for it. The tools really advance the direction of cyber security.

When I was younger, back in the 2000's taking classes Cisco Mars and Cisco Pix products where the major player in cyber security. Again, not many tools were available to study with, you could never take an appliance home with to research and study on with unless you had thousands and thousands of dollars. So Netgate really fits the need today, it was my cyber security go to tool.

This community also is so helpful if you get stuck.

I recommend you start off with ports and access control lists on it and after start learning about packages as you gain more knowledge. The TPC/UDP ports IP Classes and address with access control lists were what firewalls were back in the 2000s. We didn't even have a GUI back then just Cisco's global config mode command line.

Don't give up and do not be afraid to use office hours, the professors want to help you they are paid to help you, so use the office hours they set aside when you get stuck also.

Similarly for me

Are you running the 3rd party e2guardian package?

Did you upgrade from 2.6?

I've never tested that package because it's unsupported but I don't think it will run in the current pfSense version.

Steve

Yes it's possible. It's quite a complex setup. It can be difficult to setup a virtualised firewall like that and have everything boot correctly in the event of a power outage for example.

Steve

@viragomann said in Using LetsEncrypt Certificate for Web Configurator Authentication:

I don't believe, that Lets Encrypt has signed a certificate for 192.168.1.1.

They expressly state in their User manual that they only use domain names, and NOT IP addresses.

@pslinn said in Using LetsEncrypt Certificate for Web Configurator Authentication:

Once changes are saved I log out of the pfsense system and type in the url:
https://192.168.1.1:443

You all work, and you missed the most important reason why you were asking for a certificate :
So you don't have to use htpp://192.168.1.1 anymore, but now you can use :

241d7ea4-e72e-4cba-8518-19f1669d2a34-image.png

https://pfSense.some-domain-name-that-you-rent.tld

and yes, "some-domain-name-that-you-rent.tld" is a domain name that you have to rent.
Letsencrypt does just one thing : they will test taht you 'own' (= control) that domain name.

@pslinn said in Using LetsEncrypt Certificate for Web Configurator Authentication:

went to dns resolver
under General Settings went to Host Overrides
selected Add and typed in the requested contents including alias'.

You don't have to do this.
If you asked letsencrypt to create this cert for you :
pfSense.some-domain-name-that-you-rent.tld
and because pfSense already has "pfSense.some-domain-name-that-you-rent.tld" loaded into the DNS (point to 192.168.1.1)

...
edit : do not believe me !!
Go check yourself, using your equipment :

nslookup pfSense.some-domain-name-that-you-rent.tld

the answer will be :

192.168.1.1

....
So your browser (PC) can resolve "pfSense.some-domain-name-that-you-rent.tld" as pfSense has the answer (and yes, 8.8.8.8 has not !! (of course))
So the browser can nw connect to the resolved domain name = "192.168.1.1"
So the pfSense GUI, connected over https (using port 443) will hand over a certificate to the browser stating that this certificate belongs to "pfSense.some-domain-name-that-you-rent.tld"
And that is just great : the browser was initially using "pfSense.some-domain-name-that-you-rent.tld", got 192.1368.1.1 as the address where the server can be found, got a cert back from this web server that it is "pfSense.some-domain-name-that-you-rent.tld" => this is what https is all about. Nothing more, nothing less.
Oh, yes, now everybody knows who is who, some random numbers can be exchanged securely so the entire traffic can also be encrypted decrypted on both side so the traffic passes over the 'possible hostile network on a secured way, and can not be altered while going over the wire.

Btw : if you ask for a wild card certicate like
"some-domain-name-that-you-rent.tld"
"*.some-domain-name-that-you-rent.tld"

( this means : the top level domain name "some-domain-name-that-you-rent.tld"
and
all the sub domains "*.some-domain-name-that-you-rent.tld" )

you can now use your certificate for
pfsense.some-domain-name-that-you-rent.tld
printer.some-domain-name-that-you-rent.tld
nas.some-domain-name-that-you-rent.tld

when you've installed the certificate on your printer, nas etc.
Now you can use "https" to access all these devices (if they support it).

An update after further testing, details below:
After getting the unencrypted TCP working reliably, I wanted to verify the SSL with LDAPS and noticed that the SSL auth was randomly failing with the same bind error. I could not fix this one no matter what I tried and eventually it started failing all the LDAPS binds.
Everything works fine with LDP and Apache Directory Studio but for some reason pfSense just does not want to work with SSL.
I use LE certs on my server and in theory the LE CA should work since it is working in every other application like LDP and Apache Directory Studio.
The only major change to pfsense was the updated OpenSSL package. Might it be possible that this is the reason? If anyone can confirm that I would be happy to open a bug report but I don't want to waste anyone's time over there if this is a configuration mistake on my part.
Packet capture shows TLS 1.3 auth

@marnog
HA proxy supports FastOpen but not sure if this fits into your design. Up to you.