6 Apr
2017
6 Apr
'17
6:51 p.m.
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
6 Apr
6 Apr
7:03 p.m.
New subject: New ampr-ripd 1.16 and amprd 1.5 released
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.
--
Tom - SP2L
------------------------------------
It is nice to be important.
But it is more important to be nice!
8:26 p.m.
New subject: New ampr-ripd 1.16 and amprd 1.5 released
On 6 April 2017 at 16:51, Rob Janssen <pe1chl(a)amsat.org> wrote:
(Please trim inclusions from previous messages)
_______________________________________________
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
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.
9:10 p.m.
New subject: New ampr-ripd 1.16 and amprd 1.5 released
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(a)m6xcv.uk> wrote:
On 6 April 2017 at 16:51, Rob Janssen
<pe1chl(a)amsat.org> wrote:
(Please trim inclusions from previous messages)
_______________________________________________
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
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. 
9:21 p.m.
New subject: New ampr-ripd 1.16 and amprd 1.5 released
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(a)m6xcv.uk> wrote:
On 6 April 2017 at 16:51, Rob Janssen
<pe1chl(a)amsat.org> wrote:
_________________________________________
44Net mailing list
44Net(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net (Please trim inclusions from previous messages)
_______________________________________________
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 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.
3237
days inactive
3237
days old
4 comments
4 participants
participants (4)
-
M6XCV (Mike) -
Marius Petrescu -
Rob Janssen -
SP2L