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 - Nico

#1
I've never seen such a popup. I consider this to be a step backwards as well. Why don't make it configureable? But actually I never saw slow speeds before, syncing was always fast. And I have no idea why most stuff synced automatically before but other things like the alias lists had to be synced manually. So at least the "all or nothing" approach makes more sense to maintain a healthy state but I'd like to see the auto-sync coming back.
#2
Hi,

I'm a little confused. I just set up a new pair of OPNsense firewalls in HA mode as usual but they do not seem to sync automatically anymore. I have to manually sync the state, otherwises users, firewall rules or CARP settings are not synched anymore. Is this intended or did I miss something?
I have setup dozen of those before and the configuration doesn't really differ this time from previous setups.

Thanks!
#3
Thanks!
#4
Hi,

there seems to be a big lack of documentation in this area. Can anyone tell me when groups are being evaluated? Before or after the individual interface rule? Thanks!
#5
Hello,

this is more for informational purposes than an actual cry for help since I managed to find a work around. However, I recently found an issue with asymetrical routing and apparently unsynchronized firewall states. The setup is as follows:


  • 2x OPNsense in HA configuration with a dedicated HA link
  • Both having the FRR routing suite and iBGP setup with some bigger routers and exchanging routes over the WAN interface
  • CARP on all LAN interfaces

Firewall A was the primary ingress router since the BGP peering routers learned those routes first and had them active. So all traffic from the WAN side came in through Firewall A. This was working as expected as long as Firewall A was the CARP master. As soon as the master switched to Firewall B, the routing was asymetric and the firewall states obviously not synched anymore leading to traffic not being able to return since there was no corresponding permit rule on WAN ingress.

I solved this by


  • Overriding the next-hop on the BGP peering routers to point to the WAN CARP IP instead of the loopback IP of each Firewall
  • Enabling preempt for carp thus making it failover all interfaces at once
  • Surprisingly /etc/sysctl.conf was ignored for this so I added the tiny command to a newly created file in "/etc/rc.conf.d/preempt" which is processed fine upon reboot

Maybe I oversaw something but I thought this was appropriate to share with you. A question aside from that: I assume the firewall states are synchronised using the configured credentials but this is of course only configured one way: from A to B. Am I supposed to configure this vice versa? Since documentation is not clear about that, we tested that once but ran into issues according to my colleague. So maybe someone can shed some light on this matter.


Thanks!
#6
Thanks a lot!
#7
Quote from: franco on February 21, 2019, 12:27:23 PM
FPA = finish push ack

Set state tracking to none, for one reason or another state tracking thinks this is a faulty state transition.

Just for clearification: I cannot simply change state tracking to none for the only "pass any" rule since this would result in blocking the replies (unless I have a permit any inbound rule on WAN), correct? So I added a 2nd identical rule with pass any/any and state = none. Is this correct from your point of view?
#8
OK thanks, meanwhile I found this https://docs.netgate.com/pfsense/en/latest/firewall/troubleshooting-blocked-log-entries-for-legitimate-connection-packets.html which seems to address that. That helps, thanks a lot!
#9
Quote from: chemlud on February 21, 2019, 12:23:01 PM
TCP flag finish might be involved? See your first screen shot ;-)

I'm looking and looking.. where do you see a "finish" flag? I'm unable to find it anywhere.
#10
These are the rules on that interface. 2 and 3 are for testing only. I added a manual default deny that should kick in before the system's default deny but it never did. So I kind of got the assumption that those packets are somewhat special for my pass rule not to kick in. So I tested a little with the advanced options, enabled any flags and changed the state to sloppy but with no effect.
#11
19.1 Legacy Series / Unclear why default deny kicks in
February 21, 2019, 12:04:48 PM
Hi,

maybe someone can enlighten me why the "default deny" rule kicks in although there are several pass rules that should match?
It's about an IPsec tunnel with a permit any/any rule on that interface that should allow any traffic to pass through it. This works in like 99% of all cases I guess but a couple of times I see a default deny rule kicking it and when I look at the details of this log entry, I cannot spot why. It's like the thing ran out of memory to hold any more custom states and just falls back to the default deny. Is this possible? I will attach screenshots of one deny and one pass for you to see yourself.

Thanks!
#12
Quote from: AdSchellevis on February 01, 2019, 05:30:24 PM
can you try https://github.com/opnsense/core/commit/e9d1aa457903b335c980b10ef7f37b23b5518ce7 ?

From the console, install using:

opnsense-patch e9d1aa4


I'm sure this will work. As stated it is very clear what the issue is and I can manually update the generated file myself. It was more a hint for the next release since others may have issues with that as well since it seems to affect the Windows client in all versions.
#13
Hi,

just upgraded to the newest production release and found the new OpenVPN export utility which I generally like. However it exports the config with

remote <ip> <port> UDP

which does not work with the Windows client. It needs to be "udp" instead and it will work flawlessly.

I haven't tested other OS or clients.
#14
Yet again: enable logging for those to see if they match or not.
#15
Enable logging for certain rules and see if an earlier rule applies or if those rules apply at all.