That's what I would expect because the system routing table should be correct. Incoming traffic should always come from that route unless you have some route asymmetry somehow.

It's the port forwards (NAT) that allows traffic from a single source IP to arrive via any gateway.

Is the OpenVPN server configured to listen on 'any' interface?

If you can put a switch between igb2 and that PC? That would solve this.

However if you set OPT1 to track interface for IPv6 it will probably stop this happening. Even if you have no IPv6 on the WAN.

No solution yet as far as I know. Any progress here should be on the bug report.

@macaruchi said in Access from internet router to LAN:

No, it doesnt

So how would you expect pfsense to forward something that never gets to pfsense?

Either you don't have the forward setup correctly in the router in front of pfsense, or the traffic is never even getting to that router for it to forward.. You sure when you went to can you see me that the IP it sent the traffic too was the routers wan IP that you setup the forward to pfsense wan IP?

@stephenw10
That makes sense.
Thanks

@stephenw10 yup that is a very good viable option.

Or use that opt1 for your normal network, because the "lan" has the anti-lock out rule on it.

@stephenw10
Ok, I changed my hard drive. We’ll see!

There is no specific rule to block it. All unsolicited traffic is blocked inbound by default.

Traffic is scrubbed by default which prevents fragments passing but even if you disabled that most rules would not pass fragmented traffic because they cannot match without the header info.
See: https://man.freebsd.org/cgi/man.cgi?query=pf.conf#FRAGMENT_HANDLING

There's no way to actively pass fragments from the GUI, there is no fragment option on user rules.

@planedrop said in Will pensense join vpp/dpdk:

@NollipfSense I am guessing a typo, though that might be a difficult one to do....

LMAO...

It's defiantly Home Assistant. I assume deleting the integration didn't completely get rid of everything. I'll have to do some poking around and see if I can find out how to disable whatever is left.

Commonly it's because there are no iroutes to allow the OpenVPN server to know which subnets exist behind which clients. Those are not required in a shared key setup because it can only ever be point-to-point.

https://docs.netgate.com/pfsense/en/latest/recipes/openvpn-s2s-tls.html#create-client-specific-overrides

Steve

@stephenw10 That's great, thank you. I'll get that done

The error is still misleading. Try removing a package at the command line:

pkg-static remove pfSense-pkg-Open-VM-Tools

Steve

Hmm, then there should be no problem with them using the primary IP in the 10.10.0X subnet as long as it' not the CARP VIP.

Do you not see states at all on the other nodes?

@Gertjan

that's what i have done sunday! i was surprised that it didn't worked, but i saw the cable was still in the yellow of port of the netgear....i put it in the right port and everything goes well!

@walidbz said in Unable to check for updates from dashboard:

i install from : https://pkg.pfsense.org/pfSense_v2_7_0_amd64-core

That isn't where you're installing from. Neither wazuh-agent nor pkg-1.20.6 are in that repo.

Also if you have pkg-1.19.1_2 installed you would not need to run pkg-static:

[2.7.0-RELEASE][admin@pfsense.fire.box]/root: pkg search wazuh-agent [2.7.0-RELEASE][admin@pfsense.fire.box]/root:

What repo do you see in?: pkg-static -d update
What version do you in? :pkg-static info pkg

Just to clear you should restore the complete modified config. The rules section will reference a different set of interfaces so will not line up otherwise.

@RobbieTT said in Tunning after half a gig:

I know, you are stuck on G.fast

The struggle is real!

But, yes, multiqueue PPPoE sure would be nice.

Yes, generally I'd rather use VLANs with a managed switch than a USB adapter. Though Realtek NICs can also be problematic. But not always.

Steve

@NogBadTheBad Thanks? I added IPsec as was previously not using...

Still - no change re: original issue:

iOS device over wifi (Unifi AP) using 2FA: can NOT authenticate Diagnostic > Authentication: The same user authenticates using 2FA Log reports as listed in thread title