Remember that the system routing table and the encap routing table are separate on amprgw. The system routing table is in the kernel; the encap table is in user space. Packets arriving at amprgw which are for hosts listed in the encap hosts table are diverted to the encap router; all other packets are left to the kernel to route.

Ok that should work fine.

On the other hand, packets leaving (originating at) amprgw are first looked up in the system routing table and if a route is found (as it would be for your bgp-advertised subnet), they are sent out the system Ethernet interface and not diverted into the encap router. Packets with a destination not in the system routing table are tested to see if they're in the encap list, and if they are, they're sent to the encap router to be forwarded. The rest are dropped. The encap list currently has 19000 host entries in it.

Why do you have entries for the BGP-advertised subnets? Would those not be adequately handled by the default route? Or is this only to handle IPIP tunnels with a BGP-advertised net-44 tunnel endpoint address? Maybe route entries for only those addresses would be an option. (after all, they are known as they are listed in encap.txt)

The algorithm could then be to lookup 44-net addresses in the IPIP table when there is no specific route for them in the routing table. When no match is found, they could still be sent out as BGP-routed when desired, this could be achieved with a "special" entry in the lookup array for BGP-routed addresses that are not mentioned in the encap list.

I have experimented with forcing 44.137.40.2 into the encap router with an explicit route to the loopback interface. This seems to work; the pings go out a tunnel to 89.18.172.156. I've left this route in place for now so you can repeat your tests and see if you do indeed get replies over the tunnel the way you expect. Please let me know.

Interesting: I can now ping 44.0.0.1 from that system, but a "telnet 44.0.0.1 25" still yields nothing. I have not yet been able to find why that is, I see the SYN ACK coming back on the tunnel and I have allowed all traffic from 44.0.0.1 in the firewall but it simply fails to establish. No ACK is going back to you. I can connect to other IPIP endpoints just fine. Strange.

It is not really required to fix it, I can easily route the mail via a different path, but I was interested in finding why this goes wrong and how it may affect others / other applications.

It could be argued that I should scrap FreeBSD on amprgw and start over with a Linux host. I don't know enough about the intricacies of Linux IP handling to be at all confident of being able to do that.

I can understand that! It is certainly possible to get it running, and it would be a lot easier to get IPIP running, but it is always a big step to do such things.

Rob