@Wolfgangthegreat
...and to @comet424

I wasn't able to perform the 2.8.0 update this weekend, but when I got to the school this morning, it worked perfectly!

I appreciate the support from both of you, and from Netgate.

The backup/standby pfSense instance is back in place and ready in case I have a hardware failure, or a failure of the gray matter between my ears!

My best to all of you.

@ThePowerPig
So add an additional rule to allow access to internal subnets (best to create an RFC 1918 alias for this purpose), but at least for the IPs you want to access from the device in question, and move this rule up above of the policy routing rule.

@stephenw10 Confirmed fixed ty kindly sir.

@elvisimprsntr thanks for your suggestion. I will give it a try.

@stephenw10 Thanks for letting me know there were backend issue, I think it would be helpful if Netgate posted an announcement when there are issues, maybe some details, and an ETA to restore service.

It would save a little headache for some of us.

@stephenw10
Thanks again.
Well it is full of passwords and pre-shared keys and very detailed stuff but I guess we should find the culprit of it somehow.

I did find leftovers of lcdproc before, which I cleaned at some point.
That means that part of the config I am using was migrated from a modified WatchGuard I have used in the past.

Let me have a look tomorrow.
It's kind of late now in my timezone.
Thanks!

@70tas Indeed the global token does not work anymore, you must use the API token. And then for the login, do not use your email address. As I wrote before: "One must use the Zone ID when using the API token."

I have this working using the DDNS GUI. I only needed the script for debugging.

@Qinn said in Feed issue on SWC:

Got a reply from Dan and here it is solved.

Thanks for feedback!

Good to hear.

@stephenw10 Correct. Way longer than the tunnel rekey times, so something must prompt a configuration reload outside of that.
Or maybe the tunnel went down at some point and the config was reloaded when a reconnect was attempted.

Because 10.60.0.252 is the server end of the VPN tunnel at pfSense. The local DNS resolver (Unbound) listens and responds on that IP and that is where the override is set.

Where as 8.8.8.8 is Google's DNS service that knows nothing about any local overrides you might have set. When clients use that DNS server is bypasses any local DNS overrides.

@rasputinthegreatest well blocking and not log would just be any any udp to that ff0e::c address or port 1900 anything, etc. And don't have it log.

As to the scanners - that is a pfblocker alias I have.. And put that in a floating rule.

scandeny.jpg

I would agree. 18 hours in and everything continues to run smoothly. The issue related to image availability I believe is the valid answer and we can close this out as solved. Thanks everyone. -JD

@phthatcher said in SG-1100 as VPN client only (no dhcp) adding to existing network:

just assure that when the server reaches out to the web it is behind the vpn

So all you need is to configure pfSense as default gateway on the server.

The pfSense only needs a single interface (LAN, router-on-a-stick), connected to your LAN.
On the VPN interface you have to add an outbound NAT rule, as mentioned in the ExpressVPN tutorial.

@greatbush You have to route somewhere.. In my mind that appears like your switch "a" is in place to do that.

Otherwise the pfsense box has to have a VLAN set up on the LAN interface that is connected to switch A so that it knows that subnet is there to route.

Share your LAN settings of your pfsense box. All of them that are related. The forum crystal ball is broken.

Screenshots are best.

@stephenw10 i have same issue

You can set the size it rotates at and the number of files to retain in the log settings at Status > Logs > Settings. As long as you have the space you should be able to increase it.

@stephenw10 said in Gateway monitoring still not OK:

I would still expect to have seen dpinger try to ping and show loss rather than pending.

/etc/inc/gwlb.inc:

// dpinger returns '<gwname> 0 0 0' when queried directly after it starts. // while a latency of 0 and a loss of 0 would be perfect, in a real world it doesnt happen. // or does it, anyone? if so we must 'detect' the initialization period differently..

@lbeard said in Dynamic dns don't work with carp ip:

Done => https://redmine.pfsense.org/issues/16326

Great, thanks 👍 👍