[SOLVED]18.1 will not route to some sites and services, 17.x works fine.

[dcol]

Referring to the previous post,
And here are more examples of default deny rules that have a matching pass rule.
How can I tell if these are legit or just fragmentation?
Added a cloned LAN2 sloppy rule.

How do I get rid of fragmented packets in the logs? Or do I even need to. They seem to appear mostly after a reboot and slowly disappear after a while.

[Davesworld]

I noticed that they seem to fade out after a time. I am watching the live view. This of course seems to be totally unrelated to my problem that I started this thread with. I've been following GIT to watch the changes.

[dcol]

That's fragmentation which eventually goes away, mostly.
That's why I want to see flags in the firewall view.

[Davesworld]

I had a chance to do a traceroute to the same IP  as I showed before as well as a different one to another streaming service with 17.7.12, 18.1.2_2 as well as a firewall running IPCop, they time out about the same, the only difference is that OPNsense waited a lot longer before completely timing out and returning to the command prompt. The IPCop firewall is on a different ADSL connection but the same ISP CO and all that. This was just chasing a ghost however even tracerouting to both firewalls using yahoo.com times out after 10 steps followed by rows of double asterisks. Google makes it to 8 hops and finishes properly so I think I'm finished with tracerouting for now.

17.7.12 still works well but 18.1.2_2 does not so this remains. I really like the live view in the firewall logs much better in 18.x though as it is cleaner and you can isolate to one ip and only watch that if wanted. I just got up and don't have a few cups of coffee in me yet.

[Davesworld]

I am running 18.1.3 which while much nicer to work with did not solve the problem nor is it creating it. I rebooted to the old 11.0 kernel and everything works fine. I began to wonder about the 11.1 kernel. It is completely usable for me with 18.1.x and the 11.0 kernel from 17.7. I marked it as semi-solved since at least I know where the problem actually is.

[Davesworld]

Enabling Sticky Outbound Nat seems to have fixed the problem.

[franco]

Also here for reference, can you try this patch instead? https://github.com/opnsense/core/commit/7a823c56a

# opnsense-patch 7a823c56a

All testing and feedback welcome.


Cheers,
Franco

[elektroinside]

I also applied the patch. All good here

[franco]

Should be a NOP for WANs with only a single IP. The question is if the folks with VIPs on WAN have a better life with this in place.


Cheers,
Franco

[dcol]

I have VIP's on one box with 3 external static IP's. Did an Android update via 5G WiFi and streamed a couple of Amazon movies via the Samsung TV app with no issues. Did not apply the patch yet. Should I? Willing to test anything you need

This box does not use any NAT 1:1 or PF rules to the LAN net. I like to avoid NAT 1:1 rules when possible. Has manual Outbound NAT rules with one auto created rule on the 192.168.1.1 LAN net.

[elektroinside]

Oh, ok. Reversed :d But it worked well anyway

[Davesworld]

I also applied the patch. All good here

Just tried the patch and disabled sticky NAT, streaming DirecTVnow steady as a rock. Like I stated on the git ticket, I'm going to flog this firewall this weekend, I'm optimistic that the patch fixed it.

[slickdakine]

Hi All,
I have a new opnsense install, just moved over from pfsense (4+ years). I found this thread and it looks like I maybe having some of the same problems.
I applied the above patch, but I'm still having issues. Setup is basic, with an openVPN client setup as a gateway. Whenever the openVPN client is active, DNS goes down, even on the lan side with local clients. I can still ping the ip addresses of local and external clients like 8.8.8.8.
I found if I made a firewall rule allowing local clients to send DNS packets to the firewall, it will resolve the names. But there are still almost random requests being denied with "default deny rule".
Anyone else having these issues?
They are only present when I have the openVPN client active.
When I deactivate it, everything works as normal.
Check the attached photos for an idea of what it looks like.
Appreciate any ideas or help any of you may have.
Thanks!

PS-love what you guys are doing with opnsense, was frustrated with the last pfsense 2.4 release, the web GUI is horrible.

[slickdakine]

Here are the other two photos of my setup:

[franco]

Does not look like the problem described previously, which was addressed in a patch that is queued up for inclusion in 18.1.6.

Default deny usually means state tracking was too aggressive, which could be the case due to retransmits, switch gear, network loops, asymmetric traffic, etc. You can try to set your OpenVPN gateway rule to "slopply" or "none" state tracking and see if that helps.


Cheers,
Franco