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

Topics - Nico

#1
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!
#2
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!
#3
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!
#4
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!
#5
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.
#6
Hi,

I have just setup an iBGP with a Juniper MX router in the lab. Local & Remote AS are identical and the Juniper MX announces quite some routes from the internal network (so direct & ospf routes are being redistributed). I can see those routes on the OPNsense in Diagnostics -> BGPv4 although it seems to be malformatted since the first digit of the route is printed in the forst column next to the "i" and the network column looks for example like this: "   .251.251.0/24 84" where the 84 actually belongs to the next column "next hop" again as the first digit. However, I assume this is just a cosmetic issue. The real issue is that all those routes are not being installed in the system's routing table. Going to system -> routes -> status I only see the standard few routes that were there before. I didn't find a know either to leak the bgp table into the local table and a 'netstat -r' on the console doesn't reveal any further routing tables either that hold the bgp learned routes. There are neither route-maps nor prefix-lists present which typically means, that everything can pass. But I also tested with 'permit any' rules with the same results.

Any hint from your side? Is this a bug or did I miss something?

Thanks!
#7
Hello everybody,

my issue is not specific to 18.7 since we were on the previous major release until a maintenance upgrade tonight and the behaviour did not change. Here is a quick overview of the setup:

- 3 Vlans: 200, 300 and 400
- each with it's distinct /24 IP network: 10.0.102.0/24, 10.0.103.0/24, 10.0.104.0/24 with the .1 as the gateway and CARP for HA
- each vlan interface has a rule that permits IPv4 CARP
- each vlan interface has a rule that permits it's own source (had this set to automatically generated vlan200 net and address first which did not work either; btw: what is the difference between net and address? Didn't find any doc about that)

This should result in dropping all traffic from different sources but it's not but a test rule containing a specific pair we used to test did actually work. Instead the logging shows messages such as "icmp   let out anything from firewall host itself" which seems to be an implicit rule I cannot find anywhere.

Questions are now:
- why isn't it working?
- where can I set / see the direction of rules generally? The rules page shows the direction arrows but I've literally never seen an arrow displayed there for the rules and cannot seem to find the option in the "edit rule" to limit it to either in our out


Please let me know if further input is required.

Thanks!
#8
17.7 Legacy Series / OpenVPN cannot reach IPSec
September 05, 2017, 11:51:04 PM
Hello,

I have the following setup running:

- the OPNsense has a working IPsec connection to Google cloud established via public Internet
- the OPNsense provides a working OpenVPN server
- the OPNsense provides direct LAN to local servers
- the local server can reach the IPsec IP subnet
- the OpenVPN clients cannot reach the IPsec IP subnet
- the firewall itself (using interface diagnostics) can't reach the IPsec subnet (ping an IP there)
- the IPsec subnet 10.242.108.0/24 has a route installed on the firewall pointing to the WAN Gateway which should be wrong in my eyes
- a traceroute via OpenVPN shows, that an attempt to reach a Google IPsec IP is routed via WAN and stops there
- a traceroute via LAN to IPSec is asked for, waiting for customer reply
- firewall permit rules are installed, the OpenVPN instances have a "permit any" but I suspect the issue to be the route

What else can I provide? Maybe someone already has an idea.


Best,
Nico