Setting TTL for Outgoing Traffic

Binser · Wed Jan 16, 2019 6:56 pm

Hello,

I am using an SXT LTE kit as a fallback for our network and would like to set the TTL for outgoing traffic to 64, so that the mobile provider will not recognize that there is a whole network using data.
Using following command I get an error:

/ip firewall mangle add chain=prerouting out-interface=!ether1 action=change-ttl new-ttl=set:64 passthrough=yes 

failure: outgoing interface matching not possible in input and prerouting chains

What would be the right way to go about this?

sebastia · Wed Jan 16, 2019 6:59 pm

Hey

In pre-routing, the routing hasn't been performed yet, so the outgoing interface is not known yet.

change to chain=postrouting.

Binser · Wed Jan 16, 2019 7:23 pm

Thank you @sebastia for your competent and fast answer.

This time the router didn't complain when entering the rule.

However, the rule is now in red and the router added the comment:
in/out-interface matcher not possible when interface (ether1) is slave - use master instead (bridge)

Furthermore, when I enter

/ip firewall mangle print stats

no bytes passing through this rule are shown.

Do you have any idea how I can verify if this is working?

Binser · Wed Jan 16, 2019 8:10 pm

I have now changed the rule to:

/ip firewall mangle add chain=postrouting out-interface=lte1 action=change-ttl new-ttl=set:64 
passthrough=yes

and I can now see activity on

/ip firewall mangle print stats

Would this be the correct interface now?

Should I change passthrough to No for less CPU usage?

sebastia · Wed Jan 16, 2019 8:34 pm

The lte itself is not in passthrough, is it? If no then above is correct.

About the pass-through on mangle, that depends if you want to apply any more actions? If you don't then you don't need pass-through.

Binser · Wed Jan 16, 2019 8:58 pm

LTE is not in passthrough mode, since there are several hosts connected.

Binser · Wed Jan 16, 2019 11:42 pm

When I look at the stats going through the simple queue and the one on the mangle rule, I see quite a big discrepancy:

/que s p stats
Flags: X - disabled, I - invalid, D - dynamic 
 0    name="PCQ-Queue" target=192.168.86.0/24 rate=26.6kbps/194.6kbps total-rate=0bps packet-rate=34/32 
      total-packet-rate=0 queued-bytes=0/0 total-queued-bytes=0 queued-packets=0/0 total-queued-packets=0 
      bytes=28435218/314372420 total-bytes=0 packets=307847/301793 total-packets=0 dropped=0/3471 
      total-dropped=0 pcq-queues=1/1 
/ip fi m p stats all                                     
Flags: X - disabled, I - invalid, D - dynamic 
 #    CHAIN                                             ACTION                            BYTES         PACKETS
 0    postrouting                                       change-ttl                   10 635 234         107 271

Over 300.000 packets uploaded shown by simple queue, but only 107.000 packets in my mangle rule. How can that be?

sebastia · Thu Jan 17, 2019 12:42 am

bytes are off too. all counters reset on at same time?

Binser · Thu Jan 17, 2019 9:00 am

I just did a complete reboot, waited a few minutes and tested again:

/ip fi m p stats all
Flags: X - disabled, I - invalid, D - dynamic 
 #    CHAIN                                             ACTION                            BYTES         PACKETS
 0    postrouting                                       change-ttl                    1 083 112           7 753
/que s p stats     
Flags: X - disabled, I - invalid, D - dynamic 
 0    name="PCQ-Queue" target=192.168.86.0/24 rate=32.9kbps/465.8kbps total-rate=0bps packet-rate=61/57 
      total-packet-rate=0 queued-bytes=0/0 total-queued-bytes=0 queued-packets=0/0 total-queued-packets=0 
      bytes=1496784/6894999 total-bytes=0 packets=12402/12941 total-packets=0 dropped=0/169 total-dropped=0 
      pcq-queues=1/1

The two lines were typed immediately after the other. Definitely huge discrepancies which I cannot explain!

cdemers · Thu Jan 17, 2019 10:12 am

Maybe fast track/path packets, if you are trying to queue traffic, should turn probably turn it off as it will bypass rules.

Sent from my SM-A520W using Tapatalk

sebastia · Thu Jan 17, 2019 11:17 am

As visible in in your config in viewtopic.php?f=2&t=144141, I think you have ipv6 active. This mangle is for ipv4 only.

/interface lte apn
add apn=jionet ip-type=ipv4-ipv6 ipv6-interface=lte1 name="Jio 4G"

Binser · Thu Jan 17, 2019 2:48 pm

@sebastia

As visible in in your config in viewtopic.php?f=2&t=144141, I think you have ipv6 active. This mangle is for ipv4 only.
Code: Select all
/interface lte apn
add apn=jionet ip-type=ipv4-ipv6 ipv6-interface=lte1 name="Jio 4G"

Thanks for the suggestion. I don't use that APN, and here is my package config:

/system package pr
Flags: X - disabled 
 #   NAME                                    VERSION                                    SCHEDULED              
 0   routeros-mipsbe                         6.44beta54                                                        
 1   system                                  6.44beta54                                                        
 2 X ipv6                                    6.44beta54                                                        
 3   wireless                                6.44beta54                                                        
 4   hotspot                                 6.44beta54                                                        
 5   mpls                                    6.44beta54                                                        
 6   routing                                 6.44beta54                                                        
 7   ppp                                     6.44beta54                                                        
 8   dhcp                                    6.44beta54                                                        
 9   security                                6.44beta54                                                        
10   advanced-tools                          6.44beta54

So I think that source of error can be excluded.

@cedemer
Thanks for your suggestion. That's a good thing to check. But since I am using simple queues, fasttrack is turned off. Here are my firewall filters:

