13 Jul
2017
13 Jul
'17
11:33 a.m.
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