@Hangnail6119 Ok few updates that I found out after digging a lot more. In the S2S config pfsense uses transit network IP address so if you have a tunnel as in the video 10.100.90.0/31 that means your sites when sending requests to other end will use that tunnel ips: 10.100.90.0 and 10.100.90.1 Firewall that is asked for a DNS record needs to have Access Lists record for the tunnel. Otherwise it will just refuse those requests. You don't need to add other firewall as DNS server you just need to define Domain override. With that knowledge how would my example work: I have 2 sites connected with a tunnel: 10.100.90.0/31 SITE_1 with IP: 10.100.90.0 SITE_2 with IP: 10.100.90.1 SITE_1 has some servers under domain example.com and SITE_2 wants to access them SITE_1 has host overrides for single servises under Services > DNS Resolver > Host Overrides for example: git.example.com points at some internal IP and SITE_2 will want to access that SITE_1 will need to have Access List added for tunnel network Services > DNS Resolver > Access List > +Add and there tunnel network specified 10.100.90.0/31 SITE_! will also need a rule that allows it to recive DNS requests from other end of the tunnel, The simple rule ALLOW src:* dst:This Firewall(53) on S2S interface should be enough AFAIK(at least it works for me :P) Now the only thing that SITE_2 needs to do is add Domain override. It's located under: Services > DNS Resolver > Domain Overrides and it needs 2 things example.com domain and IP address of SITE_1 that would be 10.100.90.0 And that was my problem, now everything works.

@weyon668 here is what I would suggest you do then. Your stuff your trying to get to is on your lan network? You can ping your pfsense lan IP.. Ok now sniff on your lan interface for icmp and your destination IP.. Do you see the ping go on? If so and you get no answer, then the device your pinging is not answering, or he is sending the answer to something other than pfsense.. Here I connected to my openvpn on my phone via a cell connection - and pinging my nas.. [image: 1714080234857-vpn.jpg] That 10.0.8.2 is my phone, you can see it sends on the ping request, and in my setup my nas is answering.. Are you not seeing the ech request go out towards your devices IP your trying to ping?

@T5Y85DYSsJmA Is the wireguard tunnel itself up and running? What does / Status / Wireguard show, the tunnel should have a green up-arrow and the peer show a recent handshake having taken place.

No worries, more info is almost always better.

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. [image: SiolNr4]

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