Does Setting Multiple Peers in a Crypto Map Also Support Parallel IPSec Connections

Unanswered Question
Jan 31st, 2010

I desire to setup multiple parallel GREoIPSec connections from a single router WAN interface IP to multiple remote sites. I know that I can achieve this by applying to the interface a crypto map that is defined in multiples with different sequence numbers with each matched to a unique remote IPSec peer IP. I also read from the Command Reference that setting multiple peers for a crypto map entry provides for failover. I was just wondering if it could at the same time, using just the same crypto map, support parallel connections from all the peers set for it if all peers were to initiate IPSec connections to the interface at the same time where the crypto map match address command was matched to an extended IP access-list that specifies any as the destination host address for the GRE traffic that will trigger the negotiation. Would it refuse others if it already has established to one or would it accept others as well, all other things (IKE Policy, Transform Set) being equal?

I would just like to know if it works and any potential disadvantage with such a configuration if it works, as it seems a more efficient configuration to me if it did.

Below is my proposed configuration for the IP access-list and Crypto Map


Router(config)#ip access-list extended AllPeersCryptoACL

/* Style Definitions */ table.MsoNormalTable {mso-style-name:"Table Normal"; mso-tstyle-rowband-size:0; mso-tstyle-colband-size:0; mso-style-noshow:yes; mso-style-priority:99; mso-style-qformat:yes; mso-style-parent:""; mso-padding-alt:0in 5.4pt 0in 5.4pt; mso-para-margin-top:0in; mso-para-margin-right:0in; mso-para-margin-bottom:10.0pt; mso-para-margin-left:0in; line-height:115%; mso-pagination:widow-orphan; font-size:11.0pt; font-family:"Calibri","sans-serif"; mso-ascii-font-family:Calibri; mso-ascii-theme-font:minor-latin; mso-fareast-font-family:"Times New Roman"; mso-fareast-theme-font:minor-fareast; mso-hansi-font-family:Calibri; mso-hansi-theme-font:minor-latin;}

Router(config-ext-nacl)#100 permit gre host WANInterfaceIP any


Router(config)#crypto map AllPeersCryptoMap 1 ipsec-isakmp

Router(config-crypto-map)#set peer RemotePeer1-IP

Router(config-crypto-map)#set peer RemotePeer2-IP

Router(config-crypto-map)#set peer RemotePeer3-IP

Anyone confirmed workability or otherwise of this please respond. Thanks

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 4 (2 ratings)
Loading.
Paolo Bevilacqua Sun, 01/31/2010 - 05:28

I desire to setup multiple parallel GREoIPSec connections from a single router WAN interface IP to multiple remote sites

Why ?

tolugbala Sun, 01/31/2010 - 11:38

Sorry bevilacqua, by your question I guess you understood my WAN interfaces as private connections to my remote sites, hence you are wondering why tunneling through my own network. Actually, the WAN interfaces are connected to different ISPs at different locations for Internet connectivity. So the tunnels are to establish private connections through the Internet among the sites. Hope this clears it up?

Paolo Bevilacqua Sun, 01/31/2010 - 11:58

I meant, why do you want multiple tunnels betwen the same endpoints ?

By the way, the general solution for connecting branches over the internet, is called DMVPN.

tolugbala Sun, 01/31/2010 - 12:20

No, not multiple tunnels between the same endpoints, but multiple tunnels from one interace at one point to multiple remote endpoints. In order words, a specific point A has one tunnel to a remote point B and another tunnel to point C and another tunnel to point D. The tunnels from point A are however sourced from the same IP.

I know of DMVPN, having read about it and varied models, but being yet uncomfortable with the implementation, limitations and management I refrain from launching myself into it. I am still reading up on it. Since at the moment I just have 3 sites, I really do not think the overhead a manual multipoint VPN is that compelling to jump into the dynamic one.

Paolo Bevilacqua Sun, 01/31/2010 - 12:26

The are no disavantages or overhad in DMVPN, and that is what should be done for professional, scalable results.

DMVPN is actually nothing more than multipoint GRE over IPSEC. The D as in Dynamic refers to NHRP and that part is optional.

You can terminate multiple DMVPNs to multiple hub sites, and use routing to establish priorities.

Please remember to rate useful posts clicking on the stars below.

tolugbala Sun, 01/31/2010 - 13:06

