Comware

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?

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

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?

    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

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.

Hi David,

Pressing forward i have added some debugging information.

Screenshot

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

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

On 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

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

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?

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