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

@charneval As far as user access goes,
8d03fff1-5a86-4a27-81f3-426dc83f8837-image.png
or...
ef108509-04ea-449a-8c89-d57fd2589544-image.png
730f3484-0060-4877-94bf-7dbce9cbe34b-image.png
Univention Directory Server is an AD replacement, Windows client-ready LDAP server (pretty amazing).

@droidus Please provide more information. Your problem is DNS related, though.

@tibere86 When your coming through a vpn and wanting to talk to something on a network attached to pfsense you can run into a few different problems. Prob the most common is just firewall on the host doesn't like whatever the vpn clients IP is, in your case some 172.16 address.. Since its not local network to who your talking to.. Another issue is what your trying to talk to from the vpn is not using pfsense as their gateway.. So if they allow X to talk to them, they send it to some other gateway other than pfsense. Another is the device your talking to has no gateway at all..

Doing an outbound nat is sure a way to work around those issues.

I would validate that pfsense is sending on the traffic.. Do a sniff on your lan interface while you send a ping to your pihole, do you see pfsense send on the traffic? If so then you should check pihole firewall allowing what you want to allow. Or if you can ping, its maybe just a acl on pihole.

There is a setting in pihole. Which is default I do believe..

pihole.jpg

That would not answer some query from some 172.16 address when its local address is a 10.0.0 because that is not its local network.

Just chiming in that this has already been reported https://forum.netgate.com/topic/183141/wireguard-status-shows-last-handshake-1-years-11-months-ago

And I think the issue is not because of the leap year, but rather certain end-of-month days. It's happened to my firewalls before (during 2023 and 2024) but not every month. When it happens, it's usually the last few hours of the day.

Thank you so much!

I created an Interface for the WG tunnel
set a Gateway to WG peer address via this Interface
and created a static route to opposite
network through this new GW.

It is working fine now!

@Bob-Dig Thanks !!!

After some research on policy based routing, I managed to give Internet access to a vm on my LAN using this tutorial as inspiration : https://protonvpn.com/support/pfsense-wireguard/

now I'll try to configure haproxy to expose the services of the vm on my lan !