/ip firewall filter
add action=accept chain=input comment="Accept Winbox" disabled=yes dst-port=8291 in-interface=lte1 protocol=\
    tcp
add action=accept chain=input comment="defconf: accept established,related,untracked" connection-state=\
    established,related,untracked
add action=drop chain=input comment="defconf: drop invalid" connection-state=invalid
add action=accept chain=input comment="defconf: accept ICMP" protocol=icmp
add action=drop chain=input comment="defconf: drop all not coming from LAN" in-interface-list=!LAN
add action=accept chain=forward comment="defconf: accept in ipsec policy" ipsec-policy=in,ipsec
add action=accept chain=forward comment="defconf: accept out ipsec policy" ipsec-policy=out,ipsec
add action=fasttrack-connection chain=forward comment="defconf: fasttrack" connection-state=\
    established,related disabled=yes
add action=accept chain=forward comment="defconf: accept established,related, untracked" connection-state=\
    established,related,untracked
add action=drop chain=forward comment="defconf: drop invalid" connection-state=invalid
add action=drop chain=forward comment="defconf:  drop all from WAN not DSTNATed" connection-nat-state=!dstnat \
    connection-state=new in-interface-list=WAN

My complete config can be seen here BTW: viewtopic.php?f=2&t=144141&p=709360#p709293

BTW I was just checking the stats again, and the discrepancy seems to be narrowing:

/que s p stats
Flags: X - disabled, I - invalid, D - dynamic 
 0    name="PCQ-Queue" target=192.168.86.0/24 rate=177.2kbps/455.0kbps total-rate=0bps 
      packet-rate=130/123 total-packet-rate=0 queued-bytes=0/0 total-queued-bytes=0 
      queued-packets=0/0 total-queued-packets=0 bytes=317745337/2804936080 
      total-bytes=0 packets=2276675/2626929 total-packets=0 dropped=511/74285 
      total-dropped=0 pcq-queues=5/6 
/ip fi m p stats all
Flags: X - disabled, I - invalid, D - dynamic 
 #    CHAIN                       ACTION                            BYTES         PACKETS
 0    postrouting                 change-ttl                  303 955 589       2 121 188

So what do you guys think now?

Binser · Thu Jan 17, 2019 4:51 pm

I used packet sniffer and I think I have found the culprit: ARP protocol packets!

/tool sniffer packet print detail
time=2.638 num=581 direction=tx src-mac=XX:XX:XX:00:00:00 dst-mac=XX:XX:XX:E6:E6:E6 interface=lte1 
   protocol=arp size=42 cpu=0 fp=no

sebastia · Thu Jan 17, 2019 4:56 pm

These are definitely not mangled: not ipv4

Binser · Thu Jan 17, 2019 4:59 pm

So you agree this resolves the mysterious discrepancy!?

sebastia · Thu Jan 17, 2019 5:14 pm

No, ARP is link-local and doesn't pass through router. It won't be accounted for in simple queue.

The TTL update applies to header of packet only, so if there are fragments transmitted (packet is split for some reason), TTL will apply to first fragment only, but simple queue will have all fragments on books. Only explanation I can think of right now.

Binser · Thu Jan 17, 2019 5:20 pm

Yes, I also thought they should be local, but I filtered for outgoing tx packets from lte1 (direction=tx interface=lte1). Is outgoing from wan a local packet, because wan sends it back into the router?

sebastia · Thu Jan 17, 2019 5:23 pm

these will be transmitted by all interfaces on network, but they don't pass through simple queue. there is no ip's involved (Layer2 traffic) and ip's is what simple queue works with.

Binser · Thu Jan 17, 2019 5:31 pm

Ok, thanks for your help!

I am satisfied now, because packet sniffer showed me that all outgoing packets in my test run are TTL=64.

That's what I wanted to achieve.

Thanks for everybody's assistance, and of course especially for @sebastia who really excelled!

sebastia · Thu Jan 17, 2019 8:18 pm

you're welcome

xaocass · Fri Oct 11, 2019 9:42 am

I have similar problem - I have one more router behind my mikrotik router and it looks like my ISP started blocking traffic coming from behind that. I'd like to reset TTL on all the outgoing traffic.
How can it be done from the web interface of my router?

Binser · Mon Jan 13, 2020 9:42 pm

@xaocass
Open a terminal window in webfig and then copy paste:

/ip firewall mangle add action=change-ttl chain=postrouting new-ttl=set:64 out-interface=ether1 passthrough=no

assuming outgoing traffic passes through ether1 to your ISP. If not, change ether1 above to the correct interface.

Setting TTL for Outgoing Traffic [SOLVED]

Setting TTL for Outgoing Traffic

Re: Setting TTL for Outgoing Traffic [SOLVED]

Re: Setting TTL for Outgoing Traffic

Re: Setting TTL for Outgoing Traffic

Re: Setting TTL for Outgoing Traffic

Re: Setting TTL for Outgoing Traffic

Re: Setting TTL for Outgoing Traffic

Re: Setting TTL for Outgoing Traffic

Re: Setting TTL for Outgoing Traffic

Re: Setting TTL for Outgoing Traffic

Re: Setting TTL for Outgoing Traffic

Re: Setting TTL for Outgoing Traffic

Re: Setting TTL for Outgoing Traffic

Re: Setting TTL for Outgoing Traffic

Re: Setting TTL for Outgoing Traffic

Re: Setting TTL for Outgoing Traffic

Re: Setting TTL for Outgoing Traffic

Re: Setting TTL for Outgoing Traffic

Re: Setting TTL for Outgoing Traffic

Re: Setting TTL for Outgoing Traffic

Re: Setting TTL for Outgoing Traffic

Re: Setting TTL for Outgoing Traffic

Who is online