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.
Rob
I can ping all three IP's from my
44.165.2.2 / 44.165.2.4 systems.
and from smartphone as well.
Best regards.
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
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
Mike,
I don't think relay via the tunnel is the big issue. The ampr gateway will only forward packets to your subnet, with the provision that they have a registered DNS entry.
Spoofing happens, and sometimes I see packets to my subnet to hosts without DNS, but not a big volume.
I think the only element you should take care is to drop traffic which targets your published subnet (let's say a /24) but has no sub-subnet target (let's say you use internally 3x /26 so one /26 is unused) . This traffic will be forwarded via your default 44 route and could create some loops.
Otherwise, the rules you described are sufficient.
Marius, YO2LOJ
On 2017-04-06 21:10, M6XCV (Mike) wrote:
(Please trim inclusions from previous messages) _______________________________________________ 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
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
-
M6XCV (Mike) -
Marius Petrescu -
Rob Janssen -
SP2L