Thanks bevilacqua.

I definitely would like to implement DMVPN seeing I have no doubt that it works and is the most professional thing to do. However, like I said before, I am yet to get a hang of it, it is in my plans for the future, certainly before the sites expand more than the present 3 to the projected maximum of 15.

I am not the kind of person that is comfortable with just implementing some configuration just because it works; I like to understand it fairly well first, especially how it will interact with other configurations of mine, before I do, so that I can manage and troubleshoot issues with it fairly. Since I am not yet so, I leave it off my present options. So, for now, I just would like someone to confirm if setting multiple peers in a crypto map entry supports parallel IPSec connections to the same tunnel source IP or otherwise.


Thanks again

Paolo Bevilacqua Sun, 01/31/2010 - 13:09

What you want to do, is the wrong way to achieve results.

This said, seems like you are eager to learn from your mistakes instead of profiting established best practices, so good luck.

tolugbala Sun, 01/31/2010 - 13:30

Seems like you too are eager to just push me unto what I am yet to  understand and you don't care about the fact that I am not yet comfortable with the design and implementation of the solution, just the fact that it is the more professional option it all that matters to you. A professional solution is not necessarily the only option excluding all others, just that it is likely more efficient and and manageable. Moreover, a professional solution requires someone who understands it to design, implement and manage it well. I am not yet, though I would like to, and I am already working towards that, but as a stopgap, I asked the question I asked. I really dont think thats too much to ask.


Then you said that my approach is the wrong way to achieve results. I really don't know what that means - that it will not work (which is what I really want someone to confirm to me) or that it will work just that it is not the best (which I am willing to accomodate as a stopgap)?

Anyway, thanks for the effort.

Paolo Bevilacqua Sun, 01/31/2010 - 13:40

Sorry, can't help you further. I never divert from technical matters, and I have indicated you already what is the best solution.

Any other consideration and decision, is up to you.

Richard Burts Sun, 01/31/2010 - 14:24

Boluwade

I have implemented GRE with IPSec from a single central router to multiple remote sites using a crypto map with multiple instances (unique sequence number for each remote peer). This works quite well. I do not believe that your proposed solution would work. For one thing it is my understanding that when you have multiple peer statements within a single instance of the crypto map that one peer is active at a time. If the active peer fails then the next peer becomes active. But I do not believe that multiple peers would be active at the same time. Also I believe that there are difficulties when the access list for IPSec traffic has permit any.

If you are interested in reducing the complexity of the crypto map you might consider configuring IPSec over GRE using Virtual Tunnel Interface. The VTI runs IPSec over the GRE tunnel but uses an IPSec profile rather than a crypto map. I have not used this feature but it doe appear that it provides the same functionality and does simplify the configuration quite a bit.

Here is a link that should get you started if you are interested in this possibility:

http://www.cisco.com/en/US/technologies/tk583/tk372/technologies_white_paper0900aecd8029d629.html

HTH

Rick

tolugbala Sun, 01/31/2010 - 15:37

Thanks rburts,

Like I said, I know about using multiple instance crpyto maps as you mentioned. It just occurred to me to find out if anyone had tried out my proposal and confirmed if it works or not. I do intend to try it out using GNS3.

By the way, I'm already checking out the linked reference and it seems easier to understand and quiker to implement for me.

Thanks for also saying that you just do not believe my approach will work. I suppose that means you have never tried it out so and not that you have tried it and it did not work. Will get back to you

tolugbala Tue, 02/02/2010 - 07:14

Hi rburts,

Just thought I should confirm to you that my proposed configuration of setting multiple peers within a single crypto map entry for parallel IPSec Peer conections is supported by Cisco IOS as much as for IPSec Peer failover. I just confirmed it in the Security Command Reference (both July & December 2009 editions).

It is affirmed under the usage guidelines section of crypto map (global IPSec) command. I have extracted below just the part that confirms it with the example used. Note that it says either (or both).

Crypto map “mymap 10” allows SAs to be established between the router and either (or both) of two remote IPSec peers for traffic matching access list 101....


crypto map mymap 10 ipsec-isakmp

  match address 101

  set transform-set my_t_set1

  set peer 10.0.0.1

  set peer 10.0.0.2

Thanks for your earlier reference still, it has helped too.

