crashing opnsense 23.1.7_3-amd64 with ping6

Started by 9axqe, May 17, 2023, 09:44:15 AM

Previous topic - Next topic
Sure thing. This sense is not "productive" yet (this is for a home office, nothing enterprise-level), I still struggle with some MTU/MSS/segmentation issue which are killing my throughput (I'll start a new thread on that in a while), so I can try a patch, no problem.

And THANKS btw, really amazing work you guys do.

All in a days work for bicycle repair man ;)

https://github.com/opnsense/src/commit/1107d69ba909

# opnsense-update -zkr 23.1.6-refragment2


Cheers,
Franco

May 18, 2023, 12:58:44 PM #17 Last Edit: May 18, 2023, 01:02:15 PM by 9axqe
Seems it's working but somehow something with my DNS setup (adguard + unbound) is not working anymore now. Not sure it's related but I can't access the adguard web GUI, which is running on 443 (while opnsense web intf is on another port and is still reachable) and unbound is not starting anymore. I need to look into this.

uname -a returns:

13.1-RELEASE-p7 FreeBSD 13.1-RELEASE-p7 refragment-n250431-1107d69ba90 SMP amd64

"Shared forwarding" is enabled.
IMCP ping and pin6 are routed to gateways, which send traffic to wireguard tunnel
WAN MTU is current set to 1280 bytes

ping6 sweep is successful until 1160 bytes:


sudo ping6 -G 1508,1150 -D 2606:4700:4700::1111
PING6(40+8+[1150...1508] bytes) 2a02:8106:65:84f0:d4bb:7c6a:d30c:3d80 --> 2606:4700:4700::1111
1158 bytes from 2606:4700:4700::1111, icmp_seq=0 hlim=63 time=39.252 ms
1159 bytes from 2606:4700:4700::1111, icmp_seq=1 hlim=63 time=37.917 ms
1160 bytes from 2606:4700:4700::1111, icmp_seq=2 hlim=63 time=34.886 ms
^C


ping is successful up to 1180 bytes:


ping -D -s 1172 quad9.com
PING quad9.com (216.21.3.77): 1172 data bytes
1180 bytes from 216.21.3.77: icmp_seq=0 ttl=49 time=219.187 ms


I don't get how these numbers relate to the MTU value I configured on the interface though.

But AdGuard 443 is running locally? You can verify from https://your.fw/ui/diagnostics/portprobe

The other question is if you try to access remotely or from a locally attached LAN?


Cheers,
Franco

yes adguard is running locally.

opnsense can connect to itself on port 443 weirdly, I just cannot in the browser:


Connection to 192.168.1.1 443 port [tcp/https] succeeded!


packet capture shows TCP SYN incoming from computer on port 443, and TCP RST sent back, that's it...

Maybe not going through the tunnel on the other end? TCP RST might also be a firewall action taken.


Cheers,
Franco

Something is wrong, even uninstalling and reinstalling the plugin, which should make it available on port 3000 again, does not work.

I'd like to double check if the patch has nothing to do with it – I doubt it, but just to be sure.

Which command would allow me to revert to 23.1.7_3?

Ignore, I found the root cause, my fw rule to block DoH is somehow blocking local access to adguard locally running on opnsense port 3000 – I don't really understand how that's possible, since I can access opnsense web gui on a different port on the same IP and from the same PC just fine. I just disabled it and suddenly I can access Adguard. Weird. It's based on a URL containing a large list of public DoH providers, maybe there's a typo in it, but it still does not explain how it blocks a single port...