Basic OSPF setup. I got OSPF working. I then added a NAT rule to the configuration. After adding my nat statement my OSPF neighbor is lost. I have tried adding protocol=!ospf dst-address-type=unicast out-interface=ether1-gateway to my nat statement. I have also added 224.0.0.0/23 and 255.255.255.255 to the my_network address list. I have tried several router OS versions and different routerboard models.

My conclusion is the nat statement is matching the osfp traffic.

Are you sure it's only /23?
You could add the following rule before nat:

Years later this bug is still present.

/routing ospf area
set [ find default=yes ] disabled=yes
add area-id=0.0.0.101 name=101
/routing ospf instance
set [ find default=yes ] name=101 redistribute-connected=as-type-2 router-id=\
10.101.4.5
/routing ospf interface
add network-type=broadcast passive=yes
add authentication=none interface=ether3 network-type=broadcast
/routing ospf network
add area=101 network=10.0.0.0/8

OSPF works with this config.

This brakes ospf:

/ip firewall nat
add action=masquerade chain=srcnat out-interface=sfp+1 \
src-address=169.254.1.1

169.254.1.1 is not active on the network anywhere. Interface spf+1 is not active on this device or have an address or route associated. This rule does not match any traffic. The nat rules shows 0 bytes and 0 packets. Disabling the nat rule fixes ospf.
I have also tried adding the sugested "add chain=srcnat protocol=ospf action=accept " rule as the only rule. It breaks OSPF too.

log print:
17:14:53 system,info nat rule changed by admin
17:15:26 route,ospf,info OSPFv2 neighbor 10.108.255.254: state change from 2-Way t
o Init
17:15:27 route,ospf,info OSPFv2 neighbor 10.132.2.1: state change from 2-Way to In
it
17:15:27 route,ospf,info OSPFv2 neighbor 10.116.1.1: state change from 2-Way to In
it
17:15:27 route,ospf,info OSPFv2 neighbor 10.101.4.3: state change from 2-Way to In
it
17:15:29 route,ospf,info OSPFv2 neighbor 10.108.40.1: state change from 2-Way to I
nit
17:15:30 route,ospf,info OSPFv2 neighbor 10.101.255.255: state change from 2-Way t
o Init
17:15:30 route,ospf,info OSPFv2 neighbor 10.100.0.15: state change from 2-Way to I
nit
17:15:30 route,ospf,info OSPFv2 neighbor 10.101.4.39: state change from 2-Way to I
nit
17:15:33 route,ospf,info OSPFv2 neighbor 10.140.32.1: state change from 2-Way to I
nit
17:15:33 route,ospf,info OSPFv2 neighbor 10.102.8.1: state change from 2-Way to In
it
17:15:34 route,ospf,info OSPFv2 neighbor 10.140.60.1: state change from 2-Way to I
nit
17:15:34 route,ospf,info OSPFv2 neighbor 10.101.4.25: state change from 2-Way to I
nit

What I did was to add to the NAT rule:
protocol=!ospf

So, an example src nat rule may look like:
add action=src-nat chain=srcnat comment="my new nat rule" protocol=!ospf src-address=192.168.88.0/24 to-address=192.168.1.11

This really threw me for a long while - If there is a better way to do this - please let me know, as I have very little mikrotik experience.

What I did was to add to the NAT rule:
protocol=!ospf

So, an example src nat rule may look like:
add action=src-nat chain=srcnat comment="my new nat rule" protocol=!ospf src-address=192.168.88.0/24 to-address=192.168.1.11

This really threw me for a long while - If there is a better way to do this - please let me know, as I have very little mikrotik experience.

That solution works too, another one available is to use this one:

/ip firewall raw add chain=prerouting protocol=ospf action=notrack

Confirmed. Just happened to me. Enabling any NAT rule changed the outbound IP OSPF was using, even if the NAT rule had nothing to do with that IP. Disabling the IP, removing it from OSPF networks, etc: nothing worked. Adding a raw rule to no-track the ospf protocol was the only way I could get it running again.

edit: this is on a CCR1009-7G-1C-1S+ running 6.48.1

2022 Edit

The bug is till persistent in 6.49.5 and 7.1.5 -too. At our setup the firewall raw prerouting action does not work but adding a rule to output chain OSPF starts working ....
Really annoying because the bug was not showing up in our 6.47.1 setup but after upgrading the software the bug showed up...

In case this helps someone else....

We are using OSPF and NAT on a router running Router OS v7.2.3. This was causing problems where NAT was changing the outbound OSPF IP Address to the IP address we were using to NAT customer traffic. We tried some of the suggestions in this post with varying degrees of success. Sometimes when we rebooted the router, all the OSPF neighbor states would be stuck at init. The fix for us was to disable connection tracking for OSPF using the Router OS code below.


With both of those RAW rules in place everything has been stable.

Code: Select all

/ip firewall raw
add action=notrack chain=prerouting protocol=ospf
add action=notrack chain=output protocol=ospf

With both of those RAW rules in place everything has been stable.

+1 This works for us as well, thanks!

In case this helps someone else....

We are using OSPF and NAT on a router running Router OS v7.2.3. This was causing problems where NAT was changing the outbound OSPF IP Address to the IP address we were using to NAT customer traffic. We tried some of the suggestions in this post with varying degrees of success. Sometimes when we rebooted the router, all the OSPF neighbor states would be stuck at init. The fix for us was to disable connection tracking for OSPF using the Router OS code below.

Code: Select all

/ip firewall raw
add action=notrack chain=prerouting protocol=ospf
add action=notrack chain=output protocol=ospf

With both of those RAW rules in place everything has been stable.

+1 works here too, finally after many hours of struggle I found this.

(2017 calling, posting keywords for search results, referencing finding in viewtopic.php?p=1029269#p1029269)

Between any RouterOS v7.11.2.
(the so called +1 , 2 -> 3)

Masqurade / nat seems to cause this (internal interfaces), probably shouldn't, quite certainly a default type of logic bug as the IPs are correct.

In case this helps someone else....

We are using OSPF and NAT on a router running Router OS v7.2.3. This was causing problems where NAT was changing the outbound OSPF IP Address to the IP address we were using to NAT customer traffic. We tried some of the suggestions in this post with varying degrees of success. Sometimes when we rebooted the router, all the OSPF neighbor states would be stuck at init. The fix for us was to disable connection tracking for OSPF using the Router OS code below.

Code: Select all

/ip firewall raw
add action=notrack chain=prerouting protocol=ospf
add action=notrack chain=output protocol=ospf

With both of those RAW rules in place everything has been stable.

The only working solution for me as well.
Annoying bug, i suspect it wasn't reproducing in 6.49.2 since i didn't had any issue before upgrading to 6.49.15.
Thanks @CCIS