From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail02.haj.ipfire.org (localhost [127.0.0.1]) by mail02.haj.ipfire.org (Postfix) with ESMTP id 4b273M6MKTz32pF for ; Tue, 20 May 2025 21:29:03 +0000 (UTC) Received: from mail01.ipfire.org (mail01.haj.ipfire.org [172.28.1.202]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (secp384r1) client-signature RSA-PSS (4096 bits)) (Client CN "mail01.haj.ipfire.org", Issuer "R10" (verified OK)) by mail02.haj.ipfire.org (Postfix) with ESMTPS id 4b273J36lmz30Hh for ; Tue, 20 May 2025 21:29:00 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mail01.ipfire.org (Postfix) with ESMTPSA id 4b273H6pCSzC6 for ; Tue, 20 May 2025 21:28:59 +0000 (UTC) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003ed25519; t=1747776540; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=jTgJGOZL80N7Zjl3ao9ZAgKapKb6ayEIezFGa9pZ+TI=; b=l7vv58+Qe0EDG7PqeJEnVfHPYyRpo2B5tOGaBwFSZWIV+dkkmASCrYGMyIwCiqN3NsWnbO XnsI80rbUJ7GL5CQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003rsa; t=1747776540; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=jTgJGOZL80N7Zjl3ao9ZAgKapKb6ayEIezFGa9pZ+TI=; b=W0vUkOXz4fz6MApu/gUWoDrLSQFCdFb0Sjdw/6TmBLl4gVL68qyeVRZWcXipyS0nhrZdqP CkNLGhMAzdNQsGk3vSjw+zxydeyzg+cexkdyYaXDtaDtdNvvreZ9YwN4n9sb/9CfJBjn3k ZA8F8CW8H7owEpJW7xwg1u78lEncwzzSvbwWQRj8cXicfZrCWxeh+glhhK6Bkgj2zbrBCg SyvaJX9uqZS6wsA5scZlF9X3so0W8mrfMJ/SXjKLtYJAhjtknMgpF3ZrmF06UG8JpNrG/z JhRRrrF1pwz22qK0wrF1jipAEmydV/F67LLf4gWmoO+9SmroWsAKRNWUTo8W3g== Precedence: list List-Id: List-Subscribe: , List-Unsubscribe: , List-Post: List-Help: Sender: Mail-Followup-To: MIME-Version: 1.0 Date: Tue, 20 May 2025 22:28:59 +0100 From: Adam Gibbons To: Development Subject: CU195 Testing - WireGuard IPS ramblings Message-ID: <6bef4edafe9cc9423a3a702a06ba4561@ipfire.org> X-Sender: adam.gibbons@ipfire.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hi all, Recently I’ve been keeping myself busy testing the newly released CU195 testing build, which includes WireGuard support (insert ITS_ABOUT_TIME emoji here). Today I wanted to test if the IPS was actually inspecting and blocking traffic on the newly added interface. I thought I’d share my testing approach and findings, in case it’s useful, interesting to anyone else, or for documentation. Test Methodology: - Set up a Fedora VM, connected to IPFire via WireGuard as a Host-To-Net peer (roadwarrior). - Enabled IPS only on the WireGuard interface (disabled on RED and GREEN etc). - To check if Suricata was properly inspecting traffic inside the tunnel, I looked for a rule that would be safe and easy to trigger on purpose. I settled on this rule: GPL MISC source port 53 to <1024 (sid:2100504) https://threatintel.proofpoint.com/sid/2100504 I picked this because it’s straightforward to match, unlikely to cause noise or false positives, and works well for a basic end-to-end test. How I triggered the rule: From the Fedora VM (192.168.26.5), I used hping3 to send a SYN packet with source port 53 to IPFire’s external IP on port 80: hping3 -S -p 80 -s 53 This created exactly the traffic the rule is looking for. Result: The alert appeared in Suricata’s log: Date: 05/20 21:43:21 Name: GPL MISC source port 53 to <1024 Priority: 2 Type: Potentially Bad Traffic IP info: 192.168.26.5:53 -> :80 SID: 2100504 This test confirms IPS is inspecting WireGuard tunnel traffic as intended in CU195. Bug reports are great, but it's better when something just works. Cheers, Adam