Giuseppe Larosa Tue, 02/02/2010 - 08:48

Hello Boluwade,

Security command reference says also the following:

Usage Guidelines

Use this command to specify an IPsec peer for a crypto map.

This command is required for all static crypto maps. If you are defining a dynamic crypto map (with the crypto dynamic-map command), this command is not required, and in most cases is not used (because, in general, the peer is unknown).

For crypto map entries created with the crypto map map-name seq-num ipsec-isakmp command, you can specify multiple peers by repeating this command. The peer that packets are actually sent to is determined by the last peer that the router heard from (received either traffic or a negotiation request from) for a given data flow. If the attempt fails with the first peer, Internet Key Exchange (IKE) tries the next peer on the crypto map list.

http://www.cisco.com/en/US/docs/ios/security/command/reference/sec_s2.html#wp1046908

the set peer allows to define multiple peers for redundancy not for using them at the same time.

The working solutions as explained by Rick and Paolo are: crypto map with multiple blocks for using multiple point-to-point GRE or DMVPN

Hope to help

Giuseppe

tolugbala Tue, 02/02/2010 - 23:30

Hi Giuseppe,

Thanks for contributing to this question.

I should confess that the section you cited from the command reference was what had always kept me believing that setting multiple peers in a crypto map entry is for failover exclusively. I had always thought that the usage and functionality of the Set Peer  command should be conclusively found under its section but alas there  was something more about it that was only to be found under crypto  map (global IPSec) as I cited in my reference. I however just recently felt it was not really saying what we seem to believe it is saying. It just did not seem logical to me that the router would reject a connection with a peer with interesting traffic matching its configured crypto map just because another distinct peer already had a connection similar. I felt since they were distinctly listed then they should be distinctly treated if and when they simultaneously requested separate connections, hence my posting this question to find out if any one has actually  checked out the workability of my proposed configuration. Unfortunately, no one (of all that responded) could confirm having tried it out, just the same supposition as I had held before. I had intended testing it out with GNS3 but was sort of lazy to and thought I should still go through the command reference well until I found the section I previously quoted.

Now I am just coming off trying out my config with GNS3 and I can confirm to you that the it worked for multiple (2 in my case) parallel connections. I therefore think that what that section means to say is that if the router that has the crypto map entry set with multiple peers is the one initiating the IPSec connection it would try to contact the last peer it made a connection with first and not according to the order listed in the crypto map. Hence, the section means not to say that if all peers set in the crypto map entry initiate connections simultaneously that the router with the multiple peer crypto map entry would accept only one and reject the others. I suppose that has been our erroneous supposition.

See below my config for the three routers I used to simulate it in GNS3 as well as different sh crypto... commands outputs from R1000 after the connections were established:

hostname R1000
!
crypto isakmp policy 100
hash md5
authentication pre-share
encryption des
crypto isakmp keepalive 10
!
crypto ipsec transform-set test ah-md5-hmac esp-des comp-lzs
!
crypto map Test 100 ipsec-isakmp
set peer 192.168.0.2
set peer 192.168.0.3
set transform-set test
match address Test
crypto isakmp key test address 192.168.0.2
crypto isakmp key test address 192.168.0.3
!
interface Tunnel0
ip address 10.0.0.1 255.255.255.252
keepalive 10 3
tunnel source 192.168.0.1
tunnel destination 192.168.0.2
!
interface Tunnel1
ip address 192.168.1.1 255.255.255.252
keepalive 10 3
tunnel source 192.168.0.1
tunnel destination 192.168.0.3
!
interface FastEthernet0/0
ip address 192.168.0.1 255.255.255.0
no ip route-cache
no shut
speed auto
full-duplex
no mop enabled
crypto map Test
!
ip access-list extended Test
100 permit gre host 192.168.0.1 host 192.168.0.2
200 permit gre host 192.168.0.1 host 192.168.0.3


hostname R1001
!
crypto isakmp policy 100
hash md5
authentication pre-share
encryption des
crypto isakmp keepalive 10
!
crypto ipsec transform-set test ah-md5-hmac esp-des comp-lzs
!
crypto map Test 100 ipsec-isakmp
set peer 192.168.0.1
set transform-set test
match address Test
crypto isakmp key test address 192.168.0.1
!
interface Tunnel0
ip address 10.0.0.2 255.255.255.252
keepalive 10 3
tunnel source 192.168.0.2
tunnel destination 192.168.0.1
!
interface FastEthernet0/0
ip address 192.168.0.2 255.255.255.0
no ip route-cache
no shut
speed auto
full-duplex
no mop enabled
crypto map Test
!
ip access-list extended Test
100 permit gre host 192.168.0.2 host 192.168.0.1


