14 Jun
2015
14 Jun
'15
5:37 p.m.
You are sure that you are not masquerading 44.98.254.1 in your firewall?
masquerading overrides what you set have as source address and you will
see that it goes out with your commercial address as source.
At least when I monitored with tcpdump in Ubuntu.
I can't reach them from Canada when masquerading is switched off.
Those BGP announced subnets are a blackhole from here except when
they have a working IPIP entry or that a gateway is setup that can route
to them.
73,
Bob VE3TOK
On 15-06-14 03:10 PM, Bryan Fields wrote:
(Please trim inclusions from previous messages)
_______________________________________________
On 6/14/15 2:20 PM, Marius Petrescu wrote:
ampr-gw does not black hole packets from 44/8 to
the internet.
This is the whole purpose of that gateway: To permit 44/8 traffic to the
internet and back.
Then why is it broken?
The 44 to 44 traffic is supposed to go via IPIP
directly, so that one is
dropped correctly.
No. I can contact the hamwan seattle just fine from my 44net
space.
bryan@MrPickles:~$ traceroute -s 44.98.254.1 44.24.241.98
traceroute to 44.24.241.98 (44.24.241.98), 30 hops max, 60 byte packets
1 208.38.136.2 (208.38.136.2) 1.499 ms 1.268 ms 1.527 ms
2 gi2-4.border4.esnet.com (216.139.207.25) 1.725 ms 2.093 ms 2.094 ms
3 xe-10-2-2.bar1.Tampa1.Level3.net (4.53.172.41) 1.560 ms 1.563 ms 1.557 ms
4 ae-2-70.edge2.SanJose3.Level3.net (4.69.152.81) 67.321 ms
ae-4-90.edge2.SanJose3.Level3.net (4.69.152.209) 67.712 ms 66.815 ms
5 ae-2-70.edge2.SanJose3.Level3.net (4.69.152.81) 66.781 ms
ae-3-80.edge2.SanJose3.Level3.net (4.69.152.145) 72.565 ms *
6 4.68.71.94 (4.68.71.94) 67.288 ms 67.268 ms 67.539 ms
7 35.248.3.102 (35.248.3.102) 79.733 ms 79.714 ms 79.671 ms
8 66-193-43-154.static.twtelecom.net (66.193.43.154) 85.060 ms 84.562 ms
84.530 ms
9 ge0-0-0-1-sea4.threshinc.net (209.189.202.214) 80.159 ms
ge0-0-0-0-sea4.threshinc.net (209.189.201.214) 79.344 ms
ge0-0-0-1-sea3.threshinc.net (209.189.202.213) 84.855 ms
10 seattle-er1.hamwan.net (209.189.196.68) 84.161 ms 84.131 ms 84.014 ms
11 eth0.seattle-srv1.hamwan.net (44.24.241.98) 78.655 ms 78.350 ms 78.380 ms
Regarding BGP announced subnets: If they like,
they can set up an IPIP
endpoint, if not, that's it, they will be treated as spoofed IPs at the
moment and dropped. It's their personal choice.
No, the issue is the _broken_
routing at UCSD.
ARDC does not announce the 44/8, UCSD does it for them and has a static route
for 44/8 pointing at the gateway box. This is broken routing since the
gateway is unaware of the more specific networks.
What needs to be done is the UCSD gateway needs to be made aware of the
subnets in the global table and only announce the subnets it knows about.
There are routing protocols that would make this easy.
<tangent>
I'd argue the BGP networks would be better if 44/8 was split up in such a way
set aside a /12 (for example!) for BGP subnets and a /12 for the IPIP users.
This makes the routing much easier to configure on a IPIP encap gateway. The
present geographic area way of doing it leads to routing table bloat.
</tangent>
All space that's not used for legit 44/8 use (so like 98% of the /8 or so) is
used for darknet "research". Lets not get into the conflict of
interest/private inurement this presents.
IMHO the biggest enemy in this case is
illegitimate traffic being NATed to a
44 IP in a ham environment by bad routing, allowing external internet
traffic to the 44net.
I have no idea what sort of NAT configuration this is. Can
you define the
flows of traffic here and where the NAT is happening? Bad routing will not
cause NAT, NAT must be configured.
And there is nothing one can do to prevent it on
the service provider side
except some kind of authentication.
Exactly, 44net has no guarantee about the
traffic. Even if we did, it's still
a poor security model.
73's