Hello,
I try to forward GRE packets to another router behind my router, so I added a dstnat rule :
add action=dst-nat chain=dstnat dst-address=xx.xx.xx.xx in-interface=adsl-ether1 protocol=gre to-addresses=192.168.10.171
Sadly, this rule is never triggered (counter stays at 0) and incoming GRE packets are going through the input chain, where they are blocked by the “drop invalid” default rule.
Do someone knows why the dstnat rule isn’t triggered ?
Joris
Is IP address attached directly to adsl-ether1 (static or DHCP) or there is a PPPoE client attached to adsl-ether1?
It’s a PPPoE client 
So that’s the mistake. For the IP stack, the ether1-adsl interface is not relevant. So replace it by the pppoe-out1 (or whatever name you have assigned to the PPPoE client interface) in the firewall rules and in /interface list member if used there, and the forwarding should start working.
Thanks for your answer !
Actually, I renamed my pppoe-out1 interface, that’s why there is adsl-ether1 in my nat rule.
But it’s the right interface…
Joris
In that case, the only thing I can imagine is that the GRE packets started arriving before this dst-nat rule has been added, so a tracked GRE connection has been created. And only packets not matching any existing connection are pushed through the srcnat and dstnat chains. So /ip firewall connection remove [find protocol=gre] would normally help, but with GRE it is not always the case, so disabling the tunnel at the remote device for more than 10 minutes may be necessary to make the tracked connection time out.
Ok thanks, I will retry this later
Thank you
Instead of waiting the 10 minutes, couldnt he also go into /ip firewall connection find it and remove it?
As I wrote - removal of connection normally works, but the handling of GRE in connection tracking is weird in many aspects. I had multiple cases where the removal of GRE didn’t succeed in the past. So worth trying, but not guaranteed to work.
Understood, thank you!