Comware

 View Only
last person joined: 3 days ago 

Expand all | Collapse all

Site to Site connection MS Azure using Comware policy based

This thread has been viewed 0 times
  • 1.  Site to Site connection MS Azure using Comware policy based

    Posted Feb 01, 2018 04:08 PM

    I have changed my configuration to test if it is possible to make a connection with MS Azure using the policy based configuration as I had problems configuring the Router based solutions.

    I can happely say that I have accomplished this task.

    First you have to setup Azure to setup a VPN Policy based config. You the get the IP address space and the IP address of the gateway to Azure.

    Then comes the fun part:

    Create an Access list to guide the traffic:

    acl advanced 3102
     rule 0 permit ip source <YOUR INTERNAL SUBNET> 0.0.0.255 destination <AZURE SUBNET> 0.0.1.255

    create your key-chain:

    ike keychain Azure1
     pre-shared-key address <MSAZURE IP ADDRESS> 255.255.255.255 key simple <add your key>

    Creat an ike proposal

    ike proposal 20
     encryption-algorithm aes-cbc-256
     dh group2
     sa duration 28800
     description Azure IKE proposal

    Next create your IKE profile:

    ike profile Azure-Profile
     keychain Azure1
     local-identity address <YOUR IP ADDRESS>
     match remote identity address <NS AZURE IP ADDRESS> 255.255.255.255
     proposal 20

    Next Construct your IPSEC  Transform-Set

    ipsec transform-set azure-trans
     esp encryption-algorithm aes-cbc-256
     esp authentication-algorithm sha1

    Next create your IPSEC prolicy

    ipsec policy AzurePolicy 10 isakmp
     transform-set azure-trans
     security acl 3102
     remote-address <MS AZURE IP ADDRESS>
     ike-profile Azure-Profile
     sa duration time-based 3600
     sa duration traffic-based 102400000

    Now lets tie it all together by applying to to the interface:

    interface GigabitEthernet0/0
     port link-mode route
     mtu 1400
     ip address <YOUR INTERNET IP ADDRESS> 255.255.255.248
     nat outbound
     ipsec apply policy AzurePolicy

    So far so good.

    The connetion works and you can see the connection with:

    dis ipsec sa

    dis ike sa

    But if you try to ping the subnet within MS Azure your traffic will not route.

    You need to add in a static route. Now my question:

    I have tried every thing and all possible options and nothing seems to work.

    The most logical is to add

    ip route-static 10.0.0.0 0.0.1.255 <MS AZURE IP ADDRESS> but this doen't seem to work. No traffic is flowing, So what am I missing something? Can anybody help me get the traffic to flow?

     


    #ipsec
    #MSR954
    #Ike
    #Comwarev7
    #Azure


  • 2.  RE: Site to Site connection MS Azure using Comware policy based

    EMPLOYEE
    Posted Feb 01, 2018 05:45 PM

    Don't reverse the mask on the static route... try ip route-static 10.0.0.0 255.0.0.0 <MS AZURE Address>

    Regards,

    David



  • 3.  RE: Site to Site connection MS Azure using Comware policy based

    Posted Feb 02, 2018 01:27 AM

    Hi David,

    Thanks for the reply. We have tried that to:

    ip route-static 10.0.0.0 23 13.80.113.xx

    When we try to ping a server on the Azure side 10.0.0.4 the counter of the ipsec doesn't move:

    [GobyRouter954]dis ipsec st
      IPsec packet statistics:
        Received/sent packets: 24765/24973
        Received/sent bytes: 7900352/2832832
        Dropped packets (received/sent): 0/0


    [GobyRouter954]dis ipsec st
      IPsec packet statistics:
        Received/sent packets: 24765/24973
        Received/sent bytes: 7900352/2832832
        Dropped packets (received/sent): 0/0


    [GobyRouter954]dis ipsec st
      IPsec packet statistics:
        Received/sent packets: 24765/24973
        Received/sent bytes: 7900352/2832832
        Dropped packets (received/sent): 0/0

    This was taken during a ping from a network connected workstation.

    Any other suggestions?



  • 4.  RE: Site to Site connection MS Azure using Comware policy based

    EMPLOYEE
    Posted Feb 02, 2018 09:33 AM

        HPLeersum,

    Boy, this is interesting.  What kind of switch is this and what version of software are you running?

    Can you add counting to the rule and enable accounting in the traffic behavior?  Then you can display the acl and see if it is getting hits.  My guess is that there is something wrong with the rule.

    Also, did you do a display logbuffer to see if there are any messages in that?

    Regards,

    David



  • 5.  RE: Site to Site connection MS Azure using Comware policy based

    Posted Feb 02, 2018 11:23 AM

    Hi David,

    We added the counting and the debugging:

    Result:

    First

    *Feb  2 17:14:05:560 2018 GobyRouter954 ACL/7/Match: No match for source address in advanced rule 0.
    *Feb  2 17:14:05:560 2018 GobyRouter954 ACL/7/Match: No match for source address in basic rule 1.
    *Feb  2 17:14:05:560 2018 GobyRouter954 ACL/7/Match: No match for source address in basic rule 2.
    *Feb  2 17:14:05:560 2018 GobyRouter954 ACL/7/Match: No match for source address in basic rule 3.
    *Feb  2 17:14:05:560 2018 GobyRouter954 ACL/7/Match: No match for source address in advanced rule 0.

    Next

    *Feb  2 17:15:11:198 2018 GobyRouter954 ACL/7/Match: No match for source address in advanced rule 0.
    *Feb  2 17:15:11:229 2018 GobyRouter954 ACL/7/Match: No match for source address in advanced rule 0.
    *Feb  2 17:15:11:368 2018 GobyRouter954 ACL/7/Match: No match for source address in advanced rule 0.
    *Feb  2 17:15:11:397 2018 GobyRouter954 ACL/7/Match: No match for source address in advanced rule 0.

    Op the dis acl 3102

    Advanced IPv4 ACL 3102, 1 rule,
    ACL's step is 5
     rule 0 permit ip source 192.168.0.0 0.0.0.255 destination 10.0.0.0 0.0.1.255 counting (3 times matched)

    If we change anything the acl the ipsec fails as this is also part of th config.

    the dis ipsec sa

     IPsec packet statistics:
        Received/sent packets: 9/0
        Received/sent bytes: 432/0
        Dropped packets (received/sent): 0/0

        Dropped packets statistics
          No available SA: 0
          Wrong SA: 0
          Invalid length: 0
          Authentication failure: 0
          Encapsulation failure: 0
          Decapsulation failure: 0
          Replayed packets: 0
          ACL check failure: 0
          MTU check failure: 0
          Loopback limit exceeded: 0
          Crypto speed limit exceeded: 0

    During this time we are stil sending packets to this interface....

    Appriciate the help.

     



  • 6.  RE: Site to Site connection MS Azure using Comware policy based

    Posted Feb 02, 2018 05:40 PM

    Hi David,

    Pressing forward i have added some debugging information.

    ScreenshotScreenshot

    As you can see the ICMP flow is running from the azure enviroment to my server.ScreenshotScreenshot

    On the other side so going from on-prem to Azure I get thie:

    On premOn prem

    And now I'm lost.

    Just to be sure. The op prem network is 192.168.0.0/24 and the Azure network is 10.0.0.0/23

    the acl is defined as:acl advanced 3102
    ACL's step is 5
     rule 10 permit ip source 192.168.0.0 0.0.0.255 destination 10.0.0.0 0.0.1.255 counting (3433 times matched)

    the ip route-statis is defined as:

     ip route-static 10.0.0.0 23 13.80.113.xx

    So where have i made a mistake? Any ideas?

    Thanks

    Sidney

     

     



  • 7.  RE: Site to Site connection MS Azure using Comware policy based

    Posted Feb 05, 2018 03:23 PM

    Hi All,

    We have spend some time on this and what do we have?

    We have a connection to Azure and we have a very stable connection it's constantly up.

    We have tested the ip flow from MS Azure to the on prem and all is working as expected. We tested the on-prem to MS Azure and this doesn't work. We see that the icmp data is not reaching the ACL list and we have proven this doesn't work.

    We have removed the static route as this is not required according to the documentatio of HP and we have seens this have no effect on the MS-Azure data flow to the on-prem as this continues to work.

    So we are now focussing on the configuration of the Acl list and the Interface facing internet.

    Here is the configuration of the interface:

    interface GigabitEthernet0/0
     port link-mode route
     mtu 1400
     ip address 213.125.252.xx 255.255.255.248
     packet-filter name WebTelnet2 inbound
     nat outbound
     attack-defense apply policy 1
     ipsec apply policy AzurePolicy
    #

    This is the ipsec policy applied:

    ipsec policy AzurePolicy 10 isakmp
     transform-set azure-trans
     security acl 3102
     remote-address 13.80.113.xx
     ike-profile Azure-Profile
     sa duration time-based 3600
     sa duration traffic-based 102400000
    #

    And here is the Acl list:

    acl advanced 3102
     rule 10 permit ip source 192.168.0.0 0.0.0.255 destination 10.0.0.0 0.0.1.255 logging counting
    #

    Just to be sure our on-prem subnet is 192.168.0.0/24 and the Subnet of Azure is 10.0.0.0/23

    We are quite certain the Acl list is correct as the connection to MS Azure wouldn't be connecting if this was wrong.  We have also added the rule 20 deny ip but that doesn't go well with Azure as the connection is not being accomplished with this added to the Acl.

    So now I have no other options left. I know the ACL is functioning from Azure to on-prem and not from on-prem to Azure. I am running the ping from a workstation with ip address 192.168.0.93. The on-prem devices gives a perfect reply when pinging from the Azure server but when pingen the Azure server with address 10.0.0.4 from the workstation no result.

    Finally the workstations ip information:

      IPv4 Address. . . . . . . . . . . : 192.168.0.93(Preferred)
       Subnet Mask . . . . . . . . . . . : 255.255.255.0
       Default Gateway . . . . . . . . . : 192.168.0.254
       DHCP Server . . . . . . . . . . . : 192.168.0.1

    The routers address is 192.168.0.254

    So anybody who could help? Your help is much appriciated and lets be honest we then have the solution to connecting an on-prem network to Azure with a Comware v7.1 device.

    Kind regards,

    Sidney



  • 8.  RE: Site to Site connection MS Azure using Comware policy based

    Posted Feb 06, 2018 03:07 PM

    Hi all,

    Wel another day of testing and searching for an anwser. We have read all the documents we could find (believe me thats a lot of official documents) but actually came up with nothing indicating our error.

    So we decided to look at the older MSR935 with Comware v5 and we found that we could configure the connection perfectly.

    We were supprised to see the traffic flow to and from the on-prem and Azure with no error.

    So why is Comware v5 succesfull in communicating and Comware v7 not? Well it something related to this:

    Enabling transparent data transmission without NAT. This is a feature within the ipsec telling ipsec to no NAT during transport. And this is actually the key. and the explaination why our packets never reached the ACL within the Comware v7 router.  The config guide of Comware v5 states:

    By default, if an interface is configured with both NAT and IPsec, the outgoing packets on the interface are processed by NAT and then IPsec. In some special scenarios, NAT is not required before IPsec processing. You can use this feature to enable transparent data transmission without NAT for the interface. To enable transparent data transmission without NAT:

    ipsec no-nat-process enable

    And this is actually why Comware v5 does allow the traffic to pass as the traffic is not natted and thus passes the ACL.

    The config looks like this now within Comware v5:

    interface GigabitEthernet0/0
     port link-mode route
     nat outbound
     mtu 1400
     ip address 213.125.252.xx 255.255.255.248
     ipsec no-nat-process enable
     ipsec policy 1048576
     dns server 212.54.35.25
     dns server 212.54.40.25

    So I still can't believe that Comware v7 can't accomplish this as i still believe it must be able to be accomplished.

    Now my questions as I have searched many documents from HP and comware How did this command get translated from Comware v5 into Comware v7. If we know that then we must bable to accomplish this for Comware v7.

    Any one have any idea?



  • 9.  RE: Site to Site connection MS Azure using Comware policy based

    EMPLOYEE
    Posted Feb 06, 2018 03:58 PM

    HPLeersum,

    Good catch.  Comware 7 is not a direct upgrade from Comware 5  and not everything that Comware 5 can do is in Comware 7.

    Let me ask my peers and see if there is a similar command.

    Regards,

    David