[HECnet] Cisco DECnet routers and NML

[Thomas DeBellis]

Oh, it's not just the rules that are not understood nor kept up to date, 
sometimes it's the firewall software itself.

One time my phone rang and it was my boss turfing an emergency on me 
with an EVP whose FTP "wasn't working; it just hangs".  As you can 
guess, it was, "Drop what you're doing and get this done now!!"  EVP's 
get listened to...  So I immediately tried it myself and naturally, it 
worked just fine.  Turns out that I was using Windows (at the time) 
whose clients sent RFC959 compliant data connection verbs, PORT and PASV.

Some further digging with the network heroes got a trace showing that 
the EVP's machine was a Mac sending the IP6 compliant verbs, EPRT and 
EPSV, which are somewhat backwards compatible for sending IP4 
addresses.  It's a very reasonable thing to do, but in retrospect, the 
FTP client should have issued a FEAT to see if the remote system even 
supported the new verbs.

The problem was that the firewall software didn't know about the verbs 
and simply swallowed them, never giving any indication that this had 
happened.  After an upgrade, everybody lived happily ever after, more or 
less.

Come to think of it, I don't think that the Windows client at the time 
implemented passive mode; it may still not do PASV.

Had you ever gotten the impression that the overall level of competence 
of many technical support organizations is steadily declining?  I keep 
finding myself teaching these guys things... Simple things...

On 5/5/20 7:36 PM, Johnny Billquist wrote:
> I think they just meant TCP. I'm not sure those clowns would even 
> understand that UDP is a separate name space, separate protocol, and 
> their firewall rules are not actually applying...
> (Well, ok, I would hope they understood as much, but I've had to fight 
> ISPs enough to last me a lifetime...)
>
>   Johnny
>
> On 2020-05-06 01:32, Peter Lothberg wrote:
>> Blocking NTP? So how do you get time? (udp 123)
>>
>> ----- Original Message -----
>> From: "bqt" <bqt at softjar.se>
>> To: "hecnet" <hecnet at Update.UU.SE>
>> Sent: Tuesday, May 5, 2020 6:23:20 PM
>> Subject: Re: [HECnet] Cisco DECnet routers and NML
>>
>> They are unfortunately mostly incompetent, set to watch over even more
>> incompetent people hooking up to the internet. So they try to do what
>> they think is right, but it's a royal pain for people who actually do
>> know what they are doing, and who want to do some things...
>>
>> (I will not even tell you how much problems I have with mail in
>> different directions...)
>>
>>     Johnny
>>
>> On 2020-05-06 00:15, Supratim Sanyal wrote:
>>> it's important we watch our blood pressure. I got this gem back. Trying
>>> to figure out why SNMP is not working based on this list ...
>>>
>>> Support Ticket #62899404 has been updated
>>>
>>> Description:
>>> Hello Supratim,
>>> We've been implementing measures to avoid cyber attacks from and or to
>>> our network, For this reason, ports:
>>> 23,123,7722,389,135,137-139,445,69,514,161-162,6667 have been blocked.
>>>
>>> ---
>>> Supratim Sanyal, W1XMT
>>> 39.19151 N, 77.23432 W
>>> QCOCAL::SANYAL via HECnet <http://www.update.uu.se/~bqt/hecnet.html>
>>>
>>>
>>> On May 5, 2020, at 6:05 PM, Dave McGuire <mcguire at neurotica.com
>>> <mailto:mcguire at neurotica.com>> wrote:
>>>
>>>> On 5/5/20 5:22 PM, Paul Koning wrote:
>>>>>>> The Cisco DECnet router implementation does not speak "decnet
>>>>>>> management" as
>>>>>>> we all knew. The way we are using them the tunnel end-points are on
>>>>>>> the Internet.
>>>>>>>
>>>>>>> Most of the information "missing" is actually available through the
>>>>>>> SNMP MIB,
>>>>>>> so if we could agree on a common read-only community and publish
>>>>>>> the IP addresses
>>>>>>> of those routers it would be possible to complete Paul's map..
>>>>>>>
>>>>>> I would definitely be up for that. Maybe "hecnet-ro" for the
>>>>>> community name?
>>>>>>
>>>>>> Regards, Tim.
>>>>>
>>>>> Unfortunately this doesn't seem to be feasible.  The issue is that my
>>>>> ISP blocks SNMP outbound -- I have no idea why they would so such a
>>>>> thing.  And as far as I can tell there isn't any way to tell Cisco to
>>>>> accept incoming SNMP requests on any port other than the standard 
>>>>> one.
>>>>
>>>>   I would be on the phone with them cursing a blue streak.  I mean, do
>>>> they sell you a damn net connection, or not?  There's life outside of
>>>> port 80!  Wow.
>>>>
>>>>   One thing you might be able to do is create a port mapping coming 
>>>> into
>>>> whatever terminates the "web browsing connection" from your upstream
>>>> provider, on some port that they don't presume to block, forwarding 
>>>> back
>>>> to port 161 on the Cisco.
>>>>
>>>>             -Dave
>>>>
>>>> -- 
>>>> Dave McGuire, AK4HZ
>>>> New Kensington, PA
>>
>>
>
>