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