I try to Man in the Middle the traffic of an App to a Cloud. For this purpose I use the Burp-Suite Pro Edition.

What I've done:

  1. Setup a WiFi with an Alfa-Wifi-Dongle and create_ap; shared the network with my eth0.
  2. Connect my Mobile Device to it and tested connection to http://example.com
  3. Started an invisible proxy in Burp listening on *:1337
  4. Try to route the traffic through the listener:

echo "1" > /proc/sys/net/ipv4/ip_forward

nft add table ip mitm

nft add chain mitm prerouting {type nat hook prerouting priority 100 \;}

nft add rule ip mitm prerouting iifname eth0 tcp dport 80 counter redirect to :1337

nft add rule ip mitm prerouting iifname eth0 tcp dport 80 counter dnat to

Last steps are the same for any other ports I try to intercept (443, 8800 e.g.)

What I've tried so far:

  • Changed the Interface of the routing
  • Changed the Target Scope in Burp
  • Changed the invisible proxy to a non invisible proxy (now you know how desperate I am)
  • Changed the nftables destination host to only example.com
  • Used another proxy-host instead of localhost
  • I've done this many many times although never bothered to memorise or write down the actual setup. The notable difference is that I've not yet done it with nftables, only with iptables. Should be pretty simple to migrate but there's quite a few caveats. Transparent proxying is required in this case.
    – Pedro
    Commented May 19, 2020 at 13:42
  • I suggest making sure your interception is working with an HTTP site (neverssl.com is a good example) then move up to TLS stuff. Burp must, of course, be listening on and your linux host must be able to route traffic into the Internet. If nftables is like iptables in this sense, redirect and dnat to are equivalent. you can use tcpdump/wireshark and nftables logging targets to understand what is happening.
    – Pedro
    Commented May 19, 2020 at 13:42
  • any reason you don't want to just add a proxy on the device itself?
    – MikeSchem
    Commented May 20, 2020 at 2:21

1 Answer 1


The first issue I can observe in your ruleset is that your prerouting hook priority should be 0 or -100 as per the documentation, or at least lower than postrouting.


Are you Masquerading your traffic outbound towards the Internet? (pls refer to the link above)

EDIT (added for completeness) after the OP's own comment in response:

You also need a hook for postrouting for NATting to work.

nft add chain mitm postrouting { type nat hook postrouting priority 100 \; }

  • 1
    That wasn't the problem. But at least your answer helped me to figured out what was the problem: "[...] or at least lower than postrouting.". nft needs a postrouting hook as well whether or not I need that for my purpose. Simply adding a nft add chain <table_name> postrouting {type nat hook postrouting priority 100 \; } solved the problem and the MitM works fine. Thank you!
    – Tyr
    Commented May 27, 2020 at 15:31
  • 1
    now that you mention it, yes, I recall a discussion around this, both hooks need to exist for natting to work. glad you worked it out. I'll tweak the answer for completeness.
    – Pedro
    Commented May 27, 2020 at 15:44

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .