So, in the past we did everything right.
Thank you.

Thanks, this fix definitely worked and I can confirm this is the problem with my setup, has anyone already tried to implement a patch or a script to run on startup to fix this? New to the PfSense project and a big fan of wireguard, is there a github/ gitlab where we can submit issues/ fixes for this? [EDIT: disregard, it seems that the tunnel reset corrected the issue initially, although follow up attempts have been met with a working handshake but no flowing traffic, Might be easier to move to another VPN protocol at this stage]

Spent some time on this over the weekend and quite happy with the results. ;)

Anyone try it from a Starlink fed site yet? I will get the chance to try in the coming weeks.

@Jarhead -Thanks for hint.

Correct-OPT4 is on ....3.100/24 and LAN is on .....1.100/24.
I went to Firewall-NAT-Outbound, changed Outbound NAT Mode from Manual Outbound NAT to Automatic Outbound NAT. pfsense added 2 rules in which a WireGuard Interface takes OPT4 address space as source. (along with LAN address space).

Quick and easy. Maybe adding manual rules is a next part of learning curve.

Debian is radius server, several pfSenses with their captive portals are clients.

@Jarhead
Yeah. I get it. I've read some conflicting info while researching this along with some videos that contradicted some of what I saw. I've gone down so many rabbit holes that I lost track of what I had and had not tried.

That and not noticing my typo (32 vs 24) didn't help.

But thanks.

This is what the android client looks like when it try to enable split tunnel configuration. It refuses to connect.
split tunnel configuration

I got it resolved. I have a bit of an unusual situation. The modem provided by my ISP has a built-in router which I don't want to use. I had originally planned to downgrade it to pass-through mode (so it would only function as a modem). I had the ISP make the change for me as they are the only ones who can do so.

But no matter what I did, pfSense refused to connect to the internet that way. So I had them put it back the way it was. pfSense uses it as the gateway but it sees the ip address assigned to in internally as its "public IP address".

Dynamic DNS still works because we're making external calls to update the DDNS and the remote DDNS server knows the external IP address.

It's been running like this for more than a year without a hiccup. Anyway -- I had to login to the ISP router and tell it to forward port 51820 to the pfSense router. As soon as I did that, my phone was able to connect without a hitch and access my home assistant server via the VPN (I turned off WiFi on my phone for the test).

@cjbujold Yes

@Bob-Dig
No. I can ping out though on a shell on my netgate (freebsd uses ICMP for pings unlike cisco routers which are udp)

and can specify no fragment with up to 1472:

ping -D -t 1 -s 1472 10.2.0.1 PING 10.2.0.1 (10.2.0.1): 1472 data bytes 1480 bytes from 10.2.0.1: icmp_seq=0 ttl=64 time=148.918 ms --- 10.2.0.1 ping statistics --- 1 packets transmitted, 1 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 148.918/148.918/148.918/0.000 ms

Where then trying at 1473 I get ping: sendto: Message too long
The pings that do work, now show up in packet captures on that WG interface.
So pretty sure MTU/MSS cant be the problem

Whats really bizarre though is if I set my squids outgoing interface back to the cyberghost one, then squid clients going to ipinfo show an italian IP address as expected. But then if I set squids outgoing interface to the new WG tunnel interface then squid clients that use ipinfo return the local ISP WAN IP address.

@rprengel said in ping works fine in both directions but http / ssh from remote to intern fails:

@viragomann said in ping works fine in both directions but http / ssh from remote to intern fails:

@rprengel said in ping works fine in both directions but http / ssh from remote to intern fails:

No obvious blocker / filter /firewlls are active.

I was expecting this view. That's why I suggested to sniff the traffic to see, what's going on in fact.

I found a youtube video with some hints that a NAT may be necessary on the pfsene because of the fritzbox allthough ping is working.

Yes, NAT is a hack to circumvent firewall restrictions. But it's rather recommended to configure the firewalls properly instead of doing hacks.
It's a workaround to enable access to devices from outside, which have no default gateway setting.

Hallo,
found the problem but not solved.
I can reach system from „outside“ using ssh on port 22 and http using non default ports.
I tested the last days only trying to reach a default webserver.
It looks like ports 80 and 443 are the problem. Maybe the anti-lockout rule?
Ralf

Now solved:
After I realized that ssh from outside worked too I tried another webserver. This one worked immediately.
The first web-target was the interface of a printer that obviously didn t deliver its contect in external lans.
Ralf

Finally!

The solution was creating a firewall rule that route the traffic of my Bridge interface through the gateway i have created for the wireguard client.

@viragomann RESOLVED, thank you

I followed your recommendations and found this issue in the logs:
Mar 23 12:50:30 WAN1 Default deny rule IPv4 (1000000103)

I added a new rule (separate from my alias based port allow rule) and boom, I'm working. I also found that my WG port allow alias rule was set to TCP (the other 2 6100 are UDP), I wonder how long that has been like that and why my tunnels were working so well all this time lol

It turned out the traffic is reaching the rev proxy, but for some reason the packet is broken (maybe?)
Attaching a pcap from the proxy cap.pcap

@dimsum said in cannot reached to local network from another site when enabled failover:

I have checked the system log and the policy was passed

For sure, the traffic was passed, since your rule allow any to any. But the packets are directed to the gateway you've stated in the rule. Hence it can never reach the remote site.