hostname R1002
!
crypto isakmp policy 100
hash md5
authentication pre-share
encryption des
crypto isakmp keepalive 10
!
crypto ipsec transform-set test ah-md5-hmac esp-des comp-lzs
!
crypto map Test 100 ipsec-isakmp
set peer 192.168.0.1
set transform-set test
match address Test
crypto isakmp key test address 192.168.0.1
!
!
interface Tunnel0
ip address 192.168.1.2 255.255.255.252
keepalive 10 3
tunnel source 192.168.0.3
tunnel destination 192.168.0.1
!
interface FastEthernet0/0
ip address 192.168.0.3 255.255.255.0
no ip route-cache
no shut
speed auto
full-duplex
no mop enabled
crypto map Test
!
ip access-list extended Test
100 permit gre host 192.168.0.3 host 192.168.0.1

SH CRYPTO COMMANDS OUTPUT

R1000#sh crypto isakmp pee
Peer: 192.168.0.2 Port: 500 Local: 192.168.0.1
Phase1 id: 192.168.0.2
Peer: 192.168.0.3 Port: 500 Local: 192.168.0.1
Phase1 id: 192.168.0.3

R1000#sh  crypto isakmp sa
dst             src             state          conn-id slot status
192.168.0.1     192.168.0.3     QM_IDLE              2    0 ACTIVE
192.168.0.1     192.168.0.2     QM_IDLE              1    0 ACTIVE

R1000#sh crypto session
Crypto session current status

Interface: FastEthernet0/0
Session status: UP-ACTIVE
Peer: 192.168.0.2 port 500
  IKE SA: local 192.168.0.1/500 remote 192.168.0.2/500 Active
  IPSEC FLOW: permit 47 host 192.168.0.1 host 192.168.0.2
        Active SAs: 6, origin: crypto map

Interface: FastEthernet0/0
Session status: UP-ACTIVE
Peer: 192.168.0.3 port 500
  IKE SA: local 192.168.0.1/500 remote 192.168.0.3/500 Active
  IPSEC FLOW: permit 47 host 192.168.0.1 host 192.168.0.3
        Active SAs: 6, origin: crypto map

R1000#sh crypto ipsec sa

