Recent posts

#1
General Discussion / Re: How do predefined net alia...
Last post by silmarine - Today at 12:21:31 PM
Quote from: Patrick M. Hausen on Today at 12:07:08 PMProbably. Don't know from the top of my head but that would explain the behaviour you observed.
Just tried to test this and got this error when trying to save my alias:
'Entry "192.168.1.20/32" is not a valid hostname, IP address or range.'

Seems host aliases have to be without netmask. Another thing, when I first discovered this behavior I tested it by removing the predefine interface net aliases and then all traffic was blocked except traffic from PXKSM1. So hosts from the same network are allowed only when I put one of these interface net aliases in the source. I suppose a simple fix would be to just create my own network aliases, but then I question what the purpose of these predefined ones is.
#2
Probably. Don't know from the top of my head but that would explain the behaviour you observed.
#3
General Discussion / Re: How do predefined net alia...
Last post by silmarine - Today at 12:01:11 PM
Quote from: Patrick M. Hausen on Today at 11:59:03 AM
Quote from: silmarine on Today at 11:54:51 AMThe source_net "PXKSM1" is a host alias I created

What netmask/prefix length did you use for that host alias? Needs to be /32 for IPv4 or /128 for IPv6 to match only a single host.
I didn't put a netmask/prefix in at all. Just the exact IP, like "192.168.1.20". Does it then assume the whole network if I don't?
#4
Quote from: silmarine on Today at 11:54:51 AMThe source_net "PXKSM1" is a host alias I created

What netmask/prefix length did you use for that host alias? Needs to be /32 for IPv4 or /128 for IPv6 to match only a single host.
#5
General Discussion / Re: How do predefined net alia...
Last post by silmarine - Today at 11:54:51 AM
Quote from: Patrick M. Hausen on Today at 11:12:02 AM@silmarine did you possibly use source or destination invert in your floating rule that did not work as expected?
no, definitely not. I have only a couple of floating rules and they are intended for general rules from a couple of interfaces where similar clients to be, but are segmented for other reasons. For example, I have 3 networks were i would like to allow SSH from and to the same set of networks. So it instead of created 3 different rules I created on floating. Only thing is from one of those interfaces I only need a single host allowed. I exported my rule set and pasted this example rule here, if that helps to understand it.

             
actionquickinterfacenotinterfacedirectionipprotocolprotocolicmptypeicmp6typesource_netsource_notsource_portdestination_netdestination_notdestination_portdivert-togateway
pass10opt1,opt5,opt10ininet46TCPPXKSM1,opt1,opt100opt3,opt5,opt6,opt7,opt80ssh

The source_net "PXKSM1" is a host alias I created, in the UI the source_net "opt1" and "opt10" look like "clients net" and "client_vpn net". Interface "opt5" is where "PXKSM1" is. However I can do ssh connections to the destinations from any host in opt5. I have also confirmed that this rule is the one being matched in the live logs, as I gave it a description that is listed in the "Label" field of the logs.
#6
@newsense

Can you show your NAT ruleset that has problems (26.7.b), and the NAT ruleset which does not have problems (pre 26.7.b, e.g. 26.1.10)?

# pfctl -s nat
# pfctl -s rules

If there is something unexpected also check rules.debug, it shows if rules have been skipped before being loaded for some reason. (DEBUG: lines)

# cat /tmp/rules.debug

Try do find if there is a difference, e.g. by piping both outputs in files and using a command like "diff -u file1 file2" or a diff capabable editor.
#7
26.7 Development Series / Re: OPNsense 26.7-BETA images
Last post by newsense - Today at 11:50:30 AM
Quote from: patient0 on Today at 11:36:26 AMWhat outgoing NAT rules did you create? For what you wrote it seems that all necessary rules should have been automatic rule, no?

The road warrior WG setup worked fine for years, only broke when moving to 26.7.b

Why exactly I had to move to hybrid I don't remember right now, once everything was working I didn't have to go back there for a long time.

#8
26.7 Development Series / Re: OPNsense 26.7-BETA images
Last post by patient0 - Today at 11:36:26 AM
Quote from: newsense on Today at 11:25:10 AMWell that's the kicker: not everyone will have migrated to the new rules before upgrading to 26.7 and not everyone will have Automatic in SNAT.

You are right, yes. But as long as I can't show steps on how to reproduce it, the devs won't be able to fix it.

I did read through your post but I didn't take the time to build a system with a WG tunnel. In your case it could be NAT or something else.
What outgoing NAT rules did you create? For what you wrote it seems that all necessary rules should have been automatic rule, no?
#9
26.7 Development Series / Re: OPNsense 26.7-BETA images
Last post by newsense - Today at 11:25:10 AM
>>> don't spend anymore time on it. If I can reproduce it on a clean installation, I'll be back.


Well that's the kicker: not everyone will have migrated to the new rules before upgrading to 26.7 and not everyone will have Automatic in SNAT.

There's an issue there for sure and whether Cedrik's latest patch fixes everything or not is unclear as I'm not able to test for now.

What is likely though in the absence of the fix is that anyone not using automatic or doing fresh installs might be affected.


Thankfully 26.7 is still weeks away and by RC1 things should be clearer.


The biggest question mark for me is where the issue actually is... since it would appear that installing base 15.1 affects the core where the NAT code resides (?)
#10
26.7 Development Series / Re: OPNsense 26.7-BETA images
Last post by patient0 - Today at 11:21:07 AM
Quote from: Monviech (Cedrik) on Today at 10:56:51 AMhe SNAT automatic issue should be fixed via

# opnsense-patch https://github.com/opnsense/core/commit/aa2a54a5a8

Works like a charm now, excellent and thank you.