Changing source ip address for ICMP type 11 packets.

RouterOS General
1

In order to conserve IP address space (since there’s no support for /31 networks in routeros) I thought I could use 10.x.x.x addresses on my point-to-point links and use src-nat to make traceroutes appear to come from my router’s loopback address. Running routeros 6.5rc1

I couldn’t get it to work, so I removed all my rules and simply created logging rules.

/ip firewall filter
add action=log chain=output icmp-options=11 log-prefix=filter protocol=icmp
add action=log chain=input icmp-options=11 log-prefix=filter protocol=icmp
add action=log chain=forward icmp-options=11 log-prefix=filter protocol=icmp
/ip firewall mangle
add action=log chain=postrouting icmp-options=11 log-prefix=mangle protocol=icmp
add action=log chain=output icmp-options=11 log-prefix=mangle protocol=icmp
add action=log chain=forward icmp-options=11 log-prefix=mangle protocol=icmp
add action=log chain=prerouting icmp-options=11 log-prefix=mangle protocol=icmp
add action=log chain=input icmp-options=11 log-prefix=mangle protocol=icmp
/ip firewall nat
add action=log chain=srcnat icmp-options=11 log-prefix=nat protocol=icmp
add action=log chain=dstnat icmp-options=11 log-prefix=nat protocol=icmp

Here’s the log after a traceroute through the router.

echo: firewall,info mangle output: in:(none) out:ether1, proto ICMP (type 11, code 0), 172.16.19.1->172.16.19.18, len 80
echo: firewall,info filter output: in:(none) out:ether1, proto ICMP (type 11, code 0), 172.16.19.1->172.16.19.18, len 80
echo: firewall,info mangle postrouting: in:(none) out:ether1, proto ICMP (type 11, code 0), 172.16.19.1->172.16.19.18, len 80
echo: firewall,info mangle output: in:(none) out:ether1, proto ICMP (type 11, code 0), 172.16.19.1->172.16.19.18, len 80
echo: firewall,info filter output: in:(none) out:ether1, proto ICMP (type 11, code 0), 172.16.19.1->172.16.19.18, len 80
echo: firewall,info mangle postrouting: in:(none) out:ether1, proto ICMP (type 11, code 0), 172.16.19.1->172.16.19.18, len 80
echo: firewall,info mangle output: in:(none) out:ether1, proto ICMP (type 11, code 0), 172.16.19.1->172.16.19.18, len 80
echo: firewall,info filter output: in:(none) out:ether1, proto ICMP (type 11, code 0), 172.16.19.1->172.16.19.18, len 80
echo: firewall,info mangle postrouting: in:(none) out:ether1, proto ICMP (type 11, code 0), 172.16.19.1->172.16.19.18, len 80

It appears that the packet never traverses the srcnat chain even though the packet flow diagram shows that src-nat occurs after mangle postrouting. Is there any way to make this happen?

Thanks,
Tim Nowaczyk

2

Any update to this?

3

I just tried again with ROS 6.9 and I get the same thing.

/ip firewall filter
add action=log chain=output icmp-options=11 log-prefix=filter protocol=icmp
add action=log chain=input icmp-options=11 log-prefix=filter protocol=icmp
add action=log chain=forward icmp-options=11 log-prefix=filter protocol=icmp
/ip firewall mangle
add action=log chain=postrouting icmp-options=11 log-prefix=mangle protocol=icmp
add action=log chain=output icmp-options=11 log-prefix=mangle protocol=icmp
add action=log chain=forward icmp-options=11 log-prefix=mangle protocol=icmp
add action=log chain=prerouting icmp-options=11 log-prefix=mangle protocol=icmp
add action=log chain=input icmp-options=11 log-prefix=mangle protocol=icmp
/ip firewall nat
add action=log chain=srcnat icmp-options=11 log-prefix=nat protocol=icmp
add action=log chain=dstnat icmp-options=11 log-prefix=nat protocol=icmp




echo: firewall,info mangle output: in:(none) out:ether4, proto ICMP (type 11, code 0), 10.1.0.61->97.87.17.16, len 56
echo: firewall,info filter output: in:(none) out:ether4, proto ICMP (type 11, code 0), 10.1.0.61->97.87.17.16, len 56
echo: firewall,info mangle postrouting: in:(none) out:ether4, proto ICMP (type 11, code 0), 10.1.0.61->97.87.17.16, len 56
4

I’ve got this exact problem too. Using RFC 1918 address space as interlinks on an MPLS network. Having this problem in a lab network, about 9 RB750GLs and production network running on CCRs, all bravely (& stable) on 6.10 now.

5

I received this from MT support:

NAT only works with connection-state=new packets, soin case of ICMP a request
packet, no a reply packet, that have connection-state=established.

It is similar to linux iptables.

Makes sense, thinking that I could set a nat translation to match ICMP from outside the RFC1918 space as they come in, instead of NAT’ing on the reply’s egress. Will set this up in the lab and report back here how it goes, probably next week some time.

6

Will set this up in the lab and report back here how it goes, probably next week some time.

Any success or news to report?

7

I am very interested in this also. I took a different route that kind of works though - can’t you just change preferred source address on routing table to be loopback address and it will reply with that? I think I have that working somewhere on my network…