interface: FastEthernet0/0
    Crypto map tag: Test, local addr 192.168.0.1

   protected vrf: (none)
   local  ident (addr/mask/prot/port): (192.168.0.1/255.255.255.255/47/0)
   remote ident (addr/mask/prot/port): (192.168.0.2/255.255.255.255/47/0)
   current_peer 192.168.0.2 port 500
     PERMIT, flags={origin_is_acl,}
    #pkts encaps: 78, #pkts encrypt: 78, #pkts digest: 78
    #pkts decaps: 78, #pkts decrypt: 78, #pkts verify: 78
    #pkts compressed: 0, #pkts decompressed: 0
    #pkts not compressed: 78, #pkts compr. failed: 0
    #pkts not decompressed: 78, #pkts decompress failed: 0
    #send errors 8, #recv errors 0

     local crypto endpt.: 192.168.0.1, remote crypto endpt.: 192.168.0.2
     path mtu 1500, ip mtu 1500, ip mtu idb FastEthernet0/0
     current outbound spi: 0xCE50C0AB(3461398699)

     inbound esp sas:
      spi: 0x1A03B3EB(436450283)
        transform: esp-des ,
        in use settings ={Tunnel, }
        conn id: 2001, flow_id: SW:1, crypto map: Test
        sa timing: remaining key lifetime (k/sec): (4387529/3209)
        IV size: 8 bytes
        replay detection support: Y
        Status: ACTIVE

     inbound ah sas:
      spi: 0x5E9D6102(1587372290)
        transform: ah-md5-hmac ,
        in use settings ={Tunnel, }
        conn id: 2001, flow_id: SW:1, crypto map: Test
        sa timing: remaining key lifetime (k/sec): (4387528/3203)
        replay detection support: Y
        Status: ACTIVE

     inbound pcp sas:
      spi: 0x8B4F(35663)
        transform: comp-lzs ,
        in use settings ={Tunnel, }
        conn id: 2001, flow_id: SW:1, crypto map: Test
        sa timing: remaining key lifetime (k/sec): (4387528/3203)
        replay detection support: Y
        Status: ACTIVE

     outbound esp sas:
      spi: 0xCE50C0AB(3461398699)
        transform: esp-des ,
        in use settings ={Tunnel, }
        conn id: 2002, flow_id: SW:2, crypto map: Test
        sa timing: remaining key lifetime (k/sec): (4387528/3200)
        IV size: 8 bytes
        replay detection support: Y
        Status: ACTIVE

     outbound ah sas:
      spi: 0x15E1A208(367108616)
        transform: ah-md5-hmac ,
        in use settings ={Tunnel, }
        conn id: 2002, flow_id: SW:2, crypto map: Test
        sa timing: remaining key lifetime (k/sec): (4387528/3200)
        replay detection support: Y
        Status: ACTIVE

     outbound pcp sas:
      spi: 0x5938(22840)
        transform: comp-lzs ,
        in use settings ={Tunnel, }
        conn id: 2002, flow_id: SW:2, crypto map: Test
        sa timing: remaining key lifetime (k/sec): (4387528/3200)
        replay detection support: Y
        Status: ACTIVE

     local crypto endpt.: 192.168.0.1, remote crypto endpt.: 192.168.0.3
     path mtu 1500, ip mtu 1500, ip mtu idb FastEthernet0/0
     current outbound spi: 0x0(0)

     inbound esp sas:

     inbound ah sas:

     inbound pcp sas:

     outbound esp sas:

     outbound ah sas:

     outbound pcp sas:

   protected vrf: (none)
   local  ident (addr/mask/prot/port): (192.168.0.1/255.255.255.255/47/0)
   remote ident (addr/mask/prot/port): (192.168.0.3/255.255.255.255/47/0)
   current_peer 192.168.0.3 port 500
     PERMIT, flags={origin_is_acl,}
    #pkts encaps: 68, #pkts encrypt: 68, #pkts digest: 68
    #pkts decaps: 68, #pkts decrypt: 68, #pkts verify: 68
    #pkts compressed: 0, #pkts decompressed: 0
    #pkts not compressed: 68, #pkts compr. failed: 0
    #pkts not decompressed: 68, #pkts decompress failed: 0
    #send errors 14, #recv errors 0

     local crypto endpt.: 192.168.0.1, remote crypto endpt.: 192.168.0.2
     path mtu 1500, ip mtu 1500, ip mtu idb FastEthernet0/0
     current outbound spi: 0x0(0)

     inbound esp sas:

     inbound ah sas:

     inbound pcp sas:

     outbound esp sas:

     outbound ah sas:

     outbound pcp sas:

     local crypto endpt.: 192.168.0.1, remote crypto endpt.: 192.168.0.3
     path mtu 1500, ip mtu 1500, ip mtu idb FastEthernet0/0
     current outbound spi: 0x67C20DD2(1740770770)

     inbound esp sas:
      spi: 0x96B6C75B(2528560987)
        transform: esp-des ,
        in use settings ={Tunnel, }
        conn id: 2003, flow_id: SW:3, crypto map: Test
        sa timing: remaining key lifetime (k/sec): (4580038/3260)
        IV size: 8 bytes
        replay detection support: Y
        Status: ACTIVE

     inbound ah sas:
      spi: 0x331DAB37(857582391)
        transform: ah-md5-hmac ,
        in use settings ={Tunnel, }
        conn id: 2003, flow_id: SW:3, crypto map: Test
        sa timing: remaining key lifetime (k/sec): (4580038/3260)
        replay detection support: Y
        Status: ACTIVE

     inbound pcp sas:
      spi: 0x4754(18260)
        transform: comp-lzs ,
        in use settings ={Tunnel, }
        conn id: 2003, flow_id: SW:3, crypto map: Test
        sa timing: remaining key lifetime (k/sec): (4580038/3259)
        replay detection support: Y
        Status: ACTIVE

     outbound esp sas:
      spi: 0x67C20DD2(1740770770)
        transform: esp-des ,
        in use settings ={Tunnel, }
        conn id: 2004, flow_id: SW:4, crypto map: Test
        sa timing: remaining key lifetime (k/sec): (4580038/3259)
        IV size: 8 bytes
        replay detection support: Y
        Status: ACTIVE

     outbound ah sas:
      spi: 0xC829D4D(209886541)
        transform: ah-md5-hmac ,
        in use settings ={Tunnel, }
        conn id: 2004, flow_id: SW:4, crypto map: Test
        sa timing: remaining key lifetime (k/sec): (4580038/3258)
        replay detection support: Y
        Status: ACTIVE

     outbound pcp sas:
      spi: 0x387D(14461)
        transform: comp-lzs ,
        in use settings ={Tunnel, }
        conn id: 2004, flow_id: SW:4, crypto map: Test
        sa timing: remaining key lifetime (k/sec): (4580038/3258)
        replay detection support: Y
        Status: ACTIVE

