NAT killing OSPF

RouterOS Forwarding Protocols
1 
/interface bridge add name=loopback
/interface bridge settings set use-ip-firewall=yes
/ip address
 add address=123.123.123.208/32 interface=loopback
 add address=10.100.100.117/29 interface=ether1-gateway
 add address=10.212.1.1/29 interface=ether2-south_tower
 add address=10.212.8.1/24 interface=ether3-north_AP
/ip route add gateway=10.100.100.113

Basic OSPF setup.

/routing ospf interface
 add network-type=broadcast passive=yes
 add authentication=md5 authentication-key=myOSPFkey interface=ether1-gateway network-type=broadcast priority=0
 add authentication=md5 authentication-key=myOSPFkey interface=ether2-south_tower network-type=broadcast priority=0

I got OSPF working. I then added a NAT rule to the configuration.

/ip firewall address-list
 add list=my_network address=10.0.0.0/8
 add list=my_network address=123.123.123.0/24
/ip firewall nat
 add action=src-nat chain=srcnat dst-address-list=!my_network src-address=10.0.0.0/8 to-addresses=123.123.123.208

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.

Router is Killing all peers Ospf
v7.1.1 OspfNeighbor received wrong LS Ack
2

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

add chain=srcnat protocol=ospf action=accept
3

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

4

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.

5

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

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

6

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

7

2022 Edit :slight_smile:

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…

8

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.


/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.

9

+1 This works for us as well, thanks!

10

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

11

(2017 calling, posting keywords for search results, referencing finding in http://forum.mikrotik.com/t/v7-1-1-ospfneighbor-received-wrong-ls-ack/155679/24)

Between any RouterOS v7.11.2.

default-v2 { version: 2 router-id: x.x.x.13 } backbone { 0.0.0.0 } interface { p2p x.x.x.13%l2tp-x} neighbor { router-id: x.x.x.254 state: Full } received wrong LS Ack for router x.x.x.13 x.x.x.13 0x80000382 expected 0x80000383

(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.

12

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

13

+1 worked here! I am a days with this problem!

14

please… not trying to be rude - but why would any networkers make their lives harder by doing nat on such important basic connectivity protocols??

learn the basic, build the foundation - design and operate.

ospf use multicast if available, otherwise it will use unicast.

and interior routing - should be connected by any means of any vpn tunnels.