I've sorted the source address and am now originating with a source address of 44.131.14.255.
I guess this also highlights another issue, does anyone have a pointer to the correct way to set up filters for this? I have added some quick rules to prevent my gateway being a public IP relay, but it looks like many others have not. I am not sure the correct way to configure these filters for the general use case. I should now be discarding all packets that don't have a source or destination within my network, but I do not check for spoofing beyond that. This should be "good enough"? Clearly, others have gone further.
Thanks, Mike, M6XCV
On 6 April 2017 at 18:26, M6XCV (Mike) m6xcv@m6xcv.uk wrote:
On 6 April 2017 at 16:51, Rob Janssen pe1chl@amsat.org wrote:
(Please trim inclusions from previous messages) _______________________________________________
If you want to test it, 44.131.14.254 is a second loopback on the gateway that is used for status monitoring. 44.131.14.192 is a unicast node "inside" my network to check end to end connectivity.
Your network is OK in our routing table. I can ping 44.131.14.255 but not those other addresses.
Can you ping .254? .255 should go direct and .254 should be encapsulated to the same machine.
Do you have an address I can test to? I have been doing a few tests and it would appear that there are some issues here.
Previously I was able to access services that were public the same as an external host, but now many of those are not working. As an example 44.137.0.1 works fine from an external IP address, but not a 44.131.14/24 one. I have found at least 1 host responding to my encapsulated packets with ICMP Administratively Denied, which makes me suspect that the problem is actually my anycast setup with my source address not matching the gateway address.
I am now trying to get my packets to come from 44.131.14.255 to see if this fixes things, but it's taking longer than usual to find the magic combination of commands.
Thanks, Mike, M6XCV