Davezenith Wed, 07/28/2010 - 04:41

Hi,

Did you manage to ge this working outside LAB environment? I'm faced with a similar challenge in that, using one crypto map, I have set multiple peers.

There is a diagram attached - IPs are fictional. I have managed to get the site-to-site IPsec working between remote peer 2 and local peer. However, the GRE over IPsec tunnel is not establishing. I want to identify this is not a design limitation with the way crypto map handles multiple remote peers. The topology will scale to the point when 1 local Cisco will establish parallel tunnels to 10 different remote peers (none remote peers are not associated with one another) = 10 tunnels

Based on the above logic, the desired config for setting multiple peers will be:

crypto map MY_MAP 10 ipsec-isakmp

match address 101

set peer 1

set peer 2

set peer 3

set peer 4

set peer 5

set peer 6

set peer 7

set peer 8

set peer 9

set peer 10

set transform-set 1 2 3 4 5 6 7 8 9  10

end

Questions:

- Will the local Cisco attempt to establish 10 unique sessions each with one of the remote peers?

lets assume:

a) the transform-sets match the peers

b) the access-list 101 has 10 rules to match which traffic to encrypt

c) the crypto isakmp keys match

Thanks

David

Richard Burts Wed, 07/28/2010 - 14:32

David

I am not sure that anyone has come up with real proof whether the approach of specifying multiple peers within a single instance of a crypto map to establish multiple active IPSec sessions really works or not. Perhaps you may be the person who develops that proof.

I do know that a while back I had a TAC case open and asked the TAC engineer about this approach. The answer that I got was that the recommended approach was to have a separate instance of the crypto map for each remote peer. I have adopted that approach and it has worked well. I have a customer who is configured this way and has over 400 remote sites doing IPSec/GRE. The thought of trying to manage - or to troubleshoot a problem - a crypto map instance with 400 peers and an access list with 400 elements makes my head hurt.

HTH

Rick

Davezenith Thu, 07/29/2010 - 03:36

Hi Rick,

Thanks for the info. Point noted, my head hurts already...

Your approach sounds logical and easier to scale / maintain - this is now my learning curve. Keeping it simple, Lets say for example, I have 10 remote peers. This means I will now configure 10 crypto maps 1, 2,3...10 and 10 access-lists 101, 102, 103...110. Each map includes a peer, transform-set, extended access-list.

Question: I understand that you may configure only one crypto map per signle interface ( FA in this instance). What approach did you take to get around this to have all 10 instances active simultaneously (or where may I read about technical detailed examples of your approach so I may ask more of the right questions)

Rgds

David

Richard Burts Thu, 07/29/2010 - 05:17

David

The key thing is that you do not do 10 crypto maps but you do one crypto map with 10 entries. It might look something like this:

crypto map samplemap 10 ipsec-isakmp
set peer
set transform-set
match address

crypto map samplemap 20 ipsec-isakmp
set peer
  set transform-set
match address

crypto map samplemap 30 ipsec-isakmp
set peer
  set transform-set
match address

etc

HTH

Rick

tolugbala Thu, 07/29/2010 - 09:53

Hi David,

Setting multiple peers in a crypto map supports parallel connections like I already noted, but only if all the peers listed initiate the connections. The local router would initiate connection with only the last successful from the list. If however, each peer separately and simultaneously initiate connections, the local router would accept all

Actions

This Discussion