Messages

I'm wondering if this might be related to the issues I've been seeing with Suricata 7:

https://forum.opnsense.org/index.php?topic=38989.0

For people who are having trouble with Wireguard since the 24.1.2 update, can you SSH into your OPNSense box and check /var/log/suricata/eve.json to see if Suricata is dropping your Wireguard traffic?

Use /usr/local/opnsense/service/templates/OPNsense/IDS/custom.yaml
This file makes the changes persistent across reboots and other Suricata config changes.

Thanks! I noticed that my changes to /usr/local/etc/suricata/custom.yaml were being reset when I made any other Suricata config changes, so I appreciate you pointing out how to make this persistent :)

I updated to 24.1.2 this morning and noticed that all clients on my network were no longer able to connect to off-site VPNs using Wireguard. After a lot of troubleshooting I determined that this was only happening when I used port 443 for Wireguard - switching to a different port immediately fixed everything. After some more investigation I found a bunch of entries like this in /var/log/suricata/eve.json:

Code Select Expand


{"timestamp":"2024-02-21T08:46:28.328325-0800","flow_id":1126978883909981,"in_iface":"igb1^","event_type":"drop","src_ip":"50.xxx.xxx.xxx","src_port":63309,"dest_ip":"142.xxx.xxx.xxx","dest_port":443,"proto":"UDP"
,"pkt_src":"wire/pcap","direction":"to_server","drop":{"len":109,"tos":0,"ttl":63,"ipid":3499,"udplen":89,"reason":"applayer error"}}

{"timestamp":"2024-02-21T08:46:28.329080-0800","flow_id":1131185437371657,"in_iface":"igb1^","event_type":"drop","src_ip":"50.xxx.xxx.xxx","src_port":35884,"dest_ip":"142.xxx.xxx.xxx","dest_port":443,"proto":"UDP"
,"pkt_src":"wire/pcap","direction":"to_server","drop":{"len":107,"tos":0,"ttl":63,"ipid":42478,"udplen":87,"reason":"applayer error"}}

{"timestamp":"2024-02-21T08:46:28.330264-0800","flow_id":1126978883909981,"in_iface":"igb1","event_type":"drop","src_ip":"142.xxx.xxx.xxx","src_port":443,"dest_ip":"50.xxx.xxx.xxx","dest_port":63309,"proto":"UDP",
"pkt_src":"wire/pcap","direction":"to_client","drop":{"len":1278,"tos":0,"ttl":57,"ipid":0,"udplen":1258,"reason":"flow drop"}}

{"timestamp":"2024-02-21T08:46:28.331800-0800","flow_id":1131185437371657,"in_iface":"igb1","event_type":"drop","src_ip":"142.xxx.xxx.xxx","src_port":443,"dest_ip":"50.xxx.xxx.xxx","dest_port":35884,"proto":"UDP",
"pkt_src":"wire/pcap","direction":"to_client","drop":{"len":1278,"tos":0,"ttl":57,"ipid":0,"udplen":1258,"reason":"flow drop"}}

{"timestamp":"2024-02-21T08:46:28.349475-0800","flow_id":1219019499694066,"in_iface":"igb1^","event_type":"drop","src_ip":"50.xxx.xxx.xxx","src_port":49147,"dest_ip":"172.xxx.xxx.xxx","dest_port":443,"proto":"UDP"
,"pkt_src":"wire/pcap","direction":"to_server","drop":{"len":109,"tos":0,"ttl":63,"ipid":19617,"udplen":89,"reason":"applayer error"}}

{"timestamp":"2024-02-21T08:46:28.353369-0800","flow_id":1219019499694066,"in_iface":"igb1","event_type":"drop","src_ip":"172.xxx.xxx.xxx","src_port":443,"dest_ip":"50.xxx.xxx.xxx","dest_port":49147,"proto":"UDP",
"pkt_src":"wire/pcap","direction":"to_client","drop":{"len":1278,"tos":0,"ttl":57,"ipid":0,"udplen":1258,"reason":"flow drop"}}

{"timestamp":"2024-02-21T08:46:28.391428-0800","flow_id":1399075579550517,"in_iface":"igb1^","event_type":"drop","src_ip":"50.xxx.xxx.xxx","src_port":43720,"dest_ip":"142.xxx.xxx.xxx","dest_port":443,"proto":"UDP"
,"pkt_src":"wire/pcap","direction":"to_server","drop":{"len":101,"tos":0,"ttl":63,"ipid":25591,"udplen":81,"reason":"applayer error"}}

{"timestamp":"2024-02-21T08:46:28.397087-0800","flow_id":1399075579550517,"in_iface":"igb1","event_type":"drop","src_ip":"142.xxx.xxx.xxx","src_port":443,"dest_ip":"50.xxx.xxx.xxx","dest_port":43720,"proto":"UDP",
"pkt_src":"wire/pcap","direction":"to_client","drop":{"len":1278,"tos":128,"ttl":58,"ipid":0,"udplen":1258,"reason":"flow drop"}}


It looks like this is new behavior in Suricata 7 - whenever it encounters an exception while processing a packet it just drops the traffic (fail closed) instead of allowing it (fail open). This is mentioned in the Suricata forums here:

https://forum.suricata.io/t/my-traffic-gets-blocked-after-upgrading-to-suricata-7/3745

It's unclear to me why Wireguard traffic on port 443 is triggering these exceptions, but my best guess is that Suricata just assumes port 443 traffic is always HTTPS and throws an error when non-HTTPS traffic goes over that port.

For now I've manually added

Code Select Expand

exception-policy: ignore to my /usr/local/etc/suricata/custom.yaml, which restores the old behavior of failing open and allows my clients to connect to Wireguard servers on port 443.

I don't have a question or anything, I just wanted to make this post to hopefully save everyone else some time and frustration :)