Wallet behind corporate firewall

[cvarjao]

There was at least one instance where SSI wallets (including Trinsic) do not work on a corporate network/wifi. We may need to investigate what are the network requirements.

Problem:

(WIP) It looks like a mobile wallet access non http/https (ports 80/443) endpoints which might not be allowed for some corporate firewalls. The initial assumption is that access to the ledger is through a non http/https port.

Workaround

• unblock ZMQ ports (tcp/9702)
• turn off Wifi and turn on mobile data

Proposed Solution

https://github.com/2060-io/credo-ts-indy-vdr-proxy

[knguyenBC]

Encountered another lawyer who had this same problem. She was able to figure out that she needed to turn off wifi when at work and that it works fine at home.

[WadeBarnes]

To clarify, nodes on an indy-node network can be using any ports in the range of 9700 to 9799 for either of their node and client ports. There is a very loose convention that nodes use 9701 for their internode communications and 9702 for their client communications. For example all of the nodes in the CANdy networks conform to the 9701 (node) and 9702 (client) convention, however there are several nodes on the Sovrin networks that use other ports in the allowed range. It all depends on the network and the Steward.

A few examples:

    "name": "sovrin.sicpa.com",
    "network": "Sovrin Main Net",
    "client-address": "tcp://194.209.53.116:9778",
    "node-address": "tcp://194.209.53.115:9777",
    
    "name": "prosovitor",
    "network": "Sovrin Main Net",
    "client-address": "tcp://138.68.240.143:9711",
    "node-address": "tcp://138.68.240.143:9710",

    "name": "pcValidator01",
    "network": "Sovrin Main Net",
    "client-address": "tcp://52.175.254.49:9799",
    "node-address": "tcp://52.175.254.49:9701",
    
    "name": "icenode",
    "network": "Sovrin Main Net",
    "client-address": "tcp://185.102.43.35:9792",
    "node-address": "tcp://185.102.43.35:9791",
    
    "name": "findentity",
    "network": "Sovrin Main Net",
    "client-address": "tcp://34.211.203.16:9799",
    "node-address": "tcp://34.218.164.50:9700",

    "name": "esatus_AG",
    "network": "Sovrin Main Net",
    "client-address": "tcp://194.110.133.112:9710",
    "node-address": "tcp://194.110.133.110:9700",

    "name": "danube",
    "network": "Sovrin Main Net",
    "client-address": "tcp://193.46.104.5:9722",
    "node-address": "tcp://193.46.104.4:9721",    
        
    "name": "Stuard",
    "network": "Sovrin Main Net",
    "client-address": "tcp://4.231.233.12:9701",
    "node-address": "tcp://4.231.233.12:9700",                

    "name": "DustStorm",
    "network": "Sovrin Main Net",
    "client-address": "tcp://172.110.164.16:9712",
    "node-address": "tcp://172.110.164.16:9711",        

[WadeBarnes]

When you're speaking with security folks about this you need to explicitly indicate that they ONLY need to allow outbound traffic on the port range 9700-9799, which is a relatively safe thing to do. They can continue to block inbound traffic on those ports. The clients, the wallets in this case, only need to be able to reach out to establish the connection (outbound). There will NEVER be a case where a node attempts to make a connection (inbound) to a client.

You may also get some security folks wanting to know the IP addresses of the nodes so they can specify them in their firewall rules. This is not practical as nodes will come and go from a given network over time and the IP addresses of some nodes may even change over time as a Steward migrates to a different hosting platform. You would end up having issues with clients failing to connect to a given network over time that would be exceedingly difficult to troubleshoot. It also does not make a lot of sense since it's only outbound connections that need to be opened.

[jeffaudette]

need to have a conversation with Stephen and Andrew @jeffaudette will reach out to the ent apps team when we are ready for this, will be after the performance issues are resolved
Jeff will facilitate the meeting

[jeffaudette]

@cvarjao sm\po

[cvarjao]

Closing as duplicate as this is being addressed by #2023