Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - Noci

Pages1 2
#1
25.7, 25.10 Series / Re: wireguard not passing traffic?
October 28, 2025, 08:58:32 PM
The issue always was on the OpnSense router, all phones, tablets and a mobile WiFi router were unable to communicate.
The Phone OS's are: GrapheneOS, tablets are Samsung & GrapheneOS, router uses OpenWRT.

On the OpnSense router regularly restarting wireguard fixes that.  (it causes other issues,,,,) so not perfect.
The cause is related to somehow the routes through the tunnels get dropped / packets are sent to the WAN interfase WITHOUT NAT.
#2
25.7, 25.10 Series / Re: how to allow for TCPTRACEROUTE....
September 19, 2025, 09:50:31 AM
The SOURCE NAT, ... SHOULD NOT HAPPEN.
As the Source NAT will hide the actual response.
It is not explicitly configured for source NAT on the LAN interface.
There are source NATs in the system,, those are all constrained to the source ranges (except for traffic leaving the WAN interface for IPv4, those are the automatic rules)

There are other NAT issues with OpnSense 25.7, Wireguard traffic does NOT get it's  SOURCE NAT on the WAN interface after a *while* for packets.  Regular restart of Wireguard service will mitigate this.  (every few hours).

BTW different question is how to exclude 2 interfaces from the 8 internal interfaces from the automatic rule... other than creating 6 rules by hand
#3
25.7, 25.10 Series / Re: how to allow for TCPTRACEROUTE....
September 17, 2025, 08:57:50 PM
I think i found part of the issue......
outside:
51   108.436969   X   1.1.1.1   TCP   44   52439 → 80 [SYN] Seq=0 Win=0 Len=0
52   108.437547   185.93.175.230   X   ICMP   60   Time-to-live exceeded (Time to live exceeded in transit)


13   91.725489   192.168.7.72   1.1.1.1   TCP   56   41611 → 80 [SYN] Seq=0 Win=0 Len=0
14   91.725573   192.168.7.1   192.168.7.72   ICMP   82   Time-to-live exceeded (Time to live exceeded in transit)

The ICMP Does enter the system...., it gets NATted or the source is morfed.
The changed source address probably is the issue....
Question what is the cause.
#4
25.7, 25.10 Series / Re: how to allow for TCPTRACEROUTE....
September 17, 2025, 05:54:00 PM
Outgoing port 80 is open to anywhere so that is not the blocking factor.
The client in question has no filters when on the home network. (Linux client).
A curl request instantly returns an answer. It more or less looks like either ICMP is not matched or Only matured (SYN - SYN/ACK - ACK is considered).
Code Select
# tcptraceroute 1.1.1.1
Selected device wlp45s0, address 192.168.7.72, port 33297 for outgoing packets
Tracing the path to 1.1.1.1 on TCP port 80 (http), 30 hops max
 1  * * *
 2  * * *
 3  * * *
 4  * * *
 5  * * *
 6  one.one.one.one (1.1.1.1) [open]  4.402 ms  4.013 ms  4.058 ms
# curl http://1.1.1.1/
<html>
<head><title>301 Moved Permanently</title></head>
<body>
<center><h1>301 Moved Permanently</h1></center>
<hr><center>cloudflare</center>
</body>
</html>

I'll check what the firewall log tells me.
BTW tcptraceroute is not limited to port 80 any port can be specified....
It has helped me in the past where someone had routing for IMAP/IMAPS differing, causing IMAPS to fail.
(IMAP was forwarded to a dovecot server, the IMAPS ended up on their webserver).
#5
25.7, 25.10 Series / Re: wireguard not passing traffic?
September 16, 2025, 11:48:04 PM
That is the same issue as I noticed.
It occurs since OpnSense 25.7.....

Only restart of wireguard will enable the tunnels. (might lock clients, phone starts after touching the wireguard app).

I added a cronjob to the firewall to get reasonably "stable connections"...
See attached image. on my Phone i replaced official wireguard with WG Tunnel from F-Droid
(that does actively check connections, and continues if one access fails, on failure it restarts a link)
 
It restarts Wireguard every 4 hours.
BTW the root cause seems to be replaced routes after a while, overwriting/superseding/removing wireguards routes
that bypass the NAT on the outgoing WAN interface.
#6
25.7, 25.10 Series / how to allow for TCPTRACEROUTE....
September 16, 2025, 11:31:31 PM
When running traceroute a trace is show.
Because current network configuration may send port X to a different destination as port Y, there is an issue using traceroute.
(besides the obvious blocking of UDP traceroute packets ...)
Problem with tcptraceroute is:
Code Select
# tcptraceroute 1.1.1.1
Selected device wlp45s0, address 192.168.7.72, port 45737 for outgoing packets
Tracing the path to 1.1.1.1 on TCP port 80 (http), 30 hops max
 1  * * *    (OpnSense)
 2  * * *    (ISP)
 3  * * *
Where i expected some ip addresses.  Regular traceroute shows a nice trace until the end.
With IPv6 it is a little better..., at least the OpnSense & One upstream are shown.
Nothing after that.

The way it works is the same as with UDP traceroute a packet is sent with increasing TTL times.
Except there is never a SYN/ACK... just a SYN.
Obviously resulting in some ICMP that the packet died..., OR accepted on end of the chain with SYN/ACK.

How should a rule to allow for this be setup.   
#7
25.7, 25.10 Series / Re: Wireguard wrt NAT.
August 21, 2025, 11:07:08 PM
To confirm #6909 : After reboot all wireguard tunnels fail, after disable/enable of  all tunnels they work again.
presumably something is started AFTER wireguard starts that interferes with the wireguard rules.

BTW after a few days the tunnels start failing again.

Workaround, add a cronjob to regularly restart wireguard.  Seems to hold for now :-(
#8
25.7, 25.10 Series / Re: Wireguard wrt NAT.
August 21, 2025, 10:23:05 PM
looks like 6909...,   the system told me after upgrading and waiting for 2 days that it wasn't done booting..., so i restart a bunch of services until the message went away it started working.
(AFAICT, there were no services "not started")
#9
25.7, 25.10 Series / Wireguard wrt NAT.
August 12, 2025, 04:27:33 PM
Appearantly something changed in the routing / sourceNAT ruling wrt. Wireguard upgrading from 25.1.11 -> 25.7.1-1

Before all access worked from tunnelled devices. (Mobile Phone, Tablets, Boat).
The tunnel spec on all devices  is from a local address -> 0.0.0.0/1, 128.0.0.0/1, ::/1, 8000::/1
So all internet access runs over the tunnels for the mobile equipment.

After upgrade: all access to local resources work,
A lot of access to remote resources fails (appearently not all, have not found out which exactly...,
in broad groups: web access does (HTTP, HTTPS)  seem to work, where  IMAPS definitely fails.

I have several groups, relevant here are:
LAN  (LAN, Wireless, Wireguard tunnel 1)
GUEST ( Wireless, Wireguard tunnel 2)
Those are all separate LAN's (VLANid, Network range).

All traffic from LAN, Wireless LAN, Wireless GUEST works.
Traffic from WireGuardTunnel1, Wireguard Tunnel 2 fail on outgoing Connections for NAT.
All traffic to local resources does work throught the wireguard tunnels.
As Phones have limited testing support i can only test using WEB access (Browsing) and IMAP access (mail client).
on outgoing NAT.
WEB access does work to several sites.

Outgoing traffic is sent over the WAN interface with the source address of the Mobile Device tunnel address in the failing case.
No NAT for (at least) port 993 (IMAPS) on an internet server, from mobile, over Wireguard -> OpnSense FW -> Internet.

Did anything change with respect to routing, NAT rules around Wireguard?
Wireguard tunnels groups ARE mentions in the rules @ Firewall/NAT/outgoing
#10
24.7, 24.10 Legacy Series / Re: Update 24.7.10_2 forgot how to network (with fix)
February 03, 2025, 07:23:53 PM
Last week i found out there was ONE "gateway" entry having the wrong interface.
This might have caused the issue with the newer kernel.
Appearently this error wasn't seen before.

Although there was an error in the gateway, it still did work in the correct direction. ???
#11
24.7, 24.10 Legacy Series / Re: Wireguard - Can't get it to connect
December 25, 2024, 04:51:13 PM
Public/private keys should be unique to each device communicating using a single wireguard instance.. (You can have mulitple instances aka wg interfaces).
The Public/private key is  the identifier for a configuration.

The tunnel endpoint (server side) should be a known address, also .0 (the Me address on a network) should not be used as an address.

After this start an endpoint and see if traffic arrives on the firewall. and go from there.
#12
24.7, 24.10 Legacy Series / Re: Update 24.7.10_2 forgot how to network (with fix)
December 25, 2024, 04:37:10 PM
I am seeing similar issues:
can't allocate llinfo for <IP on VLAN020> on vlan06..

(pppoe on ) vlan06, vlan04 are all on one interface, DMZ and others are on a lagg0 on 2 different interfaces.

pings to the IP address do succeed.
bouncing vlan60 makes no difference, bouncing vlan20 neither

(Current kernel as of dec. 25)
#13
24.7, 24.10 Legacy Series / Re: IGMP Permission denied sending to 224.0.01 from FirewallIP)...
December 24, 2024, 12:26:00 AM
System was rebooted after upgrade.  Appearantly if mDNS-repeater is started before IGMP-proxy IGMP-proxy fails this way.
if IGMP-proxy is started first then it does work as advertised.
#14
24.7, 24.10 Legacy Series / IGMP Permission denied sending to 224.0.01 from FirewallIP)...
December 23, 2024, 04:30:05 PM
Recently (probably after latest December update) IGMP traffic stopped working.
Is there again any solution?
AFAIK the rules have been setup as pointed out in various documentation on the PF firewall.

IPTV now stays black, "play error" only on live streams.  (OTT traffic still works).


Router/Network:
Setup: VLAN 4 = Entry point for Multicast traffic (=Upstream) DHCP interface.
       VLAN 12 = TVLAN : STB is connected here (=Downstream)
       (WAN is interface for OTT)...
       [ Other VLANS exist, not relevant for Mcast ].

IGMP:
For upstream the 100.64.0.0/20 address block is used. this is mentioned in the upstream block
For downstream the 192.168.TVLAN.0/24 is used, STB requests DHCP address.

Firewall:
Floating rule:
    Interface    VLAN04, VLAN012
    Protocol:    IPv4 IGMP
    Source:      any
    Destination: any
    Direction:   in
    Options:     allow all
    Verdict:     pass
Floating rule:
    Interface    VLAN04, VLAN012
    Protocol:    IPv4 IGMP
    Source:      any
    Destination: any
    Direction:   out
    Options:     allow all
    Verdict:     pass
Floating rule:
    Interface    VLAN04, VLAN012
    Protocol:    IPv4 IGMP
    Source:      This Firewall
    Destination: any
    Direction:   out
    Options:     allow all
    Verdict:     pass
(+ similar for MC packets )

# pfctl -s rules |grep igmp |  grep vlan04
pass out quick on vlan04 inet proto igmp from (self) to any no state allow-opts label "94c660efceff2ab83dc70703cb0c9a75"
pass in quick on vlan04 inet proto igmp all no state allow-opts label "814db0b05f4e6b06d600a2090c22024e"
pass in quick on vlan04 inet proto igmp from any to (self) no state allow-opts label "ed02681de5b1e6111e114f5c4314b46e"
# pfctl -s rules |grep igmp |  grep vlan012
pass out quick on vlan012 inet proto igmp from (self) to any no state allow-opts label "94c660efceff2ab83dc70703cb0c9a75"
pass in quick on vlan012 inet proto igmp all no state allow-opts label "814db0b05f4e6b06d600a2090c22024e"
pass in quick on vlan012 inet proto igmp from any to (self) no state allow-opts label "ed02681de5b1e6111e114f5c4314b46e"

When running:

# igmpproxy -n -vv -d /usr/local/etc/igmpproxy.conf

The followin shows:

sendto to 224.0.0.1 on 192.168.TVLAN.1; Errno(13): Permission denied
SENT Membership query   from 192.168.TVLAN.1     to 224.0.0.1
Sent membership query from 192.168.TVLAN.1 to 224.0.0.1. Delay: 10
Created timeout 721 (#0) - delay 10 secs
(Id:721, Time:10)
Created timeout 722 (#1) - delay 115 secs
(Id:721, Time:10)
(Id:722, Time:115)
RECV Membership query   from 192.168.TVLAN.1     to 224.0.0.1
RECV V2 member report   from 192.168.TVLAN.1     to 224.0.0.251
The IGMP message was from myself. Ignoring.
RECV V2 member report   from 192.168.TVLAN.1     to 224.0.0.22
The IGMP message was from myself. Ignoring.

# About to call timeout 721 (#0)
Aging routes in table.

Current routing table (Age active routes):
-----------------------------------------------------
No routes in table...
-----------------------------------------------------

Most recent update was installed somewhere last week.
#15
Intrusion Detection and Prevention / Re: suricata failing
April 09, 2023, 02:38:32 PM
After thought.. after seeing non-movement on this issue after a week i gave up on it (OpnSense) then.
As being no alternative for what i had then.

Looking into OpnSense again, this issue is closed.
Pages1 2