Masquerading NAT not working for Metarouter tunnel devices?

RouterOS Beginner Basics
1

Hi,

I’m quite new to RouterOS and wanted to use RB2011UAS-2HnD-IN to replace my WRT54GL.
The possibilities with RouterOS are amazing but currently I’m struggling with some strange issue.

Current setup

Relevant ports:

ether10   - Uplink to the WAN, currently using DHCP Client for this.
            IP      10.2.0.197/16
            Gateway 10.2.255.254
           
vif1      - Virtual Interface for Metarouter mr1
            bridged to net-local

net-local - Bridge for combining (future) virtual interfaces
            IP      10.0.255.254/16
            DHCP-Server to serve 10.0.0.1-10.0.255.253

ether10 on the routerboard is configured to use src-nat masquerading on outgoing packets to hide the routerboard routes from the 10.2/16


Metarouter:

mr1       - Openwrt on the latest working trunk revision
            Memory: 24 MiB
            Static Interface vif1 (internaly available as eth0)

Within the Metarouter:

I’m trying to use Tayga to run a NAT64 for experimenting with it

eth0      inet addr:10.0.0.1  Bcast:10.0.255.255  Mask:255.255.0.0
          inet6 addr: fdc3::2/64 Scope:Global
          inet6 addr: fe80::f8:8ff:fe9d:76e9/64 Scope:Link
tayga-nat64 
          inet addr:10.0.0.1  P-t-P:10.0.0.1  Mask:255.255.255.255
          inet6 addr: fdc3::2/128 Scope:Global

Tayga uses some tunnel device and maps fd64::/96 to 10.64.0.0/16 addresses.
The metarouter got src-nat masquerading enabled to map these 10.64.0.0/16 to its 10.0.0.1

Problem:

From within the metarouter i can ping 10.2.0.1 (some device available behind routerboards ether10) and see these icmp packets arriving at 10.2.0.1 from 10.2.0197 as expected. So for me it looks like they are passing both masquerading rules and are translated two times.

The strange thing is, when pinging fd64::10.2.0.1 from within the metarouter I’m also able to receive the icmp packets on 10.2.0.1 but they are sent from 10.0.0.1. So they aren’t handled in the routerboards ether10 outgoing masquerading rule.

The only difference for this packets I could see is that they are passing the metarouters tunnelling device.
But from the scope of the routerboard I expect them to be passed through vif1, routed to ether10 and masqueraded there.

I know this is quite unusual setup but I’m happy for every hint you can provide. Especially I’m interested if there is some special treatment for tunnelling devices on metarouters.

Kind regards

Phil

2

Hi Phil,

I know this reply comes late, but I encountered the same issue just the other day. I think this issue is related more to packets forwarded through Tayga having bad IP checksums and thus confusing the NAT mechanism. The bad checksums are my next problem in the stack of issues. I uncovered this while configuring a metarouter instance to perform NAT64. Using tcpdump on my local network I was able to verify packets were passing through Tayga and arriving at the proper destination address, but the receiving systems were discarding them due to the IP checksum being invalid. If you ever solved this issue, I would love to know how you did so. I have tried multiple OpenWRT image builds in metarouter spanning many kernel versions and all exhibit the same issue. Cheers.

[Edit]

I have resolved the issue I was having. See http://forum.mikrotik.com/viewtopic.php?f=15&t=82329 for more details.

3

Hi Tetrafluoroethane,

I already considered this thread dead and my problem to be too specific for being answered.

If you ever solved this issue, I would love to know how you did so.

I’ve only worked around it by doing the NAT64 stuff on some other system outside of the microtik board.
So: Nope I haven’t had the patience to find a solution.

Its very nice to see that your investigation on this problem led to an solution.
Maybe I’ll try to use the provided patch from your other topic some time in the future.

Thanks

Phil