Debugging packets disappearing after reception

Question

I'm going to try to make this explanation as straightforward as possible, it's driving me up the wall since I've eliminated every option I can think of.

There are two hosts, we'll call them Alice and Bob.

• On Alice 10.242.0.1/32 is assigned to lo and on Bob 10.242.0.2/32 is assigned to lo.
• Between Alice and Bob there is a gre tunnel that provides a point to point of 10.242.0.101/32 to 10.242.0.102/32, we'll call this interface a_b_gre on both sides.
• Additionally, Alice has the ip address 10.242.1.1/24 assigned to a bridge.

Focusing on Bob, it knows that both 10.242.0.1/32 and 10.242.1.0/24 can be reached via 10.242.0.101/32. There are no firewall rules in place, policies are set to ACCEPT.

So here's my problem: when Alice pings 10.242.0.2 with a src ip of 10.242.1.1, the packets are received but not routed or replied to. Now for some of the many things I've tried in the process of debugging this:

1. Ping from 10.242.0.101 to 10.242.0.102: works fine
2. Ping from 10.242.0.1 to 10.242.0.2: works fine
3. Ping from 10.242.1.1 to 10.242.0.102: also doesn't work
4. tshark -pi any icmp: the packets are seen arriving, no response packets
5. tshark -i lo icmp: no packets seen

6. Sysctl checks:

   net.ipv4.conf.all.forwarding = 1
   net.ipv4.ip_forward = 1
   net.ipv4.conf.all.accept_local = 1
   net.ipv4.conf.all.rp_filter = 0
   net.ipv4.conf.all.route_localnet = 1
   net.ipv4.conf.all.log_martians = 1
   

7. iptables TRACE rule: TRACE: filter:INPUT:policy:1 IN=a_b_gre OUT= MAC= SRC=10.242.1.1 DST=10.242.0.2 ... which suggests it passed through the input chain fine.

8. conntrack -L: icmp 1 29 src=10.242.1.1 dst=10.242.0.2 type=8 code=0 id=29499 [UNREPLIED] src=10.242.0.2 dst=10.242.1.1 type=0 code=0 id=29499 mark=0 use=1 ... So definitely gets there... clearing the conntrack entry doesn't help.

9. route lookup checks: Our survey says...

   Bob # ip route get 10.242.0.2 from 10.242.0.1 iif a_b_gre
   local 10.242.0.2 from 10.242.0.1 dev lo table local
       cache <local>  iif a_b_gre
   Bob # ip route get 10.242.1.1 from 10.242.0.2 iif lo
   10.242.1.1 from 10.242.0.2 via 10.242.0.101 dev a_b_gre
       cache  iif lo
   

And now I'm out of ideas. Bob clearly receives the packet, and it seems to know what it should be doing with it, but it seems like something is making it drop the packet rather than replying to it or routing it on to the loopback. Considering that I see the same behaviour when I try to do a ping along the lines of ping -I 10.242.0.1 10.242.0.2 10.242.0.3, where .3 belongs to a third host setup similarly to the first two, and again ip route get giving the right answer, I'm definitely suspicous of the forwarding stage.

Oh, I should also note that I specifically don't want to NAT the address. While that would solve the immediate issue, it also defeats the objective, which is to get the packet to route through properly.

So, any thoughts on where to go from here?