Ok testing here....

There were some threads discussing it. For example: https://forum.netgate.com/topic/187100/serious

Nope that rule would not have allowed an outbound connection. But none of those prevent inbound connections and once the state is open the replies can use that.

However that would require something allowing inbound connection to reach the pfSense VM. So a port forward on the ISP router and another port forward on the pfSense VM to reach the server.

You don't have those as far as I know so if you were able to browse the site hosted on the server coming from some external IP address then the connection must have been coming over the tunnel to Cloudflare. That tunnel must have been created outbound from the server when you had a rule to allow it at some point. I would bet that if you had rebooted the server or pfSense at that point the connection would have failed.

@AlexDesro18 said in TLS Error, reconnecting:

Wan interface it says it's missing rules.

Do you see something like this on your wan?

rulesjpg.jpg

The "wan" needs no rules, but it defaults to having block rfc and bogon.. But maybe he removed those?

rules.jpg

The rfc and bogon are the only rules that would be on your "wan" unless you add something.

I ended up figuring it out by a couple of things. I don't know why the UI was saying up to date, but after running some of the commands and I set the default gateway for the "temp" WAN connection, then the commands started working and the UI started saying update available.

There was some kind of connectivity issue resolving the DNS for the repo's and I don't know why hard setting the default gateway made it work, but thats what happened.

I was able to update to the newest version and the pkg commands work again. Thanks for the consult.

If you need to run HAProxy and pfBlockerNG though I would want a 4200.

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!

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).

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

@edgewater Ugh, that sounds like the tech made more than one mistake. ;)

Had one once replace a modem, leave, then we find out only one IP out of 5 is working. And, AND, the model of modem that actually supports multiple static IPs was no longer available. The new one "has problems with that." After a couple days they tracked down one more old model in a truck, and installed that.

@stephenw10 said in Change Authentication Server from CLI:

authmode

I mens authentification to WUI.. Perfect, i was exactly looking fot that...
Thank you!

Yes, and I assume that is the case here. But in addition there were values for client identifier that tripped up Kea that ISC just allowed.

There is /etc/services (on freebsd and most linux) where port/protocol are mapped to service names.

Wow!!
Thank you guys!
That answers my questions...have windows installed on the backup computer and will install the new 4 port network card as soon as it arrives and dockument mac: addresses etc...

Thanks again!

bookie56

Ah great. Yes it was exiting out of the entire upgrade process on any error at that point before. It doesn't actually need to create a new uefi boot entry there so should be fine.
Interesting that Coreboot doesn't play nice with efibootmgr though.