Messages

Indeed - works now. Thanks a lot!

Of course, you're right. Unfortunately OPNsense doesn't provide a flag for iBGP (kind of assumed that the matching ASN would be automatically translated into iBGP) and I don't know if a manual configuration in the CLI survives any changes. But I will test it now with private ASN instead.

Thanks for your reply. Here is the config:

Code Select Expand

Current configuration:
!
frr version 3.0.3
frr defaults traditional
!
log file /var/log/frr.log
!
router bgp 65000
neighbor 192.168.230.246 remote-as 65000
vnc defaults
  response-lifetime 3600
  exit-vnc
!
line vty
!
end

I have changed ASN + IP since I don't want to reveal this here. However, now being on the zebra shell (thanks, didn't know the vtysh command; always did a telnet to localhost in earlier days when working with zebra on linux systems) I can see, that the routes are in fact received but not installed:

Code Select Expand

natgw.vm.serv# show ip route
Codes: K - kernel route, C - connected, S - static, R - RIP,
       O - OSPF, I - IS-IS, B - BGP, P - PIM, N - NHRP, T - Table,
       v - VNC, V - VNC-Direct,
       > - selected route, * - FIB route

K>* 0.0.0.0/0 via 192.168.201.0.1, vtnet0
C>* 192.168.0.0/27 is directly connected, vtnet0
K>* 172.20.0.0/16 via 172.20.0.205, ovpnc2
C>* 172.20.0.205/32 is directly connected, ovpnc2
C>* 172.20.32.0/23 is directly connected, vtnet1
C>* 192.168.202.0/24 is directly connected, vtnet1

So it seems default behaviour is not to accept anything and I need to find out how to write a "permit any" policy on this "device" I guess?

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!

I wanted to provide an update to this since the behaviour seems not to be well-documented. Apparently the device takes connection tracking into account which means, that if a connection matches an outbound rule (so egress for a vlan for example) and the reply matches the same connection, the ingress rule will not be taken into account. This makes creating rules for solely firewall local traffic a bit more complex since you cannot rely on a simply deny rule on ingress anymore.

No, not at all. I had a "permit anything from the vlan egress" rule which matched of course for any traffic between the vlans and I was unable to deny that. Also an additional "deny from source != vlan net" rule doesn't work either.

The issue was meanwhile solved and some misunderstandings (as it seems) could be cleared.

• A specific "permit" rule on egress is not required so this is a useless match
• Floating rules are always considered first. Reading the documentation I thought it would be "Floating first match > Interface > Floating last match" but it is actually "Floating first match > Floating last match > Interface" which makes the first/last match feature kind of useless in my eyes.
• We removed the specific permit on egress rule and afterwards the ingress rules were processed correctly. I guess there is some implicit "permit" for connected interface IPs that may or may not be disabled somewhere in the settings but it doesn't disturb so we won't touch this.

To sum it up: we learned some important details for the future.

To be more specific: "first match wins" seems to work globally and not on a per-interface basis. Can anybody confirm this?

Hi,

you have a specific discard rule installed but it is my understanding, that the default policy is a reject and therefore unless specifically allowed, this should be blocked without this specific reject rule anyways. It seems that - at least for traffic routed between interface (so hopefully no WAN) - a permit on egress is sufficient and another permit on ingress of the destination interface is not required. If that's the case it's at least odd behaviour and makes configuring rules a bit more complex. Maybe someone can confirm or correct me at this point?

Thanks!

OK I enabled logging for all those rules and we will test again. It might be worth a try to disable outbound NAT completely since you mentioned this "anything from the firewall host itself" message was originating from NAT.

Hi,

we have an outbound NAT configured as follows:



But since the destination is reachable via internal routing it shouldn't be used, right?

These 3 Vlans are different internal services that must not communicate with each other. All 3 Vlans have outbound NAT for access to the internet and unless specifically configured otherwise, there is no communication between vlans desired.
The first rule makes sure (but it might not be required) both firewalls can talk to each other. It was actually initially configured by a colleague so I am not sure if the OPNsense did that by itself after configuring CARP or he  did it manually by himself. But since it is set to match the CARP protocol only, it shouldn't affect the regular client traffic in my eyes.

What actually is not working is that the Vlans can communicate with each other although there should by - at least it is my understanding - a default deny policy in place and since we never specifically allow the source address from any of the other vlans, it shouldn't pass the firewall.

[very]

Hi,

thanks for the reply. The rules are actually very basic. A screenshot from Vlan200 is here but vlan 300 and 400 are identically with their individual source subnets.



It is my understanding, that this should block all traffic originating from other subnets. I did actually add a logging but even as the first rule, I only see matches with the previously mentioned let out anything from firewall host itself comment.

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!

Hehe great timing for me and my problem, we will definitively test that - thanks!

Replying myself: seems like I need several Phase 2